First off, I''d like to thank tetryds, both for advice and corrections he provided in the course of writing this tutorial, as well as the awesome BAD-T tournament he is running that led me to write this tutorial in the first place, that it might be of some use to those who want to enter but might not be familiar with FAR . With that out of the way, lets begin.

Ferram Aerospace research is a mod that aims to bring real-world aerodynamics and aerodynamic principles and mechanics to KSP. As a result, building an aircraft is now a bit more complex than in the rather more forgiving stock aero model, as planes must now be built to take into account various real-world aerodynamic design considerations. This will not be a comprehensive overview, it won't tell every trick in the book on how to make a competitive performance dogfighter, but it should adequately cover the basics sufficiently to build a successful subsonic aircraft that avoids plowing into the ground seconds after launch.

Lets start by building a basic airframe:

This consists of a KAX D-25 radial engine, a structural fuselage, an inline cockpit, a liquid fuel tank, and a tail adapter.

Now, before we add some wings, we should first know where the Center of Mass (CoM) is. This is important, as it will greatly affect wing placement and aircraft balance later on. On the sample craft, the CoM is here:

Also activated are the Center of Thrust and Center of Lift indicators. Now, the CoL indicator here looks different from stock; there's no arrow. In FAR, the CoL functions similarly, but not identically, to Stock. In stock, it indicated the net direction of lift provided by lift forces from the wings and other lift surfaces, in FAR, its simply the Aerodynamic Center. It can still be used to get a rough approximation of craft balance, but for learning precisely how a craft is balanced requires the FAR editor readouts, covered later.

So lets add some wings:

With wings on, it's looking more like a plane, but there's still some work to do. Control surfaces need to be added, and the plane balanced – as seen the CoL is slightly ahead of the CoM; this plane will want to pitch up, potentially leading to a stall and possibly crash. For a successful, easy to fly craft, the CoL should be behind the CoM, the aircraft should want to naturally pitch slightly downwards while in flight without control surfaces.

To correct the imbalance, there are a few available courses of action: The mass of the craft could be shifted forward, the wings moved farther back, or the empennage lengthened to shift the tailplanes back and offer better leverage on the craft once control surfaces are added.

A quick craft re-arrangement later, and :

A bit unorthodox, perhaps, but serviceable. The wings were moved back, and the structural fuselage behind the engine was moved to behind the fuel tank, which puts all the heavy things at the front of the craft. As a bonus, the main wings are now on the CoM, which will help with performance, as the main wing is the point the craft will want to pitch up or down; the closer the CoM is to this axis, the less leverage needed to affect pitch. Additionally, the main wing is also located on the fuel tank, which means as the craft files and the tank is drained of fuel, the overall CoM of the plane will more-or-less remain where it is. Knowing where the Dry and Wet CoM on the craft is good to know. If the CoM shifts too much as fuel is used up, it may result in the plane becoming unstable.

To control the aircraft, control surfaces are needed. Lets add some:

The craft now has a pair of ailerons, a pair of elevators, and a rudder. The ailerons are located at the main wing tips, and provide Roll authority, the elevators are on the horizontal tailplane and will control Pitch, and the rudder on the vertical one will control Yaw. keep in mind the principle of leverage; ailerons/elevons (control surfaces that control both Roll and Pitch) that are located near the fuselage will be less effective at rolling the craft then if they were placed further down the wing, likewise, the further from the CoM the elevators are the more efficient they are at pitching the craft. Elevators placed inline with the CoM won't have any effect at all (i.e. if the ailerons in the picture were set to control pitch, they would have negligible effect due to how close to the CoM they are).. By default, a newly placed control surface will be set to respond to Pitch, Roll, and Yaw commands; while leaving control surface inputs default generally speaking won't keep you from flying, it may cause the craft to do weird things, since the rudder will be trying to pitch or roll the plane, the ailerons will be trying to adjust the craft's Yaw, and so forth. To adjust the control surface's inputs, right click on it to get a context menu:

Std. Ctrl is the control settings needed here. Flp/splr controls flap and spoiler settings, covered later, and curWingMass is how much the wing weighs, with Mass-Strengt... 1 is the wing/control surface structural strength, also covered later.

Clicking on the Std. Ctrl button opens a new menu:

A few more options than in stock, no? Pitch %, Yaw %, and Roll % are pretty explanatory, these control that respective input. The 100 means that at present this surface will fully deploy in response to an input. This number can be changed from -100 to 100. having a Pitch at less than 100 means the surface will only deploy partially in response to an input, and a negative setting will have the surface deploy upside down, useful for things like front canards and so forth.

AoA% is the Angle of Attack percent. Instead of reading a P/Y/R input, it reads the crafts current AoA while in flight, and dynamically deflects the surface in response to it. This can be set from 200 to -200; useful for things like wing slats or having a plane that could automatically pull out of a dive, that sort of thing.

Brake Rudder sets if the control surface can be used for affecting Yaw like an A.I.R.B.R.A.K.E.S. part – perfect if you want to make a Ho-229 /B-2 type flying wing, this lets you maneuver without vertical rudders.

Ctrl Dflect is important. This determines, in degrees, how far a control surface deflects. The lower the number, the less deflection, and the slower the pitch/roll/yaw effect propagates in flight. Because FAR models aerodynamic stress failures, or in other words, too aggressive a maneuver and the wings rip off, being able to adjust the control surfaces so they don't result in a 15 G turn and Rapid Unplanned Disassembly of the craft is vital. The other, less immediately fatal thing adjusting Control Deflection will do is help prevent stalls from overaggressive maneuvering. Too much control authority for your elevators and you risk pitching the craft's AoA too far from prograde, resulting in at best higher drag, or worse, throwing the aircraft into a stall. A lifting surface stalls when its cL falls too low; in other words, when a lifting surface stalls, it drastically reduces the amount of lift it generates; too little lift, and the craft falls out of the sky.

Now, what about the Flp/Splr setting? Lets take a look:

Clicking the Flap setting will designate the control surface as a Flap; flaps are useful for take off and landing, when extended, flaps provide greater lift at lower speed; they also cause more drag. Flaps shouldn't be extended much or at all in normal flight. When a control surface is a flap, extending/retracting can either be done via right click menu while in flight, or via action groups.

Clicking the spoiler button actives that surface as a spoiler. In KSP, spoilers are basically airbrakes; they are automatically added to the Brake action group, and when the brakes are activated, the spoiler will deploy. Be careful when placing spoilers; place a spoiler in the wrong place or upside down, and you may discover that rather than a brake it is instead acting like a flap or an elevon and affecting the craft's flight differently than intended.

Now, lets talk about Mass-Strength. Mass strength adjusts both the mass and the strength of a wing. The stronger the wing, the more aerostress it can take before catastrophically failing. The slider goes from 0.05, for a wing that is basically made out of paper mache and prayers to 4.0 for a wing made out of adamantium. For a a spaceplane, a wing setting of 0.4 or so should generally be sufficient, for a subsonic stunt/sport craft doing acrobatics at low altitude, a higher wing strength is recommended, something like .6 or so for a light weight craft. Keep in mind, that a wing strength that works for turns at 100m/s might not be sufficient for puling out of a dive at 240 m/s. While there is nothing wrong with a higher wing strength, keep in mind that stronger wings are heavier; the standard Wing Connector A, with a strength of 0.05, weighs 15 kg, the same wing at 4.0 strength weighs 1237 kg!

With a basic plane built (yes, it still needs things like landing gear, but those are unneeded for now), its time to see how well it will fly (theoretically). To do this, open up the FAR editor window in the SPH/VAB by clicking on the FAR icon in the toolbar. When this is done, it brings up this:

This is the Flight analysis graph, which will display some information on the flight characteristics of the craft in various flight regimes. Currently here it is set to AoA analysis, which will show how the craft will handle at various angles of attack. It can also be set to show how the craft will perform at various mach numbers by clicking on the Switch to Mach Sweep button. The numbers at the bottom adjust the parameters to be tested. By default it is set to examine the craft from 0 to 25 degrees AoA, at an airspeed of mach 0.2

The side bar buttons are craft and environment settings. Want to know how the craft will fly on Laythe? Select it from the celestial bodies menu. You can also see how the craft will fly when flaps and/or spoilers on the craft are deployed. Lets see how the example craft will fare:

The mach value has been adjusted to 0.35, (around 120m/s), and the upper AoA limit has been increased to 50 degrees. The graph displays a number of lines:

The green line what the craft's lift/drag ratio is as the craft sweeps from 0-50degrees AoA. Looks like the craft will get the best lift for the lowest drag at around 5 degrees AoA.

The Blue line is coefficient of Lift – how much raw lift does the craft generate. The blue line goes steadily up until about 35 degrees AoA, and then starts falling. As the line goes up, the more lift the craft is generating. The tip of the cL curve at 35 degrees is important, this is the point the craft will begin to stall.

The red line is drag. As AoA increases, more wing surface area is exposed to oncoming air, generating more drag. Here, the line increases until about 40 deg. Of note is the area around the intersection of the red and blue lines. At 35 degrees, L/D increases slope slightly, and at 40 degrees it begins to plateau, combine that with the the correlating decrease in cL and it shows the aircraft stalling at 35 degrees and coming to a full stall at 40, pitching the aircraft that far up should be avoided. With stalls, main wings are the easiest to stall out, other lifting surfaces like tailplanes are a bit harder.

The final line, the yellow line, is a measure of craft stability. The lower the line, the more the craft will want to return to a neutral state. Here it steadily goes down, looks like the craft will automatically recover from an AoA induced stall of the wings and bring the nose back down to a prograde vector. The value of the line factors into this; the steeper the slope of the line, the more aggressive the return to a neutral state. the more aggressive this movement, the higher the G force the airframe is subjected to, the more G's, the stronger the wings will need to be.

The second page of the FAR editor window that is important is the Data/Stability Derivatives. This page can be access from the drop down menu in the upper left currently reading Static Analysis going to it, and:

A bit scary and technical, isn't it? Lets walk through it. At the top there is a planet selector (again, if you want to know how the plane will do on Laythe/Duna/Eve, or for the suicidally insane, Jool). The next is altitude, in kilometers, from sea level. As atmospheric density and temperature change, so to does aero performance. The last is speed, in mach, for the same reason; higher mach results in different aerodynamic considerations and fun engineering challenges like dealing with the trans-sonic region supersonic drag, which won't be covered here. Lastly, flap/spoiler settings can be set.

On to the numbers. The Calculate Stability Derivitives button has already been clicked, so the stats have data to them. The first set of numbers at the top are technical data about the craft. Of note is the wing area, which can be used to determine the craft's wing loading. The higher the wing loading, the more mass per square meter the wing is supporting, and the stronger the wings have to be, but higher wing loading also means less drag. Lower wing loading means the craft has more drag, but is also potentially more maneuverable, dependent on control surface settings. Also of note is the level flight numbers,which tell the the chosen mach speed in m/s, AoA, and the coefficient of lift for level flight at the selected planet, altitude, and speed – in this case, the craft needs to have an AoA of ~2.4 degrees when flying at ~119m/s (the input mach 0.35) for level flight at sea level. The coefficient of Lift can also be used in conjunction with the static analysis graph, go back and look, and the cL of .157 shown here will correlate with the blue line on the graph.

Next up are the Longitudinal and Lateral Derivatives, each of these reference a particular type of movement about an axis. These should be green, any numbers in red indicate the craft will exhibit an unwanted behavior, and the higher the green number, the less that particular kind of negative craft behavior is a concern. In particular, lets look at Mw. This number tells how much a craft will pitch up in neutral flight. The number is -.114, which means the craft will very slowly pitch down in normal fight, which is to be expected with the CoM head of the CoL. But what if we moved it?

Lets see what happened:

Mw is now red, with a value of 0.08. the craft will now want to pitch up in normal flight. It wont pitch up very fast, but it is still a motion that will have to be actively corrected through trimming the elevators or applying active inputs to them every so often.

As with higher numbers being good when green, higher numbers when red is bad, the higher the number, the worse the detrimental effect. When a number is red and very low, it isn't the end of the world, and can easily be corrected by the control authority the plane has. For numbers bigger than around 0.5 - 1.0, a redesign of the craft is suggested to reduce the number, or even better, make the value in question green. In many cases this will be minor tweaks to wing and control surface placement. In the case of large numbers (3.0 - 4.0 and above) major structural redesign will be necessary.

Loading times have always SUCKED, especially with more and more mods. I could never understand why or how to improve. I'd go from a 2,000 dollar gaming laptop to 45 min loading times, to a $5000 gaming laptop 3 years later and still have 45 min loading times!!! 

Finally, I got a $8,000 laptop - thinking, this HAS to be the best for speed as its literally the best on the market I can buy..... Nope, still 45 mins. 

So I started digging, researching, understanding, testing.... and heres what I've learned and how to do it: 

First what did I look into: 

• In game settings
• Graphics drivers
• 3rd party nvida apps to improve performance
• windows settings for gaming
• installing completely on RAM disk - unusable but slight improvement in loading times (1-10 mins) (I have 32gm RAM and with all my mods ny pc would crash since I needed 25gb of ram just to run KSP and the remaining RAM couldn't run other background services, so I doubt anyone here will have more luck unless their mod size is lower)
• forcing openGL
• Preventing FPS limiting

After all of this, here is what I found to be the most effective and what I'm doing now, if the stuff above isn't included its because they sucked, or didn't work.
 

1.  Don't open KSP from steam, or the KSP.exe in the folder structure. Delete the shortcut from your desktop to make it very easy not to screw up.
2. Go to your steam KSP folder, and find the launcher.exe, open this, and use this for now on to load the game everytime. Don't load via ckan "launch button".
3. Click on settings in the launcher
4.  then make sure your anti aliasing is disabled - your CPU/GPU is better than this 20 year old version of AA 
5.  frame limit is 180
6.  do NOT use full screen
7. 1/8th or 1/4th texture loading and can keep on "beautiful"
8. Click Advanced and disable logging, and then force fake fullscreen mode (idk why this helps but this changes everything).
9. Install RivaTuner (its safe, and it lets you stop the internal limits KSP sets on FPS, which is the bottleneck for loading time. Just add the ksp_64.exe on rivatuner and use these settings https://gyazo.com/a766e2b2cc6032fc4b8cca54042e2c4d
10. With RivaTuner installed, I can reach up to 450 FPS on the loading screen.
11.  Press launch on the launcher.exe and then close it once KSP opens. 

EDIT: EVEN BETTER PERFORMANCE!!!!!!!!

12.  Click settings, remove force fullscreen from step 8, set to the LOWEST resolution possible, for me its like 1000x800 (around there, just spam down until it can't go lower). 

13. Close the game window that pops up (since for some reason if you open launcher.exe it will also open KSP.exe, using the old settings, so close that, you may have to force it via alt f4 and windows force close to save time), then once thats forced closed, go back to the launcher and press play again, now, the window will be extremely small with the new settings and you'll get FPS like below. 

FPS rates at lowest resolution get up to 850+ FPS 

Confirm everytime before launching that the texture is back to 1/4th or 1/8th because sometimes if I close ksp and reopen the launchers settings are all saved except it has my textures set back to full res, same for the resolution.

Hope this helps - someone please post their time differences once saved. 

Oh btw, these changes with no mods on my PC KSP completely loads within 30 seconds to main menu

Stock + OPM System:  Link 

(When you open the links above, please save a copy to your own Google Account to be able to edit for yourself)

This document allows you to view the antennas utilized by CommNet to aid you in the preparation for missions to specific bodies or to determine signal strengths between vessels before launch.

-----------------------------------

Antenna Selector Sheet

The 'Antenna Selector' sheet allows you to pick enter a specified range between vessels and enter which antennas you require to give you a signal strength that is suitable for the application. You can also get a visualization of the signal strength between all major celestial bodies with the currently entered antenna setup.

There is also a separate sheet for use with Near Future: Exploration's reflector mechanic.

-----------------------------------

Antennas Sheet

The 'Antennas' sheet allows you to view all the antennas listed by the creator/mod pack grouping and all their individual statistics. Here you can enable/disable the antennas from the mods you are using.

-----------------------------------

Systems Stats Sheet

The 'System Stats' sheet lists details about all the available bodies to chose from if you wish to make your own calculations or assumptions.

-----------------------------------

Form Submission

I have included a link on the 'Antennas' sheet to a Google Form where you can submit details of antennas you wish for me to include on the spreadsheet. The submissions should auto-fill into the 'Form Submissions' sheet for later review. Useful for mod authors to submit their own CommNet module stats for their antenna parts.

-----------------------------------

Please let me know what you think, any mistakes I have made, any ways I can improve this etc. etc. 

Hopefully you find this useful for your own games.

KSP CommNet Antenna Selector - Stock + OPM System: Link

P.S. This document was built off of my original KSP RemoteTech Antenna Selector document, if you are interested in RemoteTech, please visit the forum post for this calculator: Link

-----------------------------------

For great visualizations of the antenna ranges at the various DSN levels, also be sure to check out @Kergarin & @wile1411's illustrations that can be found here. They are super useful.  

1. Use a fairing of an appropiate size as the root.
2. Put an engine plate of the same size inside the fairing.
3. Put something of the same size onto the node thats hanging in midair that appeared because of the engine plate.The default settings of the engine plate should be okay,so please don't change them!
4. Create the fairing.
5. Move that something into the fairing.
6. Put everything you want on top of the engine plate.(Don't put intakes,wings,airbrakes,deployable solar panels,or parachutes.Those components need air flowing thru them to work,and our deployable solar panels deploy using no energy because of the use of the currents of kraken gas in space,which get blocked by fairings and cargo bays and service bays too.Also,the fairings block heat radiation but not light,even though they are the same thing,for some reason.Anything that spews out anything else needs to be moved using the translation tool until it is poking out,and 0<poking out amount<1/2 of the length(i.e the COM of the spewer needs to be inside the fairing,but the spewy end needs to be outside)

https://kerbalx.com/jounce/umm-this-is-dragless Sample craft(Suborbital rocket with no drag)

Ive been tinkering with props and think I have enough info to get folks started on building a single engine light aircraft, as in the picture below.

Here's a pic in the assembly building with some pertinent info:

First up, engine:

These are massively overpowered for the application at hand. 

Under "Motor Size and Output" drop this down from 100 to 1. Yes, seriously. This will allow you to run the engine at max torque & RPM without it twisting the plane over. It should go without saying, but the more powerful the engine, the more torque it has.

Once set, disengege the motor, and set action group1 to toggle motor enagagement it, followed by action group Main Throttle with both Torque & RPM bound to it.

Prop Blades

Ive set these as static pitch, so it gives you an idea of how things work.

First off attach the blades to the engine and adjust so theyre flat faced when looking at them. 

Now set them to "Deployed" and the authority limit to -35.

At the bottom of the prop PAW window youll see theres two variants based on rotation. Pick the relevant one for the rotation of your engine - ie if the engine is going clockwise, set it as clockwise as above.

Edit / Update : with experimentation Ive found that you only need 2 blades on an engine when its power is set to between 1 - 4% of the original, max power output. Any more than that and the drag from extra blades means you get less power.  3 blades seem to operate in the 5 - 12% band (roughly). All testing done with the Type B prop. 

Youll still get some torque induced rotation when in flight.  To counter this I added a set of elevons, removed one from symmetry and set it to deployed at -9 on the authority limiter.

To start  going, reduce throttle to zero, engage motor with your action group binding, then throttle up. 

This little set up is slow, will take off around 45ms with a little encouragement from pitch control, and top speed is about 55ms. You will probably have to trim it out or set wings with a slight AOA depending on your build, but I took this over to the island runway fairly easily. 

Should be enough to get you all started, hope its helpful.

Have tried with SAS on and off and have tried with 'Target' mode (the autopilot feature) on and off but no matter what, still getting the 'your rocket is off course' message.

I have also tried going back to the previous tutorial, advanced construction, and re-designing the ship, twice. Placing the fins as low beneath the CoM as possible and moving the parts to get the CoM closer near to the base of the rocket which I have heard helps with stability.

So far, nothing I have tried works. Please help!

Online calculator tool for Kerbal Space Program

Delta-V Planner

• Click the planets and moons that you want to visit to get a total required delta-v number for the mission
• A mission can contain multiple checkpoints to visit, each on different planets, moons, and orbital situations (or surface landed)
• Also provides a step-by-step breakdown for each leg in the journey
• Shows the delta-v requirements for every possible trip combination (delta-v subway-maps only work when Kerbin is one of the locations)
• Configure custom preferences such as aerobraking at specific locations, applying a margin of error to your mission, or calculating the most efficient route instead of a direct route
• Save & export the mission as a JSON file to share with others

CommNet Planner

• Create satellites, relays, rovers, stations, bases, etc. with a custom selection of antennae, then drag those around the screen to see where commnet connections are valid
• Every craft automatically indicates if it has control or not based on the relay networks it is connected to
• Use this to plan out communication network constellations, without having to trial-and-error this in-game
• Set the DSN Tracking Station level at Kerbin to match in-game upgrade progress
• Set the CommNet difficulty settings to match the settings in-game
• Add Remote Guidance cores in craft to test a piloted base providing remote control to a rover, even when a connection to Kerbin is out of reach
• Shows detailed stats such as cost, power rating, mass, transmission speed, etc. for the entire collection of antennae on each craft
• Save & export the constellation as a JSON file to share with others

ISRU Mining Station Calculator

• Design a mining base by swapping out different parts to see their effects on the system
• Select the planets or moon for the mining base, adjust the ore concentration, and even add a specific skill engineer onboard
• Toggle the type of processing that the ISRU will be doing. Only refining Liquid Fuel? Then only turn on Liquid Fuel refining
• Fuel cells, solar panels, and RTGs can be added for power supply
• A handy 'Production and Consumption' panel displays the total outputs, and any deficiencies of the system
• Number sliders control the amount of each part. Use this to adjust the amount of drills, or power sources, or radiators until the outputs are green with no deficiencies
• Warning messages highlight potential issues in the design, such as not having 'Ore Storage' parts
• Choose from 73 stock parts
• Save & export the parts selection design as a JSON file to share with others

https://ksp-visual-calculator.blaarkies.com/

Checkout the github repo

But how do you use these exactly? How do you balance the reactors, engines, radiators and overall dry mass to get decent TWR, consistent burns and keep the reactors in their prime too? Here is all the introductory info you need to get you going.

Topics will be added over time so don't worry too much about things missing from this post.  

Glossary

• Reactor + Engine Balance
• Reactor + Radiator Balance
• Reactor Longevity
• Reactor Control
• Capacitors
• Capacitor Control
• Fuel Performance
  • Argon
  • Xenon
  • Refueling
  • Lithium

Reactor + Engine Balance
When picking a reactor, watch its Fission Generator > Power Generated value and Fission Reactor > Required Cooling value. When picking an ion engine watch its Propellants > EC consumption and you'll find that this consumption will tend to be exact to the output of a given reactor and that there are several more such pairings begging for you to notice them.

Reactor + Radiator Balance
Once you can keep in mind how much the Fission Reactor > Required Cooling of a given reactor is, it should be easy enough to look at the stock radiators and add or multiply their Radiator Specs > Core Heat xFer values. Once your total exceeds the reactor's Required Cooling value that's it, that's how many of that radiator you need. This is a good setup: 400kW from 2x large static radiator > 300kW from 1x Garnet. Also, never forget that static radiators must be attached directly to the reactor or its parent part or else. I don't need to install a radiator mod to show how to balance a reactor with them, but I would need to install one because stock radiators do have their limitations, and "options" are especially important for ion-powered vehicles that dare to pass through an atmosphere with their reactors running.

Reactor Longevity
Don't get swept away with the power of a nuclear reactor that you decide to or completely forget to put an RTG or solar panel on your craft. Always include an alternate means of power generation so that the probe core can be kept alive and that you don't waste the reactor's nuclear fuel Enriched Uranium between the last orbital maneuver and the next. In flight there is the danger of the reactor overheating and the loss of core health (separate from core life). Core Health is expressed as a percentage and iirc, once health is lost, total output becomes capped and it can eventually meltdown and become dead and useless (I don't know if it explodes, haha). Core Life is the amount of time you get depending on how full it is with Enriched Uranium and what the output cap is. The output cap is controllable via a slider in the NF Reactor toolbar panel between 0 and full EC/s rate, technically allowing the reactor to run for decades or centuries as an oversized RTG.

Reactor Control

The final thing about nuclear reactors is, of course, how to operate them directly, especially from the snazzy NF GUI app. Look for this  in your KSP toolbar once you have Near Future Electric installed and a nuclear reactor on the active vessel. (It does not show in Map View.) Every proper nuclear reactor mod out there should integrate into Near Future and can be controlled through it, and that makes life good. Such mods (that I know of) include USI Core and Mk2 + Mk3 Stockalike Expansion but exclude KSP Interstellar which changes all nuclear devices in its own way.

Do not expect this to control any radiators associated with a reactor. Those must be toggled separately.

The UI Elements are as follows:

• The radio (circle) button under a reactor name is the main switch and lights up when toggled on.
• The thermometer (with two checkpoint markers) respectively indicate the thermal range, the peak operating temperature, and the overload/shutdown temperature. The number will always be the temperature at a given moment.
• The three symbolic items above the thermometer represent kilowatt output (not necessary to most of us), the ElectricCharge output (most important) and Core Life (very important). When a reactor is on it will show you the duration in years instead of "Reactor Offline".
• Basic Controls is the output control slider or reactor throttle (at 100% by default) which lets you finely control the ElectricCharge output. Accordingly, the kW, EC and Core Life values over the thermometer will change. Most of us don't need to click Advanced Controls. I didn't, so I don't even know what that looks like.

This screenshot features the 2.5m USI device with its context window open and the NF control window. Note that in both GUI its output slider is set to 25%. Both windows have their distinct advantages, but NF's window shows you what matters right now, and for all your reactors if you have more than one, removing the need to pin all your reactors' context windows if you ever have to access them all at once.

You do not want to end up like this!

In the odd chance that you visit an infernal planet and decide that solar panels were not necessary...or they are present but useless at the time, make sure to never leave things on that will guzzle the current. In this case I had a life support device on and the ship's radiators were maxed out, causing them to fail to cool the reactor, which in turn led to the reactor gradually overheating, losing output efficiency, and nearing its overheat/shutdown temperature. If it reaches its shutdown temperature and does not receive cooling, it will remain super-heated and its Core Health (the percentage status of the core, not the output duration bit) will start to fall, meaning it's decaying and it will become a metal brick. As long as it is hot it will decay. If there's a separate power source able to feed the radiators and cool the reactor down, the decay will stop.

Jebediah!

Capacitors
As @Supercheese mentions below (which helps me a lot in do this part, so thanks muchly  ) installing capacitors instead of a reactor can save cost and weight and increase deltaV by quite a lot. As shown in the first picture, you get 8x the amount of StoredCharge (SC) to ElectricCharge for the same mass and volume of the part. Each part here weighs 0.25 tons but one quarter-ton of capacitor shines brightly against 2 whole dark tons of normal battery. (Stock 2.5m batteries featured here).

While that is a great thing, they have their disadvantages. They are not a proper 2-way street like batteries. They cannot "charge while discharging" and their charge rate is very small to avoid possibly bricking a low-specced or unmanned ship. A capacitor can be paused from charging (and when charging it will feed from everything that produces or stores ElectricCharge) but it cannot be paused while discharging (in doing so it will feed everything that stores or consumes ElectricCharge or it will dump and waste its charge).

Part powers:

Item,      Holds,    Discharges,  Recharges
CAP-101,     800 SC,    80 EC/s,     8 SC/s
CAP-106,    3000 SC,   300 EC/s,     8 SC/s

CAR-1.6,    1600 SC,   160 EC/s,     8 SC/s
CAR-8K,     8000 SC,   800 EC/s,    16 SC/s
CAR-EXTRA, 32000 SC,  3200 EC/s,    32 SC/s

Capacitor Control

You can control the discharge rate of a capacitor in the VAB and in flight at the Near Future Capacitor toolbar button. The Capacitor Control Panel is only accessible in flight.

In the VAB or in flight, the PAW features the discharge rate slider with a non-zero minimum (50% actually) and its maximum (the default). This can be adjusted on the fly in case of the need to throttle down (or up again mid-burn).

In the UI, from left to right the elements are:

• Master switches: The three lightning buttons are:
  • Blue: Discharge all capacitors simultaneously. This is necessary for large vessels that want to release enormous amounts of ElectricCharge at once. Think hard before feeling the need to press because a discharger cannot be paused.
  • Green: Turn on the recharger for all capacitors. This lights the radio buttons on the far right of each row in the part list below.
  • Red: Turn off the recharger for all capacitors. This un-lights the radio buttons on the far right of each row in the part list below.
• Item row. There's one for each capacitor in the vessel:
  • Icon (not customizable).
  • The part's title. The 2.5m inline one is indeed called "CAR-EXTRA Capacitor"
  • Blue lightning button. Discharge this part.
  • Speedometer icon and slider: The discharge rate controller. In screenshot they are all set to their minimum rate which means they will produce 1600 EC/s.
  • Battery icon and blue gauge: The fuel bar. How full this capacitor is. When its recharger is turned on it shows how much SC/s (StoredCharge) it is rated to produce, not how much it gets to produce (with respect to sub-optimal situations).
  • Battery (charging) icon: The recharger icon.
  • Radio button: The individual recharger toggle and status light.

As shown in the:

• Argon-fueled stack (left): because the visible ion engine consumes 1999 EC/s I set the discharge rate to just over that to feed the engine and any vital systems.
• Lithium fueled stack (right): because the 2.5m capacitor releases 1600 EC/s minimum I've chosen to build a test ship with 4x the tiny "LF-1 'Charon' Magnetoplasmadynamic Thruster." Two capacitors have their recharger turned on.

Even if for some reason you end up stacking a reactor's weight or more in capacitors (and heavy, heavy solar panels...) on a craft, you're still saving more than just cost. You're avoiding the troubles of nuclear fuel and reactors themselves if you're still skeptical about the things, but you'll remain at the mercy of solar panel efficiency if you're operating very far from a star.

The next thing to consider is how many capacitors set at a given discharge rate will afford a consistent engine burn up to a desired maximum length. The reference formula to measure by is very simple:
Total StoredCharge / Discharge Rate = Maximum burn time in seconds.

Fuel Performance
If you're a nut for fuel performance, then here are a few opening stats including engine sizes to help weigh Near Future's propellants in your mind before you read about them below.

• Argon Engines
  1 ~ 54.55 kN, 2800 ~ 5500 Isp
  0.6m, 1.25m, 2.5m
   
• Xenon Engines
  1.4 kN, 4000 Isp (Stock Dawn engine)
  2.3 ~ 5.6 kN, 6500 ~ 19300 Isp (Added engines)
  0.6m only
   
• VASIMR Engines (can halve their Isp for nearly triple thrust, no change in propellant consumption)
  Xenon mode: 4 ~ 68 kN, 6000 ~ 7000 Isp
  Argon mode: 2.5 ~ 44 kN, 8500 ~ 9500 Isp
  0.6m, 1.25m, 2.5m
   
• Lithium Engines
  46 ~ 237 kN, 2900 ~ 3800 Isp
  0.6m, 1.25m, 2.5m

Argon
I personally prefer ArgonGas over XenonGas because it's more abundant in-game (as it is irl) than Xenon and is hence easier to harvest from Duna and other planets with atmosphere. Here I modify a  probe that was never meant to go far from wherever it's deployed, to (almost) be able to cross SOI. Almost = not enough fuel but there's plenty, plenty room to fix that. Adding a radial Argon tank (or 4) and changing the Garnet to its TopNode subtype so I can attach things to its other end.

Xenon
Here's a Xenon-powered Duna probe I launched soon before KSP 1.2.0 was even announced. This is 6 tons, 1 TWR in low Mun orbit iirc, and 11km's dV! The Garnet reactor underneath has 2x Radiator Panel (edge), the straight ones with 150kW cooling power directly attached and they're exactly enough (300kW together) to keep it at/within its limits (300kW). The particular Xenon engines on this one have been deprecated so I can't explore them now.

Refueling
There are two mods I know of that supply a means not just to use Argon or Xenon, but to replenish your tanks.

The first is Karbonite, part of USI. Its low-altitude atmosphere scoops come in 1.25m and 2.5m size. They have very poor intake values since they are firstly filter type devices, and they operate better the faster you're moving and the thicker the atmosphere. Strap some of these, a karbonite power cell and a USI kontainer (for Argon) or a stock Xenon tank to your airplane and fly around (if you have the patience or an autopilot mod). Have the scoops filter karbonite too to feed the power cell and even better, feed some karbonite jet engines so you can infinitely fly and refuel faster.... Or you know, spam them on a landed craft and do the timewarp disco.

(Forgive me for mentioning so much karbonite.)

Then there's Near Future, of course. It provides the AIReS Atmospheric Sounder (Science category) and the M-2 Cryogenic Gas Separator (Utility category) for harvesting Argon and Xenon. The AIReS is a scanner and both parts only work in atmosphere. Unlike karbonite's scoops, the M-2's performance is not influenced by whether it's moving, and it consumes between 12 and 24 EC/s, or 12 + 24 depending on which gas, or both, you're processing.

Lithium
The story isn't very different for lithium-fueled crafts, except that Lithium, being a solid material is much denser than Argon and Xenon and that makes it better for crewed ion vessels. TWR is much better at the cost of Isp, and empowers heavy landers and even enables Duna SSTOs. I've made Argon-fueled SSTOs (in KSP 1.1.3) but those required very, very tedious mixing and matching of USI and NFT's reactors, karbonite scoops (to refuel themselves), and engines for sufficient dV and TWR. I don't know if it's still possible now. I haven't been at this kind of thing since KSP 1.2 arrived. Sometime perhaps I will post examples of a perfected ion-powered SSTO.

Near Future Propulsion adds Lithium modules to the stock drills and stock ISRU (and the ISRU of Kerbal Planetary Base System if also installed).

Here we have an Augustus-capable Lithium SSTO prototype. Since I always have Galileo's Planet Pack installed, I have KER set to Augustus, a moon, and it compares as follows:

• Augustus: 0.35g, 65km atmo, 350km radius.
• Duna: ........0.30g, 50km atmo, 320km radius.

The Garnet reactors have just enough cooling and this Lithium engine pairs it perfectly for EC flow. The 3 tons of Ore simulates precious cargo like LS resources. Full or empty, though, this craft can make it (however, it's not aerodynamically sound). When devising a Lithium-driven vessel and want to make your engine setup controllable, make sure to add this to your procedure:

1. Setup the reactor on its own stack and if possible, attach all the needed radiators to it.
2. Attach its complement engine and if necessary, nerf the engine so it doesn't drain more EC than is produced (this is only necessary for the huge engines).
3. Take that stack now and multiply it with symmetry until you get a satisfying number for TWR. This only really matters if you want to land or launch in atmosphere. With the prototype craft below, 2x is not enough and 4x is even better. But this isn't always the case. Diminishing returns are hard to avoid or control, especially when the payload fraction goes up from here.

Here's a mothership I launched from Minmus. It doesn't claim to be an SSTO but it had about 6km/s dV fully loaded and had some LFO and roughly 1.2km/s for its VTOL mode and a tiny chemical rocketed lander. it was rated for operation with the surface gravity of Vall which is greater than that of Mun. It also contained 3x Near Future's 8 ton Prometheus reactor and 6x 1.25m Lithium engines.

With the latest 1.12.4 update, SQUAD / Private Division decided to introduce an additional launcher to the game which will start up after hitting the "Play" button in Steam instead of launching the game directly. IMO this is rather annoying and doesn't provide any actual benefits, in fact, it actually causes some trouble especially for mods. Since the update, me and others figured out multiple ways to circumvent the launcher which come with their own benefits and drawbacks, so here are a few for you guys to choose from, depending on which solution fits the best for you

1. KSSL (KSP Simple Steam Launcher)

Pros:

• Easy to use
• You keep all the Steam features like the overlay, game time tracking, etc.
• Mods will work as usual

Cons:

• Need to be reinstalled if the game ever gets another update or you verify the games file integrity

@R-T-B wrote this wrapper which replaces the original executable of the launcher. Simply replace the "LauncherPatcher.exe" provided by them with the one from the stock game and you're already done and ready to go.

2. Change the game launch options (shortcut version)

Pros:

• Resilient to any further game updates
• Mods will work as usual

Cons:

• Steam features like the overlay and game time tracking don't work anymore
• Slightly more difficult to setup

Steam allows to setup individual launch options for each game, which can be used to redirect the target for the "Play" button in your Steam library. This particular solution by @Gotmachine redirects the button to point to a shortcut, which then again points to the game executable:

On 11/5/2022 at 8:50 PM, Gotmachine said:

Doing that will have the side effect of having KSP running from the wrong working directory.
In stock KSP, the only likely side effect will be that the KSP.log file will be generated in the "PDLauncher" directory, but this will definitely cause cascading side effects on various mods.

While you can specify a different executable in the Steam command line, you can't set the working directory, which is hardcoded to the "PDLauncher" directory.

This being said, the proper workaround is to have Steam pointing at a shortcut instead of KSP_x64.exe :

- Open your KSP root folder (In Steam, right click on the game > Browse local files). Usually this will be "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program".
- Right-click on KSP_x64.exe > Create shortcut
- Rename the shortcut to "KSP_x64_Steam"
- In Steam, open the game properties, and in the "Launch Options" field, put the path to the shortcut between quote, with  :

"C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Steam" %command%

This will launch the shortcut instead, with the correct working directory.

3. Change the game launch options (executable version)

Pros:

• Resilient to any further game updates
• "Purist" solution to keep the game 100% stock
• Steam features will work as usual

Cons:

• Mods are very likely to break
• Slightly more difficult to setup

So, this was the solution I came up with like an hour after the update but which turned out to be problematic later on. Works in the same way as the previous solution but instead of redirecting the "Play" button to a shortcut, it gets redirected to the games executable:

1. Right click KSP in your Steam Library
2. Click on properties
3. At the bottom of the "General" tab, you will find "Launch Options" and a text field.
4. Write in this text field "FULL GAME PATH TO .EXE FILE" %command%
5. Close the window
6. Profit!

for example:
 

The window is not resizable to show the full command but I guess you get it If you are having trouble to find the path to your game executable, you can right click the game in your library -> "Manage" -> "Browse local files". This will open up a window with your game files, showing the path at the top navigation bar.

4. The Kerbal Way (aka jump through three loops to accomplish.... "something")

Pros:

• Mods will work as usual
• Steam features will work as usual

Cons:

• Fairly janky to setup
• Not extensively tested
• A CMD window will be open as long as the game is running

This is basically a combination of solution #2 and #3 but instead of redirecting the "Play" button to the game executable or a shortcut of it, it gets redirected to the windows command line (CMD) which then is used to launch the game. Choosing this solutions allows you to eliminate the drawback of missing steam features from solution #2.

So, in order to achieve this, you need to follow the instructions from solution #2 but the command in the games launch options needs to be:

"PATH TO CMD" %command% /c "start PATH TO SHORTCUT.lnk"

The quotation marks are important, as well as using the ".lnk" extension at the end of the shortcuts name, even if it is not visible in your explorer window or part of the name you gave the shortcut.

The "PATH TO CMD" should always be the same in windows:

c:\Windows\System32\cmd.exe

The "/c" will pipe everything in quotation marks after it as a command to the CMD, so we are just telling it to launch the game via the shortcut.

In my case, the full command looks like this:

"c:\Windows\System32\cmd.exe" %command% /c "start D:\SteamLibrary\steamapps\common\"Kerbal Space Program"\KSP_x64_shortcut.lnk"

What about Linux/MacOS???

I dont use neither of those so I can only refer to the post of  @Nazalassa :

On 11/6/2022 at 11:47 AM, Nazalassa said:

[Still speaking as a Linux user]

Normally, in the KSP directory, there should be two executables: KSP.<exe/app/x86_64/whatever> and KSPLauncher.<exe/app/x86_64/whatever> .
Steam now launches KSPLauncher.{whatever} . To get rid of the launcher, the only thing to do is to find where the path to the executable is stored within Steam and replace KSPLauncher.{whatever} by KSP.{whatever} .

I can't say anything about pros and cons for this solution, not even if it works or details about the execution, sorry.

What about other launch options???

Other launch options like "-popupwindow" or "-force-d3d11" should still work as usual for any solution on this list. For solution #2 to #4, you can just add them at the very end of the command, for example:

"C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Steam" %command% -popupwindow

or

"C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64.exe" %command% -popupwindow

or

"c:\Windows\System32\cmd.exe" %command% /c "start D:\SteamLibrary\steamapps\common\"Kerbal Space Program"\KSP_x64_shortcut.lnk" -popupwindow

I hope everyone was able to find a solution which fits bets for their situation but if not, you're always welcome to ask questions right here in the thread. If any other solution comes up to fill up a niche, I'll happy add it to the list, same goes for linux and MacOS versions of the game. Also, any feedback is always welcome

The high gravity and thick atmosphere present formidable challenges to anyone that wishes to take on the challenge of returning from Eve surface. It requires a staged rocket a stunning 8000dv to even reach the low orbit. So, naturally the question comes to everyone's mind, if SSTO can use Kerbin atmosphere against Kerbin gravity, is there a way to use the EVE atmosphere against its dreaded gravity? As many have already proven, it is possible, but how does one build a craft that accomplishes that and pilot it safely into low orbit? 

And that is what I will try to explain here.

First of all, the Eve Effect.

Due to its gravity and atmosphere, even adding the payload by just a tiny bit, the amount of fuel and thrust power increases at a stunning rate. So, when building your first EVE SSTO, most of the weight should come from engines and fuel tanks, anything else should be minimized. One common theme among the Eve SSTO design is that the Kerbonaut is uncomfortably squeezed into a tine service bay with the tiniest probe core alongside a tiny reaction wheel. Another alternative approach to this is the Mk1 cone shaped command pod. It has space for 1 Kerbonaut, capable of storing data, a reaction wheel, and a tiny battery. Be sure to empty out the monopropellant if you choose the Mk1 pod. 

Weight management and resource management lies at the center of Eve SSTO. The desired result that everything is about just enough for things to function, and the only thing that doesn’t really contribute to the craft’s orbital entry should be the Kerbonauts on board.

In order to utilize Eve's atmosphere against its gravity, one must first understand the unique properties of Eve atmosphere. 

Generally speaking, based on altitude the Eve atmosphere can be divided into 4 parts. Each part has distinct properties which we aim to exploit accordingly. 

0m-15000m  the thickest of the thickest. High atmospheric pressure renders most rocket engines useless with the exception of KS-25 Vector, Mammoth, and the Aerospike. However, the smarter way is to completely forget about rocket engines. With Breaking Ground DLC installed, using propellers powered by electricity is by far the most efficient way to lift anything from sea level to 15000m.

15000m-40000m the atmosphere is still there, but it is only as thick as Kerbin atmosphere. This means that rocket engines used to lift craft from Kerbin sea level start entering the optimal range. While the usage of propeller starts to require larger and larger wing surface that will generate too much drag later on.

40000m-80000m the atmosphere is even thinner, with a thinner atmosphere, accelerating horizontally would face far less drag. LV-Nerv nuclear engines are starting to become Extremely efficient. Any other rocket engine pales in front of its 800 Isp.

80000m-90000m the atmosphere is almost non-existent. If your AP is above 100000m and your PE is within this range, the atmosphere will barely drag your AP back into the atmosphere. This is almost the equivalent of being in orbit.

In the First Phase, electric rotors and propeller blades are used to lift the craft from sea level to an altitude around 15000m. Rotors are best used in pairs; therefore, they can cancel out the torque generated on the craft. Rotors are like engines that don’t consume fuel, even if fuel cells are used to power them, no rocket engine can lift your craft to 15000m consuming less than 1000 units of fuel. They are the key to any Eve SSTO that doesn’t take off from the highest peak. Among all the setups, the R-25 propeller blade and the EM-32 rotor combination is the one that works the best. 8 blades symmetrically attached to the EM-32 rotor provide the best propulsion force while consuming a minimal amount of electricity. Another thing worth noting is that the weight of the rotors can be reduced at the cost of torque. Since we don’t need this craft extremely fast, the rotors can be set to 55-70 percent depending on the total weight of the craft and the wing area.

To optimize the propellers, it is crucial to bind the propeller blades to action groups to adjust the pitch angle. Pitch angle slowly goes up throughout most of the first phase. 16-15 degrees is good for takeoff, but a rather poor choice when the craft start to climb higher. If you’ve flown propeller planes very high in the Kerbin atmosphere, you would know that the last 2000m before reaching 15000m can be a long and somewhat annoying process. 15000m is just for reference, for some designs, 14000m is enough for entering the Eve orbit, for designs with larger wings, 16000m is the perfect point switching to rocket engines. This is a tradeoff. Larger wings and more propeller blades can bring the craft higher, but larger wings also generate larger drag. Larger wings and more blades also add to the overall weight. In my case, I picked 14500m as the target altitude for my first phase.

As mentioned previously, in order to use propellers, there needs to be electricity.

Any part used to generate the needed electricity is a part that provides neither lift nor thrusting power. Therefore, we want to generate just about enough electricity for the electric rotor and other components such as the reaction wheel. Solar panels are a poor choice to use, they have to be attached to the outer surface to generate electricity which adds drag to the craft, and it is usually somewhat cumbersome. Isotope rods can be safely stored away, but in order to generate the amount needed to power the whole craft, a combination of battery and isotope rod has to be used. Usually, upon reaching the 15000m mark, the batteries are almost out of juice. This approach requires one to properly time the rate at which electricity is generated and the rate of consumption so that one doesn't run out of electricity before reaching the target height or add way too much battery which is just extra weight, we do not want spend fuel on. Fuel cells can be a good idea, despite the fact that it consumes liquid fuel and oxidizer, but the amount it consumes is extremely low. In the case of my SSTO, the rate is barely 0.01 per second, It takes me about 11units of oxidizer and 9 units of liquid fuel, and that is negligible in comparison to all the fuel and oxidizer I have on board. However, once the orbit is reached, generating electricity using fuel cells becomes rather wasteful. In conclusion, the best option could be a combination of these methods. Solar panel + fuel cells or isotope rod + fuel cells are both viable paths to provide electricity to your rotors.

For wings, the options are rather limited. It must be able to withstand the reentry heating and has a rather large lifting surface relative to its weight. If it doubles as a fuel tank that is an extra perk to it (this will be explained later). This narrows us down to the two wings, both of them are from the Big-S Wing series. (This might seem pretty obvious to anyone who has built an Kerbin SSTO, but I want to make this article as informative as possible so that even beginners can learn too). 

As for control surfaces, Big-S tail fin is a descent choice, but it is way too big and heavy to be placed vertically. The Big-S Elevon on the other hand is a poor choice if one wishes to place it horizontally simply because it has a smaller wing surface relative to its weight (if you do the math 3.49/0.45=7.76 and 1.16/0.23=5.04, just for reference the Big-S delta wing has a lift to weight ratio of 5/0.5=10). So, for horizontal control surface, you actually want to use the tail fin, and for vertical control surface use the elevon. This conclusion seems counterintuitive indeed, but we cannot afford to have parts not optimized for their purposes. Another option for control surface is Advanced Canard. Despite its poor lift to weight ratio, it is extremely light. With such a thick atmosphere, the control surface doesn't have to be very large. Adv. Canard can serve as the perfect tail fin. (confusing huh? we are using these surfaces with complete disregard of their intended functions implied by their names).

The wings not only get us through the entirety of first phase, but wings also play extremely important roles in the second phase.

In the Second Phase, the main lifting force will come from wings and rocket engines. However, wings also have their negative effect known as drag, and this problem begins to manifest as the rocket engines accelerate the craft rapidly above Mach 1.  The amount of drag generated by wing is directly related to the wings’ angle of incidence and the surface area of the wings. But drag isn’t only generated by the wings, every other part on the SSTO can generate drag too and they don’t even provide any lifting force. So, it is better to have the wings angled rather than having the entire craft forming an angle of attack that generates drag everywhere along the craft body. As for a rule of thumb, 5° is ok to start with, but one really needs a mod, the Precise Editor, to adjust the angle of incidence to make the craft more aerodynamic. This angle can range from 1°-5° with most designs have this number lie around 2°-3°. I set the angle to 3.3°. This is another point where trade-offs are made. Greater angle means that the SSTO has a greater advantage during the first phase of the ascension, and it requires fewer wing parts which reduces the total weight; however, the drag is increased. A lesser angle of incidence has another advantage besides smaller drag. More wings can be a good thing when you need them to function as fuel tanks that generate descent lifting force.

 Whether the craft is aerodynamically optimal or not directly impact the success of any attempt to enter Eve low orbit. The main body of the craft should point prograde for most of the second phase to reduce drag. Mk2 parts are often regarded as the draggiest parts because their lift generating property comes with extra drag produced as a byproduct. I could not resist the aesthetics of Mk2 parts and placing them vertically would minimize the drag from these parts since they have stopped providing lift. Rotor and propellers must be stored away in cargo bays or service bays to reduce drag after using them to achieve the target altitude and the same goes for any other part that can be stored away. Faring is another option, but anything inside the faring will stay there until the craft is decommissioned.

No connection nodes should be left unprotected, even the rocket engines. Using a nose cone to cover up nodes on rocket engines and moving it away from the exhaust vent is an important trick to reduce the drag. The Mammoth engine is an exception because they have one connection node only and that node is already used to connect the engine to the rest of the craft.

Lift is the other factor from wings that comes into play. Ideally, there should be just the right amount of lift so that the craft will automatically pitch up when the SAS is set to prograde. The craft needs to accelerate horizontally for a while for this process to happen. Since this horizontal acceleration happens when the atmosphere is still rather thick (around 15000m) the shorter it is the better. A low thrust to weight ratio would extend this process unnecessarily long, making it very inefficient. But the craft also shouldn’t pitch too steeply. A steep ascension would mean that the engines are doing the bulk of the work. In order for wings to contribute sufficiently to this process, this automatic pitching process should not exceed 35° with 30° as an optimal upper bound. On one hand, a very steep angle also means that the craft is not accelerating sufficiently in the horizontal direction. On the other hand, a very shallow angle means that the SSTO has to combat the drag for a longer period. Once again, this is about trade-offs, and one has to weigh the various factors at play carefully. If the TWR is on the higher end, a steep ascension is perfectly fine, with a lower TWR, it is best to let the wings do more of that lifting. A greater wing pitch angle and a faster acceleration process will send the SSTO into a very steep climb. On the contrary, a lesser wing pitch angle and a slower acceleration will keep the craft in the dense atmosphere for a prolonged period. Thus, the wing pitch angle needs to be carefully adjusted according to the TWR of the engine.

Speaking of the TWR and the engines, their importance is second only to the aerodynamic features of your Eve SSTO. The smaller and lighter crafts often use the Aerospike. Medium sized crafts use Vectors or a combination of Aerospike and Vector to accomplish the same thing. Vector is more efficient when the atmosphere is denser, but the Aerospike outperforms against the Vector in fuel efficiency when the atmosphere is thinner. Their complementary qualities can be something very desirable when used simultaneously to power the craft. Mammoth is reserved for heavy or super heavy Eve SSTOs, rarely are they used in combination with the Aerospikes. One of the first Eve SSTO ever has been powered by those monstrous rocket engines. Designs utilizing Mammoth often have ISRU capabilities built-in to the SSTO. Both Mammoth and Vector has gimble capacities, this could come in handy since most Eve SSTO only has minimal reaction wheels installed. Most SSTO also need LV-Nerv to enter the orbit. Even though the thrust of LV-Nerv is among the lowest in game, its specific impulse exceeds the ISP of other engines by a long shot. Few Eve SSTO can achieve a dv around 5000 without using nuclear engines, and the one that fly without the nuclear engines are often equipped with the alternative option which is the Dawn ion thruster. Xenon, however, is not a resource that can be generated through ISRU means. Thus, by using Dawn the SSTO becomes more of a non-reusable craft. I personally think that this design is inherently in contradiction with the idea of using SSTO in the first place. In my case, I choose the combination of Vector, Aerospike, and Nerv to obtain a total vacuum dv of 5000.

The nuclear stage should never have more than 2000dv. Due to the low TWR of Nerv, it cannot burn that much fuel fast enough to complete the maneuver required to enter low Eve orbit. While in the second phase, the nuclear engine is still not optimal, but one should start the Nervs around 16000m. During this phase, it provides a small but, eventually, crucial amount of acceleration that will eventually send the SSTO into orbit.

One cannot simply add fuel to the craft to increase the dv of the stages. There is a point when the TWR of the main stage is simply too low to accomplish anything. The greater the TWR, the faster craft accelerates, and the shorter the amount of time is spent on combating gravity. Once again drag comes into play. If accelerates rapidly, the craft would have to combat extra drag. The lowest TWR around 15000m that I have seen is around 0.40, the highest I have seen is around 0.90, and my SSTO has a TWR of 0.60 at 15000m. The TWR essentially determines how the ascension profile should be tailored to maximize efficiency.

After discussing the wings and engines, I can finally go back to the “automatic pitching” process. The lifting force obviously comes from the wings, but there is more to it. The center of the lift and the center of the mass should be extremely close, a lot closer than any other aircraft intended to fly on Kerbin. Throughout the process, the relative position of these centers should stay roughly constant. This can be accomplished through simply balancing the fuel or using a more sophisticated fuel flow priority to establish sequence where the center of mass is unaffected by the burning of the fuel during the second and the bulk of the third stage. Initially, the craft has a positive angle of attack upon entering the second phase. The engine accelerates the craft so that the lift is great enough to initiate this process. By switching to prograde when the angle of attack is 0°, the craft would experience minimal amount of drag during this process. If this ascension were to be done in a manual manner, the drag generated in this process would make the SSTO highly improbable to enter the low Eve orbit. As the atmosphere starts to thin out, the craft will eventually lose the lifting force provided by the wings. This is what causes the craft to pitch down in the process. As soon as the thicker parts of the atmosphere are no longer affecting the craft, the angle should slowly go down, allowing the craft to spend more fuel accelerating horizontally.

Thus, we arrive at the Third Phase. At this point, the SSTO has successfully managed to get out of Eve’s thicker parts of the atmosphere. The goal is to accelerate horizontally achieving a target apoapsis height and a target orbital velocity before the main engines shut off due to the lack of oxidizer. I have personally established a few checkpoints to guarantee my ascension path. This is slightly different for every SSTO. Here are my checkpoints. 30° at 30000m, 25° at 40000m, 20° at 50000m, and eventually 15° at 60000m. Depending on the SSTO, this process might or might not happen automatically, but since the drag is getting smaller and smaller, switching to manual pitching wouldn’t create a whole lot of drag either. Feel free to adopt my checkpoints to begin with, and slowly adjust them through trial and error.

The main engines should shut off halfway through the third phase. Usually at this point it becomes very clear whether the SSTO has the potential of making it to orbit. There are some parameters that might help. Ideally, when the main stage is done burning, the craft should have an orbital speed greater than 2400m/s and an AP of at least 80000m. If the orbital speed is not high enough, the nuclear stage will not have the time to complete the burn and accelerate into a semi-stable orbit. If the AP point isn’t high enough, the nuclear engines can’t raise the AP high enough so that dense air wouldn’t slow it down preventing it from entering a semi-stable low eve orbit.

For the rest of the third phase, a common mistake is to raise the AP above the atmosphere and starting to make a maneuver node. Rather, click to show the in-game orbital info, and keep focusing on the PE and AP numbers. Since the Nuclear stage often has a low TWR, it is important to buy as much time as possible. Raise the AP point and make sure that there is plenty of time to accelerate during the fourth phase. The trick is to keep a positive angle of attack. I usually just leave the direction of the craft unchanged after I reach the 60000m checkpoint.

The Final Phase. This is the last phase to enter the low Eve orbit. Unlike other crafts, Eve SSTOs have a unique way of entering stable orbit due to the extremely low TWR of Nerv nuclear engines. As mentioned before, don’t bother setting up a maneuver node. If the AP is around 100000m, it is usually a very good sign. This indicates that it is very possible to complete the entry into orbit in one burn. Even if that is not the case, there is still a chance for a semi-stable orbit. A semi-stable orbit in the case of Eve has an AP above 90000m and a PE between 80000m-90000m. However, there is no guarantee that an orbit that satisfies these conditions will be semi-stable. A semi-stable orbit allows the SSTO to pass through the PE and re-exit the atmosphere. By burning again at the AP point, the PE can be raised above 90000m. So, do not give up just yet if the PE isn’t high enough, there is always a chance.

For the entirety of the final phase, keep a positive angle of attack. There is no definitive number as to how high the angle should be. In the most extreme cases, the AoA can be around 75° or even 85° towards the end of the burn. It is all about raising the AP and prolong the time to reach AP. The longer the craft stays above 85000m, the better. Nuclear engines should have plenty of dv at their disposal, all it needs is just a little more time to complete the burn. Quick save the game and practice a few times.

Changelog

GitHub
Check it for development, pull requests and other maps.
All required tools for map editing are referenced there.

How do I use it?
It's simple!
1. Pick a planetoid you wish to visit.
2. From your initial position, add up the numbers between every checkpoint until you reach your desired checkpoint.
3. The total is the general Delta-V value needed to reach your destination.

Example:
- Kerbin surface -> Duna Surface
3400+950+130+10+250+360+1450 = 6550*
*Aerobraking can reduce the needed dV to almost zero. Using it would result in the following: 3200+950+130+10 = 4490.
- Eeloo Surface -> Kerbin SOI
620+1370+1140*+1330* = 4460
*Aerobraking can reduce this number to almost zero.
*Numbers outside the stripes are the maximum dV needed to change between planets inclinations. Pay attention to them!

Elliptical or Low Orbit? What's the difference?
A Low orbit assumes a circular orbit 10km above the nearest obstacle/atmosphere.
Elliptical orbits have the Periapsis at Low Orbit altitude and the Apoapsis at the planet's SOI edge.
I added the Elliptical orbit checkpoint for two reasons:
          1. It shows you the required dV needed to get your vessel grabbed into the planet's SOI, disregarding the value needed to circularize on a low orbit.
                    1a. It assumes you have set your encounter to the lowest periapsis possible, during the encounter maneuver.
          2. If your destination isn't the planet, but instead, its moons, you don't need to count the whole dV needed to circularize around the planet's low orbit, since you won't use that. Instead, a simple capture/elliptical orbit is enough to transfer to a moon. That way, you can reduce the needed dV for a trip drastically.

I hope this helps. Enjoy!

License

This work is licensed under CC BY-NC-SA 4.0.

• You are permitted to use, copy and redistribute the work as-is.
• You may remix your own derivatives (edit values, design, etc.) and release them under your own name.
• You may not use the material for any commercial purposes.
• You must use the same license as the original work.
• You must credit the following people when publishing your derivatives in the material:
  • JellyCubes (Original concept)
  • WAC (Original design)
  • CuriousMetaphor (Original vacuum numbers)
  • Armisael (Additional vacuum numbers)
  • Kowgan (Design, original atmospheric numbers)
  • Swashlebucky (Design)
  • AlexMoon (Time of flight)
  • Official Wiki (Relay Antenna calculations)

--
This was originally a continuation from WAC's Delta-V Map from KSP 0.23. Since then, a lot of people (credits above + advice from people in this thread and over the internet) have contributed to improve this chart and keep it up-to-date with the latest KSP version. I am very thankful to all those who helped make this chart possible. Seriously, thank you guys.

This video tutorial will cover how to do a manual ascent to rendez-vous, in IVA (from the cockpit) ! : )

This part can be quite tricky, and almost as hard as an IVA landing, when done right !  

This part assumes you already know all the bits & bobs covered in the previous tutorials, which you can find below :

Feedback and questions always welcome !

Cheers  

(Author's note:  Please forgive the out-of-date screenshots.  This post is ported from a blog entry I made on an older version of the forum software, back in 2015, so screenshots reflect what KSP looked like at the time.  The appearance has changed a bit since then, but everything I wrote here still applies.)

The big picture

Docking proceeds in four main steps:

1. Rendezvous.
   • This is the part where you use maneuver nodes to arrange for your ship and the target to be in the same place at the same time, or at least as close as possible.
   • Careful fiddling with the maneuver node will generally get you a rendezvous within a kilometer or so.
2. Fine tuning the rendezvous.
   • This involves making small burns as you approach the target, in the last few kilometers, so that your closest approach is zeroed in to a few dozen meters (from the kilometer-or-so you got in step 1).
   • This involves close observation of the navball and light touches on the throttle.
3. Kill relative velocity to target, right when you're at your closest approach.
   • Also a navball-and-throttle operation. You're now parked right next to the target, just a few meters away.
4. Actually dock.
   • This involves eyeballing docking port alignments in the camera view (unless you have a mod installed to show docking alignment on the navball, which is a big convenience).
   • This is where you use your RCS thrusters to jockey for position.

The following sections go into detail on these steps.

Step 1: Rendezvous

Navigation tool: Maneuver nodes and map view
Control via: Main engine and throttle

The first thing you have to do is to send your ship on a course that will put it and the target in the same place at the same time-- or, at least as close as you can get with maneuver nodes.

I'm assuming here that you in fact have maneuver nodes (i.e. you've unlocked them by upgrading the tracking station), and also that you're familiar with how to use them.

I'm also assuming that you know how to set up a fairly good orbital rendezvous with maneuver nodes, i.e. one that will get you a closest approach within a kilometer or two. This is a big assumption: doing that is actually a significant challenge, and if you're a new player just learning how to dock, there's a pretty good chance you may not have mastered "orbital rendezvous with maneuver nodes" as a skill yet.

However, I'm not going into it here, for a couple of reasons:

• It's a whole complex topic in its own right, and this blog post is about docking rather than general orbital navigation. (I may add a "how to rendezvous" post at some time in the future, in which case I'll link to it from here. If my glossing over this part is frustrating, please let me know so that I can gauge demand. )  Here's a handy guide to rendezvous (not mine).
• The details of how to set up a rendezvous vary a lot depending on the starting situation (e.g. launch from surface to direct intercept, or two craft already in orbit, are their orbits coplanar or not, etc.).

But even though I'm not telling you how to do it here, I can show you what "good" looks like:



Exactly what your own situation will look like depends heavily on circumstances. But the important bit is that it's a close rendezvous. You want the closest approach to be as close as you can manage with the maneuver node-- no more than 2 km at most, preferably under 1 km. (In the above example, it's 0.3 km, which is pretty good.)

One more side note:

• See how the target (yellow) line and my own ship's (cyan) line are crossing each other like an X, rather than being close to parallel to each other at the point of intersect?
• That's actually pretty bad: it means that they're orbiting in significantly different directions at the point of intersect, which in turn means that they're going to have big relative velocity to each other, which means I need to burn a lot of fuel.
• I've done it that way deliberately, here, so that this guide can show you "how to dock" even if the situation's not perfect. Ideally, you will set it up better than this, so that their relative velocity at closest approach will be smaller, and therefore your job will be easier in the remaining steps.

Step 2: Fine-tune the rendezvous

Navigation tool: Navball and map view
Control via: Main engine and throttle

Your eventual goal (in step 3, below) is to coast to a stop so that you're parked right next to the target (as in, just a couple of dozen meters apart).

Chances are, however, that unless you're either super lucky or an ace at maneuver-nodes, the rendezvous that you set up in Step 1 above will only get you to within a few hundred meters at best-- perhaps a kilometer or two. You'd like to be closer than that when you match velocities, since your final approach (using RCS) will be very slow, just centimeters per second, and you don't want to have to do that for a kilometer or more.

So the way to solve that is to make minor course adjustments with light touches on the throttle of your main engine, using the navball for guidance. Here's how:

First things first: Make sure navball is in "target relative" mode

Once you get close to the target, you don't care what your orbital velocity is. You only care about your velocity relative to the target. Chances are, the navball is probably in "Orbit" mode when you're in orbit (the game does that automatically, unless you've manually tinkered with it).

Normally, when you approach your target within 60 km, the navball will switch automatically to "Target" mode instead of "Orbit": this causes your prograde/retrograde markers to indicate your target-relative velocity rather than your orbital velocity, which is what you want. It looks like this (note the "Orbit" or "Target" indicator at the top of the navball):



...Typically, it will do this automatically for you and no action is required on your part. I only bring it up because it's possible this might not happen, and you need to make sure that the navball is in "Target" mode, or nothing after this point will make any sense. You can change the mode manually by clicking on the label. This will toggle the navball between Orbit, Surface, and Target modes.

Why this fine-tuning step is needed

As you get within several kilometers of your target, your navball will start to look something like this (again, make sure your navball is in target mode):


This looks pretty good: your marker (target relative velocity) is pretty close to your marker (target direction). The fact that these two are close together means that you are heading almost directly towards your target.

However, the key word here is "almost". If you just coast towards your target and do nothing, you'll see the marker slide farther and farther away from the marker, like this:


That's because you're not heading directly at the target. Unless you got super lucky (or are an ace) with the original maneuver node, your closest approach is likely to be at least several hundred meters away from the target. This means that without any course corrections, you're going to go past it, and the target will slide off the side of your navball in the same way that someone standing beside the road slides off to the side of your windshield as you drive past them.

Therefore, you need to adjust your course when you get close by, so that you are sitting right next to your target (and not a kilometer away) when you come to a stop relative to it.

What to do

When you get reasonably close to your rendezvous (say, when it's 1 minute away, which you can see in the map view when you mouse over the intercept marker), start the process.

What you're trying to do is to move your marker so that it's precisely centered on your marker (i.e. so that you're heading directly at the target). To do this, start by lining up your navball so that your crosshairs, , and are exactly lined up in a straight line, like this:


Note that the marker is exactly on a straight line in between the navball crosshairs and the marker.

Why do we do this? Well, firing your engines "pushes" the marker away from the center crosshairs on the navball. Since what we want to do is move the marker onto the marker, then by lining the navball up this way, it will "push" the marker in the direction we want it to go.

Once you've got it lined up, gently throttle up to move the marker. How much throttle you need will depend on your ship's TWR and how big your target-relative velocity is. So just keep a careful eye on the navball, gently throttle up, and be ready to kill the throttle immediately when things line up.

As your engine burns, you will see the marker drift towards the marker, like this:


When the two markers line up perfectly, cut throttle. (Don't worry if it's not pixel-perfect; all that matters is that it's better than it was. If you're off by a smidgeon, what will happen is that as you get closer to the target, the two markers will drift apart again, and you can do this correction maneuver again. Repeat as needed.)


Prograde fine-tuning (if you end up too slow while still far away)

In the preceding discussion, we did all our fine-tuning while thrusting close to . I recommend this because it kills two birds with one stone, thus saving dV: not only does it fix our heading to get a close approach to the target, but it also helps kill some of our velocity (since we'll need to reduce that down to zero in the next step).

However, it could happen that you end up approaching too slowly while still far away: i.e. your target-relative velocity is very low while you're still at a long distance. In such a case, fine-tuning in the prograde direction is an option.  Details in spoiler.

Step 3: Kill relative velocity to target

Navigation tool: Navball and camera view
Control via: Main engine and throttle

This is the easiest part of the process, since there's little steering involved. All you have to do is slow down to a stop in the right place.

As you approach the target, line up your navball so that you're pointing perfectly retrograde (i.e. the marker is centered perfectly in the crosshairs-- again, make sure your navball is in target-relative mode, not "orbit"). If you have a level-1-or-better pilot, or if you have a HECS-or-better probe core, then this is easy: just choose the "hold retrograde" SAS button (red arrow in the illustration below). But if you don't have that convenience, just do it manually.


As you approach the target, the marker will want to drift away from center; if necessary, you can do more correction as described above in step 2.

Reduce your speed gradually as you approach the target. If you wait too long, you'll overshoot; if you start too soon, you'll go too slowly and it takes forever to close the distance. I find that a handy rule of thumb is "stay 30 seconds away from intercept": switch to map mode and mouse-over the intercept marker, which will give you a timer countdown to closest approach. Thrusting to slow yourself down will increase the time-until intercept. Just keep that at 30 seconds until your speed gets down to whatever you're comfortable with (I usually go for around 10-15 m/s), then switch back to camera view and you can eyeball it the rest of the way.

When you get really close, slow yourself to a stop, 0 relative velocity. You're now parked right next to the target-- if you got things lined up well up to this point, you'll be very close, just a few meters away, like this:

Step 4: Prepare to dock

Navigation tool: Navball and/or camera view
Control via: reaction wheels only

First, get roughly lined up. We need to get the docking ports at least approximately lined up (facing towards each other).

If possible, the easiest way to do this is to switch briefly to the target ship (using the [ ] keys) and rotate it so that it points its docking port towards your ship, then switch back and rotate your ship appropriately. This is a lot faster and easier than flying your ship around the target to get in the right spot, which is tedious.


(Sometimes that might not be an option, if it's not practical to rotate the target-- for example, if your target is a huge, massive, asymmetric space station with random stuff docked all over it. In that case you just gotta fly your ship to where it needs to be.)

Next, set your target and control-from to the two docking ports.

Right-click on the target docking port and choose "Set as Target":


Right-click on your own ship's docking port and choose "Control from Here":


Now, get your orientation precisely aligned. That is, you want the axis of your docking port and your target's to be precisely parallel. (They may be laterally offset from one another for now, but we'll deal with that next). There are a couple of ways to do this:

Option #1: Use a docking-alignment mod. My personal favorite is Navball Docking Alignment Indicator. It's very minimalistic, uses no screen real estate, stays out of my way when I don't need it. What it does is this: whenever your target is a docking port, it adds a red icon to the navball showing your alignment relative to it. When that red icon is perfectly centered in your navball cross-hairs, it means you're perfectly aligned for docking. So if you have this mod installed, all you have to do is rotate your ship to center that red icon. Your navball would then look like this:

...all you need to do is to rotate your ship to center the red icon in the navball crosshairs.

Option #2: Just eyeball the orientation. This is doable but less convenient. Not only do you generally have to monkey around with different camera angles, but it also becomes a royal pain in the dark, since you can't see what you're doing unless the ships are lit up. This is what I did for the first several months (and several hundred dockings) in KSP, until I got fed up and switched to option #1. Really, that mod ought to be part of the stock game, IMHO.

Either of the above two options will work. For the remainder of this discussion, I'll use screenshots that have the mod present, not only because that's how I do it when I dock, but also because it makes the screenshots much easier to understand.

Next, turn on fine-control mode. This is caps lock by default (on Windows machines; I think it may be different on Macs). Doing this will turn your control indicators at bottom-left from red to cyan, like this:

...The reason why you do this is described in another blog post, but what it boils down to is that it makes your RCS thrusters smarter so that it's easier to control your ship.

Next, activate RCS (press R). There, we finally get to use our thrusters!

Step 5: Dock!

Navigation tool: Navball and/or camera view
Control via: RCS thrusters

Okay, now the fun part.
Thrust gently prograde using your RCS thrusters until you get your speed up to 0.2 or, at most, 0.3 m/s. Slow slow slow. Your ship is now heading directly straight ahead. However, that's not quite right yet, since the target is offset to the side by a bit. We need to apply some lateral thrust in order to get us heading in the right direction.

Initially, your navball might look something like this:


How to read this:

• You're pointing in exactly the right direction: the red icon (from the mod I discuss above) is perfectly centered in the crosshairs, indicating that you're aligned correctly.
• Your position isn't quite right, because the target isn't directly in front of you. The is off to the left, instead of perfectly centered in the crosshairs where we want it.
• Your velocity isn't quite right, either-- the marker shows that you're moving up and rightwards as you drift forward, whereas your target is off to the left.

So now you need to use your RCS thrusters to correct that. Use your lateral thrust (IJKL for up, down, left, right) to nudge the marker to where it needs to be. You want to arrange it so that the marker is directly on a straight line between the marker and the center crosshairs, like this:

...What this means is that as you drift towards the target, you're also drifting sideways so that you're lining up with it. As you get closer, you will see the slide towards the center crosshairs. As it gets closer to the center, you can nudge the marker inwards, too (using RCS), still keeping it lined up:


When the marker reaches the center of the crosshairs, use RCS to center the marker there, too.


You're now all set up perfectly for docking:

• Centered red icon = you're facing the right way
• Centered = the target port is right in front of your port
• Centered = you're traveling directly towards it

Now all you have to do is just let it coast until docking completes.


Ta dah!

Today, we continue this tutorial serie for a Moon landing, fully manual from the start of the powered descent to touchdown, all from the cockpit (IVA).

This is one of the trickiest part of IVA flying, but one of the most rewarding for sure !  

Link to the previous/next parts of those retro-IVA tutorials :

Cheers

The answer is yes for Vanilla KSP as of 1.4.5.  You can "land" in the water by getting a craft to the ocean floor out beyond the limit of the shore biomes, and there are lakes or rivers for each of the major biomes that you can splash down in, and I'm going to list the coordinates for the latter below.  For an added challenge, in addition to getting the raw science by running and recovering the standard experiments, you can run the experiments, transport them back to KSP by any means of transport you like, and instead of recovering the experiments, launch them into orbit where they can be processed in a mobile sci lab for more sweet science.  (Or converted to reputation or funds via strategy, since science from the Mun or Minmus yields more science points for the same effort.)

Getting landed in water is just a matter of getting a craft to the ocean floor by making a submarine or a craft that's too heavy to float.  Ore tanks full of ore do the job nicely, and you can adjust the amount of ore a craft has at launch to greater than zero the same way you can adjust the fuel, oxidizer or mp in a tank.  You can also map the "jettison tank contents" action to an action group to dump the ore and regain buoyancy and return your sub to the surface.  Note air breathing jet engines can get oxygen from underwater... somehow...

I used a modified version of kantokris' Mini Submarine Mk 3.  I replaced the claw at the front of the craft with a materials bay studded with experiments, and added some detachable landing gear as a launching frame.  I'm not sure kantokris knew you could just start with full tanks of of ore, so you can possibly dispense with the drills and ISRU as well.

https://kerbalx.com/kandokris/Mini-Submarine-Mk-3

For added Kerbalness, if you can find a way to make your submarine a yellow one...

As noted above, splashing down in land biomes is just a matter of finding a lake or river that isn't a water or shore biome.  I find a supersonic science "dive bomber" works well here.  Create a custom waypoint with the Waypoint Manager mod using the coordinates below and fly towards your target.  Decelerate down to subsonic speeds and drop into the lower atmosphere once you get near your target, then kill the engines and go into a dive straight towards your target body of water.  Once you're under the 1000 m limit (ALL lakes and rivers are at a 0m altitude), deploy a buttload of chutes and fall gently down for a nice splash down.  Stall to get to a safe velocity before doing so if you need to.  (Doing the same with landing gear is handy for soft landings with planes is rough terrain as well, FYI.)  In two cases, there are several biomes available in the same body of water a short distance away from each other.  You can also deploy landing gear in the water and use some low power jet thrust to get your plane up safely onto the shoreline, but make sure you aim for a gentle slope before trying this.  If your plane has a probe for flight control and only one seat, you'll have to choose whether you want to send a scientist (cleans experiments for more than one result), or an engineer (repacks chutes for multiple landings).

Below are the coordinates for each biome's splash down location, thanks to the chaps in this thread for helping me find them.  Note that you can customize MechJeb's surface info window to add the surface biome your craft is in or over.  If you have the ScanSat mod and want to try and find some locations yourself, look for locations with the target biome that have an altitude of less than 0m.

Shores: You really should be able to work this out for yourself...

Grasslands: 3°56'45" S 83°40'53" W

Easily reached by going S/SE along the coast from KSC.

Deserts: 2°25'7" S 87°34'5" W

Near the west coast of the KSC continent opposite KSC, over the southern edge of the mountain range.

Highlands: 47°21'13" N 140°3'52" W

This and the nearby mountains are probably the only splash down locations for their respective biomes.  This is in the river system on the large area of grasslands and highlands north of Baikanur and the great desert.  Splash down in the river near the target coordinates and cozy up to the cliffside on the western edge.

Mountains: 47°28'17" N 140°4'24" W

Just north of the above highlands splash down point in the same river.  Cozy up the west edge of the cliff again.

Badlands: 17°50'27" S 30°19'23" E 

This is probably the nearest Badlands lake to KSC, but it's a bit of a pain to taxi back out of owing to the steep banks, if that's what you want to do.

Tundra: 70°39'59" N 100°56'43" W

Mostly a straight flight north from KSC, this is a very big lake that's easily visible from orbit.

Ice Caps: 70°59'32" N 99°5'21" W

In the exact same lake as the Tundra biome above, easily reached by splashed down taxiing.

Northern Ice Shelf: 70°59'33" N 99°2'14" W

As you get close enough to the near vertical ice cap wall on the eastern edge of the lake, you transition from splashed down in the ice caps to splashed down in the northern ice shelf.  This is arguably buggy, and you can get this splashed down biome "fairly" by splashing down in the ocean just south of the edge of the ice shelf and then taxiing up to the vertical shelf.

Southern Ice Shelf: 74°39'43" S 57°31'9" W

Pretty much head south from KSC over the sea, and splash down near this point in front of the southern ice shelf.  There are other places in a more direct line from KSC where the ice shelf biome juts out into the sea, but this one is conveniently located near a beach if you want to get your craft back up onto land.

Have fun exploring, FOR SCIENCE!

Which involves the usage of that bloody X-pointer instrument...   

Looks overwhelming at first, but in the end allows for very precise and smooth dockings to be made, and is also so damn rewarding and fun !

Link to the previous/following parts of those retro-IVA tutorials :

Questions/feedback welcome   

Cheers

This is the continuation of the first part of the tutorial serie (spoiler below) about flying retro styled IVA spacecrafts, this one will focus on the DSKY usage, as well as a rendez-vous guide, instruments only !

Previous/following tutorial parts :

Feel free to ask any questions or provide feedback : )

Cheers  

All needed parts are on the ground. Station, RTG, communication, experiments. Literally nothing works.

I tried looking online but this DLC has been pretty much ignored.

I don't understand why this has to be so complicated.

- Ever wonder how much science you can get from Ike compared to Jool? (Ike has more, and is easier to get to)

- Is a Gravity Scan in Low Space over Minmus per-biome or global? (per-biome, but you knew that)

- Did you know that you can get more Science Points from Kerbol (The Sun) than all the biomes on Kerbin combined? (yep, 'tis true)

This spreadsheet shows every biome on every celestial body, which experiments are valid in each one, and how much science you will earn from performing the experiment. All of the information was taken from the Wiki and various forum posts.

Using a dropdown box, you can choose to display values for returning experiments to Kerbin, for Transmitting them, or for processing them in a Lab.

I'd be happy to hear suggestions for improvement, and PLEASE do point out any mistakes you find so I can correct them.

Screenshot:

Downloads:

Latest version: 1.3 (8/15/14)

Excel 2013 format: https://www.dropbox.com/s/jyx2m7x1xw39wb5/KSP%20Science%20Chart.xlsx

Excel 97-03 format: https://www.dropbox.com/s/3fh845tfdhzfh24/KSP%20Science%20Chart.xls

OpenOffice format: https://www.dropbox.com/s/qg0szytmzot919c/KSP%20Science%20Chart.ods

PDF format: https://www.dropbox.com/s/jz78nribdm1w77b/KSP%20Science%20Chart.pdf

Note: I have removed the v1.X suffixes from the filenames, so that I don't need to generate new Dropbox links every time I update the files, and I added a "Version" field at the top right corner of the spreadsheet

Updates: 8/15/14 Fixed highlighting, removed several unobtainable surface biomes from Moho & Gilly

Basic Layout 

A conventional helicopter generates lift with a single main horizontal rotor, which produces a torque known as reaction torque. The vertical tail rotor produces thrust opposing this torque. This prevents the body of the aircraft from spinning, also known as the stator.

 
Helicopter Size 

The three sizes of helicopter blades differ greatly in performance and flight dynamics.

Large blades seem to have disproportionately more drag and although providing more lift, higher airspeeds are usually unreachable due to said drag and instability. Furthermore, greater blade mass puts additional strain on the rotor system. Stretching robotic joints and attachment nodes, which exacerbates lift and yaw instability.

Small blades are often too close to the centre of mass in the horizontal axis, which contributes to cyclic/input instability; due to a bug/game limitation. I recommend building a medium sized helicopter at first, to avoid the inherent problems that come with the small or large blades.

Collective 

Collective pitching of the main rotor blades produce lift and control altitude. When configured correctly, the collective pitch should be bound to the main throttle group with the use of a KAL-1000. Helicopters don’t generally incorporate negative collective pitch but in Kerbal Space Program it’s helpful when descending and also to successfully autorotate. 

Set blades to deploy and set the blade deploy angle to 0 in the right click menu. This ensures the rotor does not produce lift before fully spooled. 

Reduce the play-speed of the KAL-1000 to make collective throttle proportionally slower, as rapid changes in collective may have undesirable effects on pitch stability.

When setting the KAL-1000 deploy angle limits, stay within the stall limits of the rotor blades. I recommend between -3, +12 (for medium blades)

Cyclic 

Cyclic is the differential pitching of the rotor blades throughout the rotational cycle (advancing/retreating). This reduces and increases lift on opposing sides of the rotor disk. This provides control in the pitch and roll axes. 

On the main rotor blades, enable pitch and roll and disable yaw. 

High blade authority angles can reduce overall lift during intense manoeuvres. This causes blades to exceed their stall angle, resulting in a rapid reduction in lift/altitude. I recommend between 1 and 3.

Counter-Torque

Thrust from the tail rotor prevents the helicopter spinning, known as counter-torque. The tail rotor, also provide yaw authority or control in the yaw axis. Manual control of counter-torque is quite common and often trim is used to find the neutral point. Although it is possible in Kerbal Space Program, manual control of the counter torque is very difficult without a flight stick or H.O.T.A.S. 

Helicopters’ mechanically couple the main rotor torque to the counter-torque rotor, also called mixing. 
To couple collective pitch and the counter-torque rotor in Kerbal Space Program, add blade deploy angles for both the main and tail rotors to a KAL-1000. It may also be possible to simulate torque-coupling or mixing by adding tail rotor torque in place of the blade deploy angle to a KAL-1000. 

In the propeller/tail-rotor graph, evenly distribute points along the timeline. 

Build a rig using launch clamps and free spinning rotors; in order to roughly tune the counter-torque on the ground. Then, in-flight precisely tune the counter-torque. Later copy these settings to be saved in the SPH (editor) Again, set blades to deploy and this time, set the tail rotor blades deploy angle to the neutral angle found during tuning. [craft v1.4.1 update: Retuned counter-torque in-line with adjustments to the tail height.]

Finally, disable pitch and roll, and enable yaw. 

Engines

As mentioned earlier, Kerbal Space Program has a critical limitation in relation to control surfaces (rotor blades) orientation and distance from the centre of mass. To avoid complications with cyclic inversion/mixing, use a medium or large rotor hub to properly space the blades.

To create a reliable start-up sequence. Add rpm and torque limits for the main/tail rotors to a KAL-1000. Set the rpm/torque values as required, adjust the graph curve and reduce play-speed for a gradual spool up sequence. 

Although, directly adjusting rpm in-flight is not common, managing torque to regulate rpm is. To simulate this functionality, add the main rotor torque limit to a translation action group for in-flight adjustment.

I recommend binding play-sequence/set-forward-direction to the stage action group for engine start-up and play-sequence/set-reverse-direction to the abort action group to shutdown.

Spin Direction

Single rotor helicopters are inherently asymmetric and come in two configurations; clockwise or anti-clockwise spin. The highlighted colours on the top surface and silver leading-edges seen on rotor blades, indicate the direction of spin.

Lift Asymmetry

The effect of asymmetry on lift is known as “dissymmetry of lift” or the difference in lift between advancing and retreating blades in relation to the direction of travel. 

Dissymmetry of lift is responsible for the continuous roll instability experienced by all single rotor craft. This imbalance, even when properly compensated for, will at the absolute limits of a helicopter's high-speed flight, result in a fatal uncontrolled roll.This phenomenon, a roll towards the retreating blade side is known as a “retreating blade stall” and a stall on the advancing blade side, is known as an “transonic stall”

Gyroscopic Precession

The effects of gyroscopic precession, will cause any force acting on the rotor disk to be offset by 90°. With the exception of blade deploy angles which are calibrated relative to the centre of mass within Kerbal Space Program.

Dissymmetry of lift however, is subject to the gyroscopic effect. The imbalance of the advancing/retreating blades imparts a force on the retreating blade side, which offset by 90°causes a pitching moment about the centre of mass. This effectively raises the nose of the aircraft, returning it to level flight.

Static Stability 

To achieve static stability, a helicopter needs to compensate for the effects of dissymmetry of lift and gyroscopic precession. This is done through a combination of flapping and feathering hinges built into the rotor assembly. 

[youtube]

When pitch/roll are carefully balanced, the helicopter will be stable across a range of dynamic flight regimes, and retain control authority in extreme bank angles and at high speed.

Pitch Stability 

As with fixed-wing aircraft, helicopters longitudinal stability is affected by the relative position of centre of mass/lift forward and aft. 

Helicopters are exceptionally sensitive to changes in mass, but when balanced will fly straight and level for some distance. For a basic design, having the main rotor centred directly above centre of mass is preferred but more advanced helicopters may position the main rotor slightly forward or aft. 

The addition of a vertical tail rotor inhibits the usefulness of the centre of lift overlay in the SPH (editor). Instead, reference the main rotors' centre of spin as the true centre of lift. 

Cyclic Authority 

Cyclic Authority is the ability to control pitch and roll. The height of the main rotor relative to the centre of mass determines the degree of control; although not exclusively. (higher, more authority and lower, less authority)

The tail rotor (in addition to the main rotor) has a massive influence over roll stability. Its height relative to the centre of mass determines the roll bias of the helicopter; either neutrally stable or with a left/right bias. The influence the tail rotor has on roll changes across flight regimes and at differing airspeeds. The addition of feathering, flapping and hunting hinges/rotors help to equalise any bias or changes that might occur at differing phases of flight/airspeeds.

Any changes to either the tail rotor or main rotor will drastically affect cyclic authority and overall static stability, so take care when adjusting. [craft v1.4.1 update: I raised the height of the tail significantly. This required a slight retune of the counter-torque and the left-roll bias had to be accounted for, with changes to the roll-angle of the main rotor and feathering/flapping hinge settings.]

Fully Articulated, Semi-Articulated and Rigid

A fully articulated rotor system has three axes of blade articulation: feathering, flapping and hunting. Each blade can move independently in each axis. 

A semi-articulated system usually has two axes of articulation: feathering and flapping. Often blades will only be independently articulated in a single axis (feathering), and mast-articulation will make up the other axis (flapping). Less commonly, a semi-articulated system will have three axes of articulation, for which mast-articulation would make up at-least one.

A rigid system has zero axes of articulation. Instead rigid rotors often use flexible blades in place of hinges. Rigid systems will also sometimes include a stabilising fly-bar. 

Rotor blades in Kerbal Space Program are not flexible, so a statically stable rigid system is not possible. This leaves two options: a fully and a semi-articulated system. Building a system strong enough to withstand rotational forces is essential. Unfortunately however, due to the strength limitations of the robotic parts, assembly options are even more limited and a fully-articulated system is unlikely. 

Therefore, I recommend a two hinge semi-articulated system, with mast-hunting. More than two hinges can result in a significant amount of robotic drift, making their use  impractical. 

Note. 
Most articulated helicopters will also have an articulated tail rotor, with independently articulated blades to allow feathering and flapping. This ability compensates for dissymmetry of lift across the tail rotor and equalises out the counter-torque thrust.

Feathering 
Feathering is the blade twisting about the chord length, changing the pitch angle. The advancing and retreating blades are free to move in the pitch axis, which actively compensates for dissymmetry of lift. Working in conjunction with flapping and hunting, feathering absorbs torque generated by the collective and cyclic. During an autorotation, a slight negative pitch helps to sustain rotor rpm, storing energy for the descent.

Flapping
Flapping is the up and down motion of the rotor blades. This movement allows blades on the advancing side to flap up, reducing lift and down on the retreating side to increasing lift. This contributes to a reduction in dissymmetry of lift. Cyclic authority is improved by the addition of flapping, as the rotor disk is able to tilt in the direction of travel. This dampens gusts that would otherwise disrupt the static stability of the helicopter (KerbalWeatherProject) and or rapid changes in direction; which would increase drag and reaction-torque. 

Hunting
Hunting is the leading or lagging of the rotor blades or rotor system, adapting to changes in torque. Additional drag on the rotor system generates more torque, which is then dampened and prevented from transmission to the stator. This works dynamically at different airspeeds as drag is increases. Usefully excess counter-torque forces can also be dampen; allowing the tail rotor to operate at a higher thrust.

Hunting can also become saturated which causes a phenomenon known as the speed wobble. This occurs shortly before rapid aerodynamic instability and is a helpful warning to reduce speed.

How to build a semi-articulated three axis system!

Once the basic layout of the helicopter is worked out. Add three robotic components: two small G00 hinges and a single F12 rotational servo.

[update: Found a simple alternative to rotor hinges. By using a single grip pad in place of the G00 hinges. One grip pad can provide enough movement, to effectively do the job of both the feathering and flapping hinges. I recommended using rigid attach for the blades, and grip pads. Also, strut between the rotor hub and the rotor-blades as before; to provide strength. The rotor-blades are more prone to spin separation/drift but offsetting parts can help with this issue. The counter-torque will also require a retune to account for altered main-rotor loading. However, overall, this alternative is about 80-90 as effective, as separate hinges. Top speed is reduced and  fly characteristics are significantly different.]

Mast-hunting
Attach the F12 rotational servo under the main rotor to provide mast-hunting, allowing the entire rotor system to lead/lag. Set the F12 to its maximum power output and a traverse rate of at-least 1.0. This will allow torque-transmission to the stator. 

I recommend reinforcing the connection between the F12 servo and the stator (fuselage) with struts. Robotic drift under load will cause the entire rotor system to stretch and compress; however, strutting both sides will prevent rotation, nullifying its usefulness.

Flapping and Feathering
Next, attach both sets of G00 hinges between the rotor hub and blades. One set will provide flapping and the other feathering. 

Flapping hinges are fairly simple. They allow the blades to move up/down. Set power output to maximum, traverse rate to maximum, target angle to 0.0 and the angle limits to -1.0,3.0, biasing the angle limit in the upward direction. [craft v1.4.1 update: settings changes...  angle limit -2.0,2.0, target angle 0.0, traverse rate 2.0, motor size & output 0.00. This accounted for a heavier left-roll bias and effectively increased level flight top speed by 10mp/s (to 60mp/s) and high-speed stability.]

Feathering hinges are a bit more complex. Use the rotation and translation tools to orient/centre the hinges, such that they can twist about chord-length, in the blades’ pitch axis. Set the power output to 10%, traverse rate to maximum, target angle to 0.0 and the angle limits to 3.0,3.0. [craft v1.4.1 update: Settings changes... angle limit -2.0,2.0, target angle 0.0, traverse rate 1.0, motor size & output 0.00. This accounted for a heavier left-roll bias and effectively increased level flight top speed by 10mp/s (to 60mp/s) and high-speed stability.]

I do not recommend the use of rotor-servos for high drag applications, as they seemingly experience more robotic drift than hinges. Although they do work for low drag applications, as on Duna. 

Struts
Finally, add struts between the rotor hub and blades. The minimum angle limits of hinges are actually more coarse than the minuscule angles required. 

Using struts successfully reduces their range of motion and prevents too much flapping, which would destabilise the helicopter. This extra stiffness also increases overall cyclic authority. 

Airframe Aerodynamics 

Static wing surfaces will have minimal impact on stability during low speed flight but throughout differing flight regimes, they can be used to make the helicopter dynamically stable; even partially compensating for dissymmetry of lift. 

An asymmetric tail plane angled up on the retreating blades side, will lift the tail and lower the nose. Resisting the helicopter's tendency to level out at high speed and roll in a retreating blade stall. 

Rotor Bias and Autorotation

It is possible to bias the main/tail rotors’ for high speed flight, to assist auto-rotation or for dynamic stability in conjunction with the static airframe. In both cases changing the main/tail rotors' leverage over the centre of mass or rotating them about the pitch/roll axes.

[youtube]

Main Rotor 

Translating and rotating the rotor forward and aft will impact the longitudinal stability or pitch stability.

Translating and rotating to the left or right will impact lateral stability or roll stability. Bias in the longitudinal axis can help keep the nose down. Bias in the lateral axis will compensate for a retreating blade stall, lateral drift caused by thrust from the tail rotor and mitigate a death-roll during auto-rotation. [craft v1.4.1 update: Tilted the main rotor roll-right toward the retreating blade side, in order to eliminate side slip caused by the tail rotor thrust. This is only possible due to the angle and height of the tail-rotor; which is heavily biased left-roll towards the advancing blades side. Also, the feathering and flapping hinges had a settings change to allow more freedom of movement in the rotor system to account for this bias.]

Tail Rotor

Translating and rotating the rotor in the vertical axis will impact lateral stability or roll stability. Translating and rotating through the horizontal axis will impact yaw authority. Adjusting the height of the tail rotor will bias roll stability at low-speed (unstable) and compensate for a retreating blade stall at high-speed (stable). [craft v1.4.1 update: The vertical tail and rotor were tilt as seen in the imagine bellow (formerly straight vertical) this was to account for the main-rotor adjustments.]

Rotating the tail rotor like the above imagine, reduces the bank angle needed, to prevent side slip caused by the lateral thrust of the tail rotor.

These changes are usually made at the expense of low-speed stability. However, the use of three axis articulation increases the envelope where the helicopter remains statically stable, working in reverse to compensate for bias and enable a dynamically stable design. 

This capacity for damping forces, can allow for an increase in counter-torque thrust at the high end of the collective throttle. The addition of mast-hunting dampens the effectiveness of the counter-torque at low speed, when drag on the main rotor is low and at higher speeds when drag is high, releasing its full potential. This only works because the hunting servo can become saturated.

Some bugs to be aware of…. 

• Cyclic mixing/inversion, when rotor blades are too close to the centre of mass/centre of spin.
• KAL-1000’s can bug out, if attempting to bind the authority limiter and deploy angle.
• Excessive uncontrollable roll. Occurs across multiple craft saves. Is unaffected by reverts and most unfortunately looks exactly like the effects of dissymmetry of lift on helicopters. I believe it’s related to the memory leak Kerbal has and the only known fix is a complete game restart.
• Node strength and robotic drift really limit helicopters. (I really wish Squad had implemented a set of helicopter specific hinges)

Final note. 
It is my opinion that the drag configuration of all rotor blades is excessive and is the root cause for a lot of helicopter related bugginess. 

Here's a extensive tutorial on the usage of the FDAI, found on most of the retro-style modded KSP IVAs.

That great instrument flew on Gemini, Apollo, the Space Shutlle, and is still used today !

Following tutorials of this serie :

Feel free to ask questions or provide any type of feedback : )

Cheers

For IVA enjoyers out there, I made this tutorial which covers a full flight only IVA launch, rendez-vous & docking to space station, then landing back at KSC runway, with a SSTO.

IVA is in a retro style, so no much fancy displays, only manual piloting !

I hope you find it useful ! Also feedback and questions appreciated   

Notes : 
* Always match your inclination first with your target before doing the Hohmann transfer burn, I didn't tought about it since I knew the station was in a equatorial orbit, but still, the small deviation from my initial orbit trajectory was enough to make the rendez-vous phase trickier, as you'll see.
* 21:14 : velocity relative to the targeted docking port but only in the X and Y axis.
* 22:45 : I didn't mention it, but on this IVA, the screen display actually shows X, Y axis distance and vel in precise numbers, which is very practical, as well as the X, Y, Z rotation angle. it's a numerical aid to the instrument to the right, which is more visual.

When KSP 1.8. came, using Unity 2019, my old Mac Mini 5.1 (i5, 2 cores, 4 HyperThreads) didn't handled it. I just could not fire up KSP and keep the machine useable - the whole thing started to stutter. Facebook, Youtube, command line terminals, you name it. Everything were stuttering, it was impossible to watch a video!

Since I was going to buy a new old rig anyway (that by pure chance ended up being an Mac mini 6.2 - 4 Cores, 8 HTs), I didn't gave it to much attention. The new old Potato ended up handling KSP >= 1.8.0 and that allowed me to keep using it for development (besides KSP 1.7.3 still being way more performatic, being the reason my main playing is still 1.7).

And so KSP 1.12 came, and screwed everything again: KSP 1.12 did to my Mac Mini 6.2 what KSP 1.8 did on the 5.1 . Krap.

Oh, well. Life goes on. I still can run KSP 1.12 for some "quick" and small tests and use 1.11 for the main workload until I figure out a way to buy yet another new old potato.  

But then I realized I made a less than ideal decision making on a thingy called Refunding from KSP-Recall. At that time, I had pretty little time to fool around and made things the fast as I could in order to work around the problem under my nose, rushed the thingy into the Mainstream and gone back to day job, and by doing this I ended up bullying the GC. I then optimised a bit the memory usage, but the bulling just would not stop. It ended up being (another) bug on KSP that was causing a memory leak, that was triggering the GC a lot, that was being sabotaged by spinlocks on the waiting threads!

Checking the worst processor hogs on the KSP's process, it came to my attention that almost 100% of the CPU time was being used on a system  call related to Semaphores inside an Unity thread, the dispatch_semaphore_wait_slow that by itself was spinning around os_semaphore_wait that by its turn was calling semaphore_wait_trap.

Interesting. Checking the other threads of the KSP's process, I got horrified!

LOTS AND LOTS OF THREADS hogging up 100% of the CPU, a clear indication of busy waits!

It's not a surprise Refunding was provoking a memory leak - there're so many threads busy waiting for the GC that there's no CPU left for the GC itself, and so we have a dead lock!!!

Every single thread, including OSX HID Input (Human Interface Devices) are boggling the CPU at 100%! It's evident now why the input is so sluggish when your crafts gets to big for your rig!!!!

Digging a bit more on the subject around the Internet, I came to a Swift code like this one:

        if (mutex_sem != 0)
            kr = semaphore_wait_signal_trap(cond_sem, mutex_sem);
        else
            kr = semaphore_wait_trap(cond_sem);

What explains a lot - semaphore_wait_trap is used without a mutex, and so somebody somewhere is using a spinlock to do the job - you know, we need to synchronize things between threads, right?

Remembering a very productive exchange with @darthgently, I decided to use one of the tricks he taught me, the MONO_THREADS_PER_CPU environment variable. It tells mono to, well, limit the number of threads per CPU.  

By limiting this number, we would have less spinlocks on the process, and so the poor CPU would have a better chance to do its job instead of spinning around the same code waiting for something that will never happens because the CPU is being completely screwed up by the waiting threads.

Since I'm on a UNIX machine, this is what I did:

The command MONO_THREADS_PER_CPU=1 ./KSP.app/Contents/MacOS/KSP will set the environment variable and then call the executable `KSP`. On exit, the environment variable will be lost, so no chance for it to linger and end up screwing up some other process you call later.

And that, my friends, solved the problem for me. My old Mac Potato 5.1 is now able to run KSP 1.8.1 . Barely, the game is still slugish but the rest of the machine is useable! I can even watch Youtube videos while running KSP 1.8.1, something that was impossible for this machine 17 months ago!

My less old Mac Potato 6.2 managed to withhold some more abuse from KSP 1.8.0 to KSP 1.11.2 because it have twice the cores of my previous rig, but now on KSP 1.12.0 someone increased the default number of threads per CPU again (or something similar) [edit: see note below], and it screwed up my i7: there's no point on increasing the working threads with spinlocks, all you will get is more threads waiting for something that will never happens because your threads are preventing everything else to run!

Note: Since the last time I revisited this article, I managed to diagnose the reason KSP 1.12.x screwed up so badly my punny Mac Potato 6.2: THE TEXTURES. Squad essentially quadrupled the VRAM footprint and this completely wrecked my GPU, as it has a maximum of 1536MB of VRAM. By manually shrinking the textures sizes to a quarter of the original size (more or less the sizes on the KSP 1.5 era) KSP 1.12.x behave nicely on my rig! More info on this thread.

Aftermath

Right now, I'm being able to run KSP >= 1.8 on my oldest rig by using this trick. I'm trying now to figure out the best compromise of threads for my rig (2 appears to be acceptable, I will try 4 on my next time window for this). I'm pretty confident that a similar trick will "solve" the issue for my less older Mac Potato, so soon I'm be able to test drive things (and diagnose problems) on KSP 1.12.x, something that until now I was not able to do properly.

These hacks are not solving the bad performance of KSP itself, besides it is getting slightly better (or less worse) too. What will solve the problem for good is using MUTEXES instead of spinlocks, and this is something I do not currently know if it's doable by options or environment variables.

I will update this article with my findings as they happen.

Addenda

On KSP 1.7.3

Out of curiosity, I fired up KSP 1.7.3 (Unity 2017) and inspected the process the same way I did on KSP 1.8.1:

We still have lots of threads screwing up the cores with semaphore_wait_trap, but we also have some others that don't!

Some unnamed threads are using nanosleep, and the OSX HID Input one is using mach_msg_trap.

We have now good evidences that my thesis have teeth.

On KSP 1.3.1

On KSP 1.3.1 (Unity 5) I got similar results!

It worths to mention that KSP 1.3.1 and older are simply the best performatic KSP versions on my i5. Point.

I think we have a pattern here. Unity is (ab)using dispatch_semaphore_wait_slow on Version 2019, and this is royally screwing KSP on anything not top notch (and probably hindering top notch machines as they would probably perform better without this mess).

Conclusions

Besides being a Bad Move™ (and Unity would have better results on the field without using that kind of stunt), what's really screwing up things is not necessarily the spinlocks, but using them where a proper MUTEX is really mandatory. The HID Input thread appears to be one of them, at least.

I think it's more than due time for Unity to start getting their excrements together and do things right. For a change.

This article is also published on my site.