Tutorial:How to Play/zh-cn

欢迎来到我的Kerbal太空计划教程（译者注：这篇教程的原作者是Quizzical，如无特殊注明，本译文中的第一人称用语均指原作者本人）。在撰写本文的时候，游戏的最新版本是1.10.1，本文亦是针对于该版本编写的。本文假设读者拥有全部的DLC，但没有安装任何模组（mods），因为很显然的，模组可以对游戏进行很大的更改。

在本Wiki和其它的地方已经有很多非常优秀的教程了，为什么我们需要另一个教程呢？古人云：“长江后浪推前浪，浮事新人换旧人”，互联网上能够找到的大部分Kerbal太空计划的教程已经非常的陈旧和过时了，虽然本教程在未来的某日也终将变得过时，但我们总是需要新旧交替，用新的信息来更新旧的信息。

本篇教程还会着重于大多数教程都没有涵盖的两件事：首先，冗长的零件列表可能会使新手感到困惑，我会系统性的介绍所有主要的零件类型，并且解释他们的用途。

其次，本教程将比大多数其它教程更加着重于数学和物理。但先不要急着逃跑！这并不意味着冗长的代数导数，我会写下一些公式，但并不真正使用他们。不过，这的确意味着讨论古典力学的三大能量守恒定律，解释一些零件在现实生活中如何工作，并且定义足够的线性代数术语来让你以正确的方式思考。

局部空间内的移动

大多数游戏中，最为基础的活动之一是四处移动。你可以向上，下，左，右，或者任何方向移动来前往你要去的地方。但我们即将看到，在轨道上的不同时刻向同一个方向移动可能会让你到达完全不同的位置。这就是为什么这一章节仅涉及局部空间内的移动，而稍后的章节里我们会讨论在全球范围上的移动。

动量守恒定律

让我们首先从一些基本的定义开始。你的速度（velocity）描述你移动地有多快，这是一个三维的向量（vector），它既包含你移动的速率（speed），也包含你移动的方向。速度总是相对于某个参考系的，比如，在驾驶一辆汽车的时候，你相对于地面移动的速度会很快，但是你相对于汽车的移动速度基本上是零。

用不那么严谨的说法，一个物体的质量（mass）（译者注：不要与重量（weight）混淆）就是它包含的物质的量。用更加严谨一点的说法，质量是对于加速的阻力。一个物体的质量越大，将这个物体移动到更远的地方就越困难。

在一个地方的重力是固定值的时候，质量（mass）和重量（weight）是可以互换的概念，这对于描述在星球的表面上的移动非常不错，但在描述太空中的航行时不是很好。重量是重力施加在一个物体上的力的多少，这取决于一个地方的重力的大小。而且为了是你感到更加的困惑，在某种程度上讲，重力和加速度（acceleration）是同一回事。

事实证明，由于加速产生的阻力的这种质量和由于重力产生的质量其实是同一回事，这对我们很方便，因为这代表着由于重力产生的加速度不取决于你的质量。

动量（momentum）是质量乘以速度。在数学意义上，这是一个向量的标量（scalar）积。 动量自己是一个向量，有它的量纲（magnitude）和方向。 和速度一样，你的动量取决于你的参考系，因为你可以相对于一个物体移动的很快，而相对于另外一个物体根本不移动（动量为零）。

从根本上，动量守恒定律（The Law of Conservation of Momentum）说，只要一个系统外没有任何东西与这个系统内的东西相互作用，那么这个系统内的动量之和就是恒定的。但是在现实中，有一个这样完全封闭而且不与宇宙的其他部分交互的系统是不大常见的。除非这个系统就是整个宇宙本身，不过这种要首先要计算出宇宙中所有动量之和的行为听起来并没有什么卵用。

但是在一个较小的时空内，把这种系统作为一个完全隔离的系统不失为一种好用的假设，尤其是在加速的参考系里面，当系统里面所有的东西都跟外界没什么交互的时候。

动量守恒可能对于太空航行造成问题。的确，一旦你开始飞得很快，你将会一直飞得很快，一直到重力想要让你慢下来，这是件好事。 问题在于如果你的火箭一开始就没有动的话，你哪也去不了。

比冲

这个问题的解决方法是，火箭会带着一些东西进入太空，然后把这些东西向着它想去的方向的反方向扔。如果你想往右移动，你就使上吃奶的力气向左边扔一坨什么东西，这样整个火箭会往右边移动。但如果你只是扔一小坨东西出去的话，你在反方向上得到的速度会非常的小，因为你的火箭相比于这一小坨东西要重得多。真正的解决方案是，重复地扔东西出去，或者更加确切地说，连续地扔东西出去。

火箭引擎基本上就是可以受控爆炸的巨型炸弹，它把燃烧的燃料废气尽可能快地向着要去的地方的反方向扔出去。你扔得越用力，废气就有越多的动量，而你的火箭也就可以获得更多的相反方向的动量。由于你需要带着你要用的燃料和你一起走，在不失去控制的情况下发射你的废气是十分重要的。这也就是把火箭引擎称作巨型炸弹的由来。

一个火箭引擎的比冲（specific impulse）是度量其效率的值。它越能用力的把爆炸时产生东西扔向一个方向，它也就越能把你的火箭推向另一个方向，而你从一定量燃料里获得的加速度也就越多。比冲的缩写是$Isp$ (译者注：Isp的I是India 的I，而不是Lima的L)，通常定义为燃料喷射的平均速度除以9.81m/s^2。这个数字是在地球和Kerbin的海平面上的重力加速度的值。

很显然地，如果你想要在真空中加速，能够更用力地向相反方向丢出一定质量是一种优势。而不那么明显的事情是，如果把这些质量分成更多更小的部分，分别丢出去也是一种优势。让我们假设，你的火箭有一半的质量是你可以燃烧并且丢出去的燃料，而且你可以将这些燃料产生的废气以3000m/s的速度抡出去，那么你的Isp是大约是300。如果你一次性把所有的这些燃料都抡出去，那么你会得到1500m/s的加速。相对于你开始的地方，这些燃料将会以1500m/s往一个方向移动，而你的火箭将会以1500m/s向另一个方向移动。

但是，现在我们假设你把燃料分成两部分进行燃烧。首先，你扔出去火箭重量的1/4，然后你再扔出去另外1/4，也就是剩下的1/3。相对于你开始的地方，第一次爆炸将会把燃料以2250m/s速度发射出去，同时将你的火箭在相反的方向加速750m/s。第二次爆炸将会把第二批燃料相对于火箭正在前进的方向以2000m/s的速度发射出去，同时将你的火箭在相反的方向再加速1000m/s。总体下来，你的火箭加速了1750m/s，这比1500m/s要多得多。

将这些燃料分解成更多，更小的爆炸，将会是你获得更多加速度，但每次分解后获得加速度将会不断地减少。在持续而且稳定的燃烧情况下，你能获得的极限最大加速度大约是2079m/s。如果你好奇的话，公式是

$v_{e}\ln {\frac {m_{0}}{m_{1}}}$

或者更加普遍的：

$\ln {\frac {m_{0}}{m_{1}}}\times Isp\times 9.81m/s^{2}$

其中:

• $v_{e}$是喷射燃料的速度，

• $m_{0}$是开始质量,

• $m_{1}$是结束质量。

• $Isp$是比冲。

对于知道微积分的人来说，对数自然的通过相对于质量积分质量的倒数出现。

（译者注：这个公式就是大名鼎鼎的齐奥尔科夫斯基火箭方程）

Delta-V 的思维方式

这就将我们引向了一种新的，用Delta-V（$\Delta {v}$）来思考火箭能做什么的思维方式。用希腊大写字母Delta（Δ）来表示“改变”和拉丁字母 v 来代表“速度”（译者注：Δv有时被也简写成dv），也就是一个火箭在装有给定质量的燃料和给定质量的其他东西时，最多能够改变自己这么多的速度。

非常重要的是，这些速度的改变不一定需要在一次完成。如果一个火箭有2000m/s可用的Δv，没有理由阻止它现在加速1000m/s，等上十天半个月，然后再使用另外1000m/s。比如，有人现在正在沿着一条向着月球上着陆点前进的轨道运行，等到他快要到着陆点的时候，他才开始减速并且安全着陆。

在许多情况下，思考剩余燃料多少正确方法并不是看火箭里还剩下多少吨的液体燃料，而是你的火箭还剩下多少Δv。这决定了你的火箭能够走多远，是否能够到达你想要去的目的地，还有你是否能够回来，如果你还想要回来的话。

主要的火箭引擎

游戏中的大多数火箭引擎都依靠燃烧来产生向后发射东西的力。 你燃烧火箭燃料和氧化剂来获得爆炸，然后将燃烧的产物从火箭后面抡出去，从而推动火箭前进。

通常，当物质在地球上燃烧的时候，地球大气是氧气的来源。但是，太空中没有一堆氧气来给你燃烧，因此，你得自己带着氧气来维持燃烧。 游戏中的有些火箭引擎并不依靠燃烧来产生向后发射东西的力，他们不需要氧化剂，但是这些引擎都有一些缺点，我们将在后面的章节中介绍它们。

在游戏中你可以做出许多不同形状和大小的火箭，有些比其他的宽，有些比其他更长，有些产生的推力多，有些比其他的更加昂贵。而且往往是同一枚火箭会满足上述的全部四个特征。用前面介绍到的比冲作为衡量标准时，某些火箭比其他火箭的效率更高

在大多实际用途中，你需要首先考虑你所需要的火箭的大小，这将会防止大多数火箭来用于一定的用途。由于你通常想让火箭很好很适合地连接到你想要连接的任何物体上，火箭的大小最直接地由火箭的径向尺寸来决定。游戏中多种类型的零件有六种基本的径向尺寸（直径）: 微小（0.625m），小（1.25m），中（1.875m），大（2.5m），加大（3.75m）和特大（5m）。通过串联方式连接的东西（包括大多数火箭引擎和燃料箱），你一般希望所连接的两个零件都有相同的径向尺寸。这并不是绝对必要的，有的时候你有充分的理由来不这么做，但这么做会一般更加有效率。

• 

  48-7S “火花”

• 

  KR-2L+“犀牛”

你需要多少推力来抬起你的有效载荷至关重要。一个48-7S “火花”引擎自重0.13吨，有20kN的推力，是一个非常不错的引擎。一个KR-2L+“犀牛”引擎自重9吨，有着2000kN的推力，也是一个非常不错的引擎。但如果你想要抬起一个1000吨重的东西，使用 “火花”引擎将如杯水车薪，无济于事，因为你需要上百个这样的引擎，而且那将会是一个令人难以置信的荒诞设计。同时，如果你想要抬起一个2吨重的东西，使用 “犀牛”引擎简直是牛鼎烹鸡，仅仅只是它的自重就会让这枚火箭的效率极低。

下面级液体燃料引擎

使用火箭来升空（或者着陆）会带来两个复杂的事。第一是重力会对你施加很大的作用，而你并没有无限的时间。如果你的引擎所能产生的推力小于重力的话，你是绝对不可能飞起来的。如果你幸运的话，那么你会坐如钟，而如果你脸黑的话，你也并不会行如风，你的火箭将会倒下然后爆炸。但如果你的推力只是刚刚好大于重力也不够，因为那样你需要使用大量的燃料来大气中缓慢蠕动。

这就把我们引向了推重比的概念。如果你点击游戏中的Δv图标，游戏将会向你展现很多计算出的数据，这其中就包括了你现在的推重比。在起飞的时候，你会想让这个值大大的大于1，比如1.3，1.5，或者1.7。你也不会想让推重比变得太大，因为那样表明你建造了一个过大或者过重的火箭。同时，在低层大气中移动的很快也会让你经受很大的阻力，有时这会让你的火箭失去控制并且翻个底朝天。

第二件复杂的事情是，火箭引擎在大气中工作地并没有在真空中那么好，空气就是让引擎不能好好地发挥作用。有些引擎比其它引擎更加容易受到影响。这就是为什么每一个引擎有两套Isp和推力的数值：一套表示它在真空中的性能，而另一套表示它在一个大气压下的性能，也就是在Kerbin海平面高度的性能。在大气中你将会以真空中同样的速度燃烧燃料，但是产生相对于真空中更小的推力。

当然了，除了一个大气压和真空，这还有很多其他的大气压值。有些地方的大气压在这两个值之间，有些地方的大气压甚至会大于一个大气压。在气压低的地方（比如0.01大气压下），引擎真空数据会更加接近于实际的数值。火箭引擎的性能会随着压力的增大而变差，并且在足够高的压力下根本不产生推力。你可以通过在组装大楼中右下角窗格里选择具体的星球和高度来看到那个位置准确的推力和Isp。

从Kerbin，或者其它任何有着浓密的大气的天体（Laythe, Eve, 还有Jool的低层大气）上起飞时，你基本上不应该使用任何真空性能和大气性能之间有较大差距的引擎。这两个性能之间没有较大差距的引擎会更加适合作为起飞级的引擎。这样的引擎包括但不限于RV-1“幼兽”引擎，S3 KS-25“矢量”引擎，RE-M“主帆”引擎，和S3 KS-25x4“猛犸”引擎。

• 

  RV-1“幼兽”

• 

  S3 KS-25“矢量”

• 

  RE-M“主帆”

• 

  S3 KS-25x4“猛犸”

上面级液体燃料引擎

在深空中的时候，你可能会想要使用一些Δv来调整你的飞行轨迹。调整这些轨迹所需要时长并不很重要，毕竟会有大把的时间。重要的是你究竟可以使用多么少的燃料来完成轨道机动。一些引擎被优化成在火箭的上面级使用，并且旨在仅于真空或者大气非常稀薄的地方使用。通常，这些引擎非常注重效率，有着较高的比冲。

一些引擎牺牲了自己在高气压下的工作能力，换来在真空中优秀的性能。这些被称作上面级引擎，但是，在上面及引擎和下面级引擎并没有一个正式的界限。一些很好的上面级引擎包括但不限于LV-1“蚂蚁”引擎，LV-909 “小猎犬”引擎，LV-T91 “猎豹”引擎，RE-L10 “贵宾犬”引擎，RE-J10 “爱尔兰猎狼犬”引擎和KR-2L+ “犀牛”引擎。

• 

  LV-1“蚂蚁”

• 

  LV-909“小猎犬”

• 

  LV-T91“猎豹”

• 

  RE-L10“贵宾犬”

• 

  RE-J10“爱尔兰猎狼犬”

• 

  KR-2L+ “犀牛”

在设计上面级时，你一般会很清楚你的载荷有多重，你的火箭需要有多大，以及它要如何与火箭上的其它零件来配合。这会将你限制到一小部分合理的选择上，然后你可以从这些候选中选出看起来最有效率，而且可以在完成任务的同时使用最少的燃料和资金的那个。

没人会阻止你在深空使用下面级引擎，但那些引擎相比起上面级引擎效率低下。而在高气压环境下使用上面级引擎也会给你非常差的性能。

固体燃料助推器

固体燃料助推器是一种特殊的火箭，旨在用于火箭的第一级，将你的火箭带离地面并且开始向上移动。它们不会带你走很远，但它们是一个很棒的起点。大部分液体燃料火箭都将燃料罐和火箭引擎作为两个不同的部分，但我们的固体燃料助推器却不这样，它们自己集成了燃料和引擎这两部分。

不过，固体燃料助推器有些严重的缺点。首先，不像可以随着节流阀上下调整推力的液体燃料引擎，固体燃料推进器根本无法被关闭。点燃它们之后，它们会一直燃烧到燃料耗尽，然后才会停止。生涯模式早期的固体燃料助推器完全没有矢量（译者注：不能调整推力方向），直到最近，一批新加入游戏的固体燃料助推器才拥有矢量。除此之外，固体燃料助推器的比冲也很糟糕。

• 

  S1 SRB-KD25k“反冲”

• 

  S2-33“克莱兹代尔马”

所以为什么要使用固体燃料助推器呢？一个原因是它们简直就是是白菜价。一个S1 SRB-KD25k“反冲”固体燃料助推器可以在低层大气中提供62.8秒的600kN持续推力，而且只要2700块！不少液体燃料引擎要花费两倍的价格来达到同样的推力，这还没算上油钱！

固体燃料助推器在很小的尺寸上提供很大的推力。当你需要很大的推力来离开地面，同时又想要保持较小的横截面来降低阻力的时候，固体燃料助推器能够派上大用场。

固体燃料助推器只对你离开Kerbin的第一小步有用。由于它们低下的效率，你不会希望带着这堆死重到高层大气和太空中去使用。它们很适合开始推动很多火箭，但只要使用它们，丢掉它们，然后继续旅程就好了。当你开始使用大型的火箭的时候，你会发现你不觉之中已经在往火箭上贴一堆S2-33“克莱兹代尔马”固体燃料助推器了。

特殊的引擎

总是要带着一堆最后终将要被燃烧掉的液态氧到处跑似乎非常的低效，那么有没有其它方法可以不使用氧气呢？您好，有的，而且有不少。但它们都有一些明显的缺点，这一小节我们专门会讨论这些引擎。

LV-N“神经元” 原子火箭引擎

LV-N“神经元”原子火箭发动机

首先，我们有LV-N“神经元”原子火箭发动机（译者注：它实际上是一种Nuclear Thermal Rocket（NTR），核热火箭），它的原理是在这个引擎中有一个核反应堆，核反应堆产生的热量可以加热作为工质的氢，随着氢原子变热，它们会移动得越来越快。现在我们的引擎上有一个洞，高速运动的氢原子就会从这个洞喷射出去。（译者注：游戏里并没有氢或者其它的燃料种类，只有液体燃料，于是“神经元”在游戏里只会消耗液体燃料，不使用氧化剂）使用氢作为燃料是因为氢的相对分子质量最低，而一个分子的相对分子质量越低，在同样温度下的移动速度就更高。（译者注：$E_{k}={\frac {1}{2}}mv^{2}$，分子动能一定，质量和速率的平方成反比）

“神经元”引擎的优势是它高达800的巨大的比冲。相比之下，游戏中比冲最高的化学火箭引擎是RE-J10“爱尔兰猎狼犬”,但它也只有380的比冲。这就是为什么使用“神经元”引擎的原因。

但就像之前说的一样，它有一些巨大的缺点。首先，它的推重比非常糟糕：一个三吨重的引擎只有60kN的推力。游戏中其它每一个普通的化学液体燃料引擎或固体燃料引擎的推重比都至少是它的五倍，甚至超过十倍。即使在没有任何燃料和载荷的情况下，它甚至都没法在Kerbin的海平面高度上推起自己一半的重量。

它们也非常的昂贵，每一个造价10000资金单位。这使得“神经元”成为游戏中第七昂贵的引擎，而且比它昂贵的引擎都更大，而且有至少1000kN的推力。有些时候你可以通过安装一堆同样的引擎来弥补一个引擎的推力小的这个缺点，但对于“神经元”来说，这行不太通，因为那样太贵了！

“神经元”的燃料经济性也不是很好。你可以使用普通的燃料箱，只要不装氧化剂就好了。但是这样子你的燃料箱的干湿质量比只会有4.6：1而不是9:1，这抵消了它的很多效率优势。你也可以使用纯液体燃料箱，但是游戏中并没有多少纯液体燃料箱，大概也不会有你想要的形状。

“神经元”的低推力意味着你通常需要较长的燃烧时间来达到需要的速度变化。这在深空还行，但在重力很强的星球的低轨道上则不是很好。想象一下，如果你的轨道周期只有30分钟，而你的加速时长是20分钟。它们可以用来让你脱离星球的低轨道，但会非常令人痛苦。

即使如此，由于它的高效率，“神经元”通常非常值得在长途飞行中使用。如果你只是想绕着Kerbin飞或者前往Kerbin的一颗卫星，使用它是完全没有意义的。它甚至不那么适合前往Eve或者Duna。但对于Jool，Moho，或者Eeloo这些较远的目的地，在深空级有一个“神经元”可以大大的减少发射质量。

IX-6315 “黎明” 离子引擎

IX-6315 “黎明”电力推进系统

另一种让火箭以更高的速度排出废气的方法是使用离子引擎。它的原理是。在电场中有一些氙气（氙（Xiān），Xenon，第54号元素）。通常，氙气是一种稀有气体，它们并不活跃，而且是电中性的。但如果你通过剥离电子的方式来使一小部分氙原子电离，那么你的电场就可以用极大的力推动那一部分电离的氙气，而不对其他的氙原子施加任何的力。那极少数的氙离子以极高的速度从引擎中飞走，而其余的氙原子则一动也不会动。

这样的结果是你得到了一个真空比冲4200的离子引擎。这超过“神经元”引擎比冲的五倍，任何其它常规液体或固体燃料引擎的十一倍以上。这使得“黎明”引擎以巨大的优势成为了游戏中拥有最高真空效率的引擎。

自然的，它们有一些巨大的缺点。首先，它们的推力很小，只有2kN。这其实已经比现实生活中的离子引擎强大到不知道哪里去了，现实中的离子引擎通常只有大约0.01%的推力，甚至以mN（毫牛）来作为推力单位。虽然“黎明”引擎对于深空飞行十分有效，但你不是需要安装大量的引擎，就是需要忍受非常，非常长的燃烧时间。

其二，相比于液体燃料箱9：1的干质比，“黎明”引擎的燃料箱的干质比只有大约4：1。这也就偷偷抵消掉了一部分的效率优势。

其三，它们非常昂贵，一台引擎要花费8000资金单位似乎并不算什么，直到你意识到它们只能给你2kN的推力。它们的油箱的价格更高，因为氙气应该不是从树上长出来的。氙气每吨的成本超过40000资金单位，相比之下，火箭燃料简直就是白菜价，只要100资金每吨。

其四，它们消耗非常，非常多的电能来维持电场。每个“黎明”引擎在运行时每秒消耗8.741电量单位。快速生产大量电能需要的电气设备的质量使得它们看起来不再那么高效。

PB-X750氙气储存罐

其五，推力弱意味着很长的燃烧时间。一个满推力的“黎明”引擎排光一个PB-X750氙气储存罐需要超过三个小时的时间。你在加速的时候并不能进行时间加速，不过你可以进行最高四倍的物理时间加速，但那样你仍然需要在现实中等待超过45分钟。即便如此，请记住，游戏中的“黎明”引擎比现实中的离子引擎仍然强大得多，现实中的离子引擎可能会一次进行长达数天甚至数周的燃烧。

其六，它们使用的氙气并不能够通过采矿来补充。游戏中的其它任何引擎都运行你在任意星球上使用一些采矿设备来完全补充燃料。但是就像前面说的一样，氙气不长在树上，你不能指望在任何地方都能找到氙气，在很多星球上，即使有氙气，也会漂浮到太空中去，消失得无影无踪。

实验数据储存单元

“黎明”引擎由于成本高，推力低，几乎无法用于下面级。它们真正发挥作用的地方是将很小的载荷带回Kerbin，比如，很小的指令舱，带有高价值数据的实验数据储存单元，或者一些合同要求你带回的零件。它们非常适合从Moho返回，但对于从Jool或者Eeloo等遥远的星球而言效果不佳。因为在那里太阳能板的发电效率很低。如果你想把什么东西放在太阳的低轨道上，“黎明”引擎也是必不可少的。

喷气引擎

另一种提供推力的方法是根本不使用火箭。飞机上使用的喷气引擎的效率大大高于火箭发动机的效率，因为它们有两个巨大的优势。首先，它们只需要携带燃料而不需要携带氧气，因为它们可以从空气中吸取氧气进行燃烧。其次，它们不需要携带什么东西来抡出去，涡轮机可以直接推着空气来产生推力。这导致了喷气引擎的比冲在3200到12600之间，这低则可以和“黎明”引擎打个平手，高则可以吊打我们前面提到的吊打了其它所有火箭引擎的“黎明”引擎。

但很明显，天下没有免费的午餐，喷气引擎也有一些巨大的缺点。它们的主要缺点是需要氧气。因此，它们仅能在低层大气中起作用。即使是低层大气，也得是有氧气的低层大气，因此，只有在Kerbin和Laythe上它们才有用。而且问题在于，如果你在低层大气中，你想要做的第一件事可能就是不继续呆在这里——要不进入太空，要不在地上着陆。对于大多数任务，喷气引擎只需要运行很短的时间，因此它们的燃油效率显得无关紧要。

其次，如果用火箭的标准来衡量，它们的推重比简直小得可怜。相对于它们的重量，它们带来的额外推力非常之小。而且用一台发动机的排气对着另一台发动机是不行的，因为那样会破坏你的空气动力学性能。所以你能使用的喷气引擎的数量大大的受到横截面积的影响。通常，你的载具的宽度要小于长度，否则空气动力学会让你失去控制，这会限制你在发射的时候使用较小的载具。

其三，起降是一个难题。在现实中有很多很多机场和跑道，飞机通常会从一个地方飞到另一个地方。但Kerbin上只有三条跑道，而Laythe上一条也没有，这使得飞机起降成为了一个难题。你当然可以垂直起降（VTOL, Vertical Take-Off and Landing）,从而根本不需要跑道，但VTOL载具很难建造。

其四，喷气动力使你不得不应对复杂的空气动力学问题，用一个字总结那就是难。这在现实中也很难，但现实生活中的航空航天工程师有更加精确的工具。而你有的只有对称工具。你可以通过旋转对称来建造火箭，那样可以防止某个零件稍微偏了一点而造成可怕的事情。对于喷气机，你可以在一个维度上使用镜像对称，但是你仍然需要在另一个维度上使用一点都不精确的工具来平衡东西。

如果你四处看看，你会发现很多人说他们用喷气引擎做到了这个或者那个。大部分的这些东西都非常古老，可以追溯到1.0版本空气动力学大修之前，所以他们做的东西放在现在不一定能用。你当然可以做一个小的只能装没有意义的载荷的喷气机到处飞，但是我还没有发现任何情况中用火箭不会更好一些。最好将喷气发动机视作玩具，它们在游戏中没有实际用途。

转子

除了使用内置的喷气发动机以外，你还可以使用转子来自己整一个发动机。转子不使用燃料，而是依靠电力。转子由两个部分组成，在启动时，其中一个会相对另一个旋转。这可以用来旋转螺旋桨叶片，直升机叶片，或者结构面板，来提供一定的推力。

你可以使用转子来发挥你的创造力，但请记住，转子很难妥善使用。你可以把它们做成飞机用的螺旋桨发动机，而不使用喷气发动机。这些转子不依赖大气中的氧气，因此它们也可以在Eve或者Jool的大气中使用。实际上，直升机大概是唯一可以在Jool的低层大气中工作的东西。

另一种可以避免你接触空气动力学的方法是用转子来制作船只使用的发动机。这样你可以在没有燃料的情况下降落在水中，你可以启动船只引擎来让你慢慢开回岸上，然后你就可以使用漫游车车轮，或者挖掘一些矿物来制造火箭燃料。只要你移动得足够慢，空气动力学就反应不过来不会使你倾覆并且爆炸。

RCS推进器

另一种特殊的引擎是RCS（Reaction Control System，反应控制系统）推进器。这些发动机旨在进行小的，精确的运动，尤其是在深空中的时候。RCS不会让你入轨，也不会让你能够着陆。但它们会在当你想让两个飞行器在太空中对其并且对接的时候派上用场。

就个人而言，我认为它们并没有那么有用。它们可以很好的做到它们的工作，但是你也可以用其他的方式进行精确的操作，甚至对接。这样你甚至不需要携带多一种类型的燃料和引擎。（译者注：KSP中的动量轮过于强大而且不真实，使得RCS在游戏中的作用没有现实中那么大）

旋转

在大多数情况下，盲目的力大砖飞是不够的。你还需要把力往正确的方向使，这样才能够让你去你想去的地方。对于火箭的话，这一般意味着让你的火箭引擎指着你想去的反方向。为此，你需要能够旋转你的载具，这就是本节的内容。

角动量守恒定律

线性速度也有它的角度形式。我们会在下一章中讨论坐标系，目前你只需要了解你的角速度（Angular Velocity）是你相对于其它什么东西的角度变化的速率。正如线性动量一样，也有一种叫做角动量（Angular Momentum）的东西。一个物体相对于一个点的角动量是从这个点到物体的距离与这个物体的动量的向量叉积（Cross Product）。叉积在代数上是混乱而且不直观的，因此我不会在这里解释它。

角动量的重要之处是它是守恒的。只要不施加任何外部扭矩，一个系统围绕一个固定点的角力矩之和就是恒定的。相比于没有外力施加到系统上，不施加外部力矩是一个弱条件；我稍后将会解释扭矩的概念。尽管角动量守恒解释了火箭如何工作，而且在游戏里并没有什么影响，但它仍是一种极其重要的原理，有着非常广泛的用途和后果。

角动量守恒适用于任何物体和任何点。在极限条件下，当参考的旋转点变得无限远的时候，它等同于普通的动量守恒定律。很多对象和点的组合其实并没有很好的体现这一点，部分是因为系统中有外部的扭矩。

在游戏中有两种情况下角动量守恒极为重要。其中一个较为复杂和深刻的是你的火箭围绕行星或卫星等天体运行的过程。我们观察角动量的物体是你的火箭，而参考的旋转点是绕行的物体的质心。在详细介绍这些东西之前我们还得介绍更多的术语，因此我们稍后再讨论这些东西。

另一个角动量很重要的情况是你的火箭会围绕着它的质心旋转。简单地说，物体的质心是物体中质量的平均位置。对于一堆质量点，质心可以通过所有的质量乘以位置之和除以所有质量之和计算得出。对于连续的固体对象，你会需要使用积分而不是和。

一些物体的质心可以很方便的通过对称找出。例如，球体的质心在球的正中心。当建造火箭的时候，如果你在航天飞机机库中用镜像对称放置所有的东西，你可以确保飞机的质心会在镜像对称平面中的某个位置。而如果你在航天器装配大楼中用旋转对称来放置所有的东西，则质心将位于通过火箭中心的直线上的某个位置。在这两座建筑物都可以选项可以显示你的质心位置。

关于理解物体的质心的一件重要的事情是，当一个物体在没有任何其他物体接触的情况下开始旋转时，它将会围绕着它的质心旋转。 因此，你需要围绕着质心旋转火箭。

动量轮

如果你不知道动量轮的工作原理，它们看起来会像是魔法。它的原理是当你在深空中而且没办法碰到任何东西的时候，你可以启动你的动量轮来旋转你的火箭以使得它指向某个特定的方向。然后你可以停下，并且可以一直将你的火箭指向你想朝向的方向。这样你不需要启动任何推进器，只需要消耗一点电力。这实际上是一件在现实中你可以做到的事情。

第一个动量轮是偶然发现的。 某个太空计划发射了一颗卫星，这颗卫星起初在按照他们的预期计划进行。 但是，当它开始将数据传回地球时，它开始旋转了起来。 这很麻烦，因此他们不得不停止它的旋转，然后将其转回预定的方向，这浪费了很多燃料。 然后，当它再次开始传输数据时，它又开始了旋转。 起初，这让人感到非常的莫名其妙。

最终，他们弄清楚了这为什么会发生。 因为这颗卫星是使用磁带来储存数据的，在这它传输数据时，它需要旋转卫星的内部的这些磁带。 在适当的参考系中，卫星在开始传输数据之前的净角动量为零。 当旋转磁带的轮子的时候，这些轮子在某个方向上就有了一定的角动量。 但由于整个卫星的净角动量保持零（因为角动量守恒），整个卫星的其余部分就会开始沿相反方向缓慢旋转。

弄清楚这一点对于火箭来说是巨大的进步。 不需要装一堆的小型推进器就可以使火箭朝任意方向旋转了，而火箭所需要的只有几个装在内部的轮子。 你想要沿一个方向旋转你的火箭？ 只需沿相反方向旋转这些轮子即可。 停止轮子之后，火箭也会停止旋转。

游戏中有三个专门的动量轮零件，它们分别有三个不同的径向尺寸。 游戏允许所有动量轮沿任意方向旋转，从而稍微简化了你的游戏操作，并且旋转的速度比现实生活中的动量轮能做到的要快得多。 此外，游戏并没有限制动量轮的累积扭矩，这与只能够转到一定速度的现实动量轮不同。 但是动量轮本身是一种货真价实的东西，而不仅仅是一种使游戏变得更容易而加入的魔法。（译者注：译者认为相比现实中的动量轮，游戏里的动量轮就是实打实的黑魔法）

除了专用的动量轮以外，游戏中的大多数指令舱还具有内置的动量轮。 这些动量轮扭矩的往往比专用的动量轮低，因此除了一些非常小的载具外，你通常会希望在你的火箭上添加一个或多个专用动量轮。

扭矩

扭矩基本上就是力的角度形式。 从技术上说，一个物体上相对于一个点的扭矩是旋转点和施力点之间的距离与这个力的叉积。 因此，扭矩的大小不仅仅取决于力，还取决于计算扭矩的点的位置。

对于我们来说，我们再次有两个很有用的点来计算扭矩。 一个是火箭的质心。 另一个是你所环绕的天体。 我们将在接下来的章节中将谈到后者，但就目前来说，相对于火箭质心产生的扭矩将使你的火箭开始旋转。

在两种特殊的情况下，两个向量的叉积将会是零。 一是，模为零的向量与任何其他向量的叉积将始终为零，这意味着大小为零的力会导致大小为零扭矩。 这也意味着直接施加到物体质心上的任何力都会对这个物体施加大小为零扭矩。

另一种更广泛的情况是，两个互相平行的向量的叉积为零。 因此，如果所施加的力直接指向这个对象的质心，它将导致大小为零的净扭矩，并且不会旋转对象。

除了动量轮以外，游戏中还有其它五个主要的扭矩来源。 它们可能是你有意产生的或者你不想要的，但它们都会导致火箭旋转，因此了解它们很重要。

Asymmetric rocket placement

First is if your rockets are placed asymmetrically. A rocket engine that isn't pointed right at your center of mass will have some torque. If you have another engine on the opposite side, it will cause the opposite torque. These cancel out, for a net sum of zero torque. That's usually what you want, so that you can avoid extra torque when you don't want it.

The vehicle assembly building and spaceplane hangar will both draw this for you. You can show the sum of the forces, as well as the center of mass. If the former is pointed right at the latter, you're fine, at least for a rocket. Making everything use rotational symmetry will accomplish this for you. For a plane, you want the sum of the forces to be pointed right at the center of mass in the horizontal direction, but possibly not quite in the vertical.

There are two ways to screw up the net force here. One is if the rockets firing at a given time are placed asymmetrically. This can happen because of the way that the rocket is built, with one engine not having others to balance it. Even if the initial design is correct, it can happen if one engine is firing while the other(s) to balance it are not. It can also happen if something goes awry and blows up some but not all of your engines.

The other way to mess this up is if your center of mass is off-center. For example, if you stick one extra fuel tank off to one side without a counterpart on the other side, you can end up with a center of mass that is off to the side. Then even if you properly pair all of your engines, the net force isn't pointing at the center of mass, and so the rocket still rotates. To avoid this, you need all of your parts to be either paired with other, identical parts using the rotational symmetry tool, or else a single part actually on the center line of the rocket.

引擎矢量推进

In addition to pointing their exhaust in the exact direction that they're facing, some engines can angle the nozzle off to the side. This is something that can be adjusted from moment to moment, so that you can have the nozzle pointed to the side one moment when you want to turn and centered again a second later when you want to go straight.

Each engine has a maximum amount of gimbal. Some engines can't gimbal at all, and the maximum angle for most of those that can is very small, such as two or three degrees. A few engines have a very large gimbal angle, such as 10.5 degrees for the vector or 22.5 degrees for the cub--though the cub can only angle in one axis, not two.

Large gimbal can be handy sometimes, but excessively large gimbal can mean a lot of torque. With SAS on, this can cause it to overshoot back and forth on angles until the entire ship shakes violently or even flies apart. Fortunately, you can reduce the maximum gimbal of any rocket engine. Sometimes it is handy to have a stage that mixes some engines with high gimbal with others with no gimbal at all so that you can still rotate at a decent rate.

Aerodynamics

Air resistance when in the lower atmosphere is another source of torque. For planes, this is essential to make the plane fly at all. For rockets, it's generally undesirable at take-off, but can be helpful to slow you down before landing.

While air resistance mostly slows you down in whatever direction you were going, it can also provide some torque. Because it pushes so hard, a slight angular tilt can offer considerable torque. In some cases, it can cause a rocket to flip over shortly after launch.

For a rocket of a fixed size and shape, there will be some amount of force applied to the rocket as it moves in any particular direction. The force generally varies with the direction, and often by quite a lot. A pancake moving with its wide face catching the wind will draw a lot of air resistance, for example, but the same shape will get much less if it moves in the direction of an edge.

The most stable direction for a rocket is whichever direction offers the least resistance. For a long, narrow rocket, this will usually be either retrograde or prograde. For a short, wide rocket, it can be moving on an edge. If you're near the direction of minimum wind resistance, aerodynamics will often push you toward it.

There can be multiple local minima that are stable if you're near them. Additionally, so long as the torque applied by aerodynamics is less than what you can apply with other sources (typically engine gimbal or reaction wheels), you can keep the rocket stable in the direction you want it to be facing.

Ultimately, aerodynamics is very complicated. New players commonly have to figure out why their rocket is flipping over shortly after launch, and aerodynamics is the culprit. It often helps to make your rocket have less drag when traveling in the direction you want to go, such as by using aerodynamic nose cones. Sometimes you need more torque from other sources. Occasionally, you just have to make the rocket go slower when in the lower atmosphere to keep it stable.

Collisions

If one object directly pushes on another, it can apply some torque to the other object. Actually, both objects can apply some amount of torque to each other. In one sense, this is obvious, and also the simplest example of torque. But in another sense, it's fairly rare, as you typically don't collide with other objects when deep in space.

The main issue where collisions will spin your rocket around is when landing. If the ground is uneven and one side of your rocket touches before the other, the ground will apply some torque to spin the rocket away from the side that touched first. You can reduce this force considerably by touching down at a lower velocity. It also helps a lot if you can find a level place to land, though this isn't always practical.

Rotors

The basic goal of a rotor is to apply some torque to rotate some small portion of the ship in one direction, such as helicopter blades. But as angular momentum is conserved, this rotates the entire rest of your ship in the opposite direction, albeit usually much more slowly. Even so, if you're reckless with rotors, they can easily cause you to spin out of control.

The solution to this is usually to have an even number of rotors, and spin them in opposite directions. Thus, when some of them apply torque in one direction, others apply an equal amount of torque in the opposite direction. The net effect is zero torque on the rest of your ship.

Inertia

Just mass is resistance to acceleration, so inertia is resistance to rotation. The amount of angular acceleration of an object is the amount of torque divided by the moment of inertia about the axis that the torque is trying to rotate the object. Importantly, the moment of inertia is not a single, fixed constant for a single object, but varies with the axis. The axis of rotation always goes through the center of mass of the object.

Technically, the moment of inertia is the integral over space of the mass density of the object times the square of the distance from the axis of rotation. You can think of it intuitively as the mass of the object times the square of the "average" distance of parts of the object from the axis of rotation. It would be more proper to use the root mean square (which is greater than the average) rather than the average, but using the average is probably more intuitive and usually won't lead you too far astray.

One thing that is important to understand is that an object of fixed shape gets larger in all directions, the moment of inertia grows much faster than the mass. Meanwhile, the aerodynamic forces on it grow proportionally to the cross-sectional surface area, and thus more slowly than the mass. If you increase the size of the rocket in all dimensions by a factor of n, the aerodynamic forces (including torque) increase by a factor of n^2, the mass by a factor of n^3, and the moment of inertia by a factor of n^5. That last one is n^3 for the mass times n^2 because the distance from the axis of rotation increases by a factor of n.

Thus, the angular acceleration due to aerodynamic forces decreases by a factor of n^3. For example, make the rocket twice as big in all dimensions, and the angular acceleration due to aerodynamics will only be 1/8 as big as before. This is why small rockets are prone to flipping, but a similar shape with a much larger rocket allows you to nearly ignore aerodynamics when taking off.

Another consequence of this is that big rockets are much harder to turn than small ones. Small probes that only weigh a few tons can commonly spin very fast from the minor reaction wheels inside of a pod or probe core. Giant stations with a mass of thousands of tons can take minutes to rotate to the direction you wanted, even with a number of dedicated reaction wheels.

Moving globally

Your intuition is likely that if you want to move from point A to point B, you start moving directly toward point B. Keep moving in that direction for a while, and eventually, you'll get there. For moving small distances, that works pretty well, with some fake forces that we'll discuss near the end as the only real impediments.

For moving from one celestial body to another, however, just pointing in the direction you want to go will fail spectacularly. Constantly firing rockets to counteract the force of gravity will drain your fuel in a hurry. Rather, you need to apply minimal thrust at carefully chosen places, and then rely on gravity to take you where you want to go.

This section is by far the most math-intensive in the entire guide. As before, I promise not to give you lengthy algebraic derivations. I will, however, introduce some linear algebra terminology, to at least give you the proper nomenclature for what is going on.

Coordinate systems

If you want to describe the location of a point in space, there are a variety of ways to do it. The three that will generally be introduced in a fairly introductory physics or multivariable calculus course are rectangular, cylindrical, and spherical coordinates. There are plenty of others, and we'll get to some that are useful for describing orbital mechanics shortly. Cylindrical coordinates aren't important in this game, but I'd like to explain rectangular and spherical coordinates before moving on.

Rectangular coordinates

To describe a point on a line, you can use a single number. Pick a point on the line as your zero point. You can then specify any other point by saying how far from the zero point it is, and in which direction. One side of the point is positive, and the other side is negative.

You can do about the same in two dimensions, but you'll need two numbers. For example, to specify a point on your monitor, you could have one number that describes the position in the horizontal direction, and another that describes it in the vertical direction. Each spot on the screen corresponds to a unique pair of numbers.

You can do the same in any other number of dimensions, too. As space is three-dimensional, we commonly want three dimensions. In this case, it takes three numbers, that is, three coordinates, to describe the position. The three coordinates are customarily called x, y, and z.

It's important to understand that there is not a canonical origin (zero) point. Nor are there canonical directions of which way is x, which way is y, and which way is z. Rather, you're allowed to pick whatever is most convenient. It's common to use z as "up", but out in the middle of space, there isn't a clear "up" direction.

Spherical coordinates

Another way to describe a point in space is with spherical coordinates. As with rectangular coordinates, you start by picking one particular point as your origin. Your three coordinates are the Greek letters rho, theta, and phi. I'll call them r, t, and p, respectively, simply because it's hard to type Greek letters here.

The r coordinate is your distance from the origin, regardless of the direction. The t coordinate is your angle in some particular plane through the origin that you pick. The p coordinate is your angle with that plane. The t and p coordinates together specify a direction. Physicists sometimes reverse the roles of theta and phi, but I'm going to stay with the convention I've just described.

One notable feature of spherical coordinates is that the three coordinates aren't allowed to be arbitrary numbers. As r is a distance, it must not be negative. As t and p are angles, they would repeat if allowed to become arbitrarily large. By convention, t is allowed to be in [0, 2 * pi), while p is allowed to be in [-pi/2, pi/2], where pi = 3.14159...

There's one important use of spherical coordinates built into the game that you're probably already familiar with. The zero point is the center of a planet or moon. r is essentially your altitude, though it is commonly displayed as (distance from the center of the planet) - (distance from sea level to the center of the planet). t is your longitude, that is, how far east or west you are. p is your latitude, which is how far north or south you are.

Some linear algebra

If using a rectangular coordinate system, you can choose the directions almost arbitrarily. But some choices are often better than others. To explain why, we're going to need some terminology.

When using rectangular coordinates, we said that we had x, y, and z coordinates. We commonly write a point (or a vector) by listing the three coordinates. For example, we might write (2, 5, -3) to mean that we're at the location where x = 2, y = 5, and z = -3. We can add two vectors algebraically by adding their coordinates. For example, (2, 5, -3) + (7, 1, 3) = (9, 6, 0). In the x-coordinate, we get 2 + 7 = 9, and so forth.

Geometrically, we can write a vector by drawing an arrow from the origin to the point. We can add two vectors geometrically by moving the tail point of one to the head of the other, and then drawing a vector from the other tail to the other head.

We can also take scalar multiples of vectors. Algebraically, this is just multiplying each coefficient by the same number. For example 3 * (2, 5, -3) = (6, 15, -9). Geometrically, this corresponds to making the vector longer or shorter (or pointing in the opposite direction if negative) without changing the direction that the vector is pointing.

Orthonormal bases

The span of a set of vectors is the set of all linear combinations of them. That is, pick a scalar multiple of each vector in the set, then add them all together. The span of a set of vectors is a subspace of the original vector space, that is, the space in which our vectors live.

A set of vectors spans a vector space if the span of the set of vectors is the whole space. A good coordinate system should span the whole space, so that you have a way to describe all of the points in it. For example, the set of vectors (1, 0, 0), (0, 1, 0), and (0, 0, 1) spans the whole three-dimensional space. If we want to write a point (a, b, c), we can write it as a * (1, 0, 0) + b * (0, 1, 0) + c * (0, 0, 1). The set of vectors (1, 0, 0) and (0, 1, 0) does not span the whole space, as it gives us no way to make the z-coordinate not be zero. Similarly, the set of vectors (1, 0, 0), (1, 1, 0), (2, 1, 0), and (0, 1, 0) does not span the whole space.

A set of vectors is linearly independent if the only linear combination of the vectors to give zero is the zero combination. For example, the set (1, 0, 0), (0, 1, 0), and (0, 0, 1) is linearly independent. The set (0, 1, 0) and (1, 0, 1) is also linearly independent. The set (1, 0, 0) and (2, 0, 0) is not linearly independent, as we could compute 2 * (1, 0, 0) + (-1) * (2, 0, 0) = (0, 0, 0). A good choice of a rectangular coordinate system should have its coordinate vectors be linearly independent, as otherwise, more than one set of coordinates will give the same point.

A set of vectors is a basis for a vector space if it is both linearly independent and a spanning set. This requires that every point in the space can be written as a linear combination of the basis vectors in exactly one way.

The dot product of two vectors is obtained by multiplying the components, then adding the products. For example (1, 2, 3) dot (4, 5, 6) = 1 * 4 + 2 * 5 + 3 * 6 = 32. Two vectors are orthogonal to each other if their dot product is zero. In other contexts, this is sometimes called perpendicular or normal, but I'll generally stick with orthogonal.

We usually want for the coordinate vectors in a coordinate system to be orthogonal to each other, as otherwise, we could get some peculiar effects. For example, the set of vectors (2, 1, 1), (1, 2, 1), and (1, 1, 2) forms a basis for three-dimensional space. But it's kind of an awkward basis to use, as we can get the vector (4, 4, 4) by using +1 as the coefficient for all three basis vectors. We can get the vector (2, -1, -1) by using +2 for the first coordinate and -1 for each of the other two. But this makes the vector (2, -1, -1) look "larger" than (4, 4, 4), which seems intuitively wrong.

The length of a vector is the square root of the dot product of the vector with itself. This does geometrically give the length if you measure it. An orthogonal set of vectors is called orthonormal if each of its vectors has length 1.

We typically want a good coordinate system to have its coordinate vectors form an orthonormal basis. We could use (1, 0, 0), (0, 2, 0), (0, 0, 2398) as a basis for a space. But that would make the z-coordinates tend to be much smaller than the x and y coordinates, which would seem weird.

Dimension and degrees of freedom

All bases for a vector space have exactly the same number of vectors. It isn't a coincidence that rectangular coordinates and spherical coordinates for the same space each have three coordinates. The number of vectors in such a basis is the dimension of the space.

It might be surprising that most ways of picking vectors randomly will form a basis, if you pick the right number of them. It's kind of like observing that most ways of picking three points at random won't happen to accidentally place them on the same line. Most sets of vectors will not happen to form an orthonormal basis, however.

Spherical coordinates don't technically define a basis for a space globally. They do provide a valid coordinate system for treating the space as a smooth manifold, except along the axis through the poles, but that's far beyond the scope of this guide.

When you get to non-rectangular coordinate systems, the number of degrees of freedom is basically the dimension that you're dealing with. That's the number of coordinates that you'll need.

Maneuver nodes

To help you plan your journey, maneuver nodes let you specify to specify how much thrust you want to apply in which places. They will map out your future trajectory after that thrust so that you can see if you need to thrust more or less or in a different direction or whatever. Changing maneuver nodes doesn't use any fuel, as it's only planning, not actually firing rockets.

Just as your position has three coordinates, so does your velocity. Thus, if we want to describe the direction in which you're moving, it will take three coordinates. It may be tempting to make them just the change in the three coordinates to describe your position. That works, after all. But it's usually a rather bad choice, and especially terrible if you're using spherical coordinates.

Rather, the game has a built-in orthonormal basis that it will show you that is very useful. One of the coordinates is the direction you're going. That's the "prograde" direction, and the opposite direction from it is "retrograde". For reasons that we'll get to shortly, much of the time, when you want to thrust at all, it is best to do it in either the prograde or retrograde direction.

Another coordinate is kind of away from the celestial body that you're orbiting, but not quite. This is the "radial out" coordinate, and its opposite direction is "radial in". There are two reasons why it is only "kind of". One is that you're not necessarily orbiting anything; we'll get to spheres of influence in a bit.

The larger reason is that directly toward some celestial body usually isn't orthogonal to the direction you're moving. We want the basis to be orthonormal, as otherwise, it will do weird things, so it needs to be orthogonal to the prograde direction. What they actually do is to pick the direction nearest to pointing away from the celestial body from among those directions orthogonal to the prograde direction. For those who know linear algebra, they're using the Gram-Schmidt process under the hood.

The third coordinate is the normal direction, which basically means, whatever direction is orthogonal to the first two axes. Its opposite direction is the anti-normal direction. This is the normal direction to the plane in which your trajectory lies.

When you specify how much thrust to apply at a given maneuver node, the you specify numbers in each of the prograde, radial out, and normal directions. Those directions are as you will be traveling at the node itself. This makes it fairly easy to do a purely prograde burn, or purely retrograde, or whatever.

Law of conservation of energy

The first thing to know about energy is that there is no such thing as energy. It simply isn't a real, physical thing. Rather, it's a made-up quantity that is designed to make computations easier. It can also help with your intuition about how things work.

What has happened over the centuries is that there are various situations in which scientists have noted that some computed quantity is constant, even as various components of it change. In a number of intuitively related situations, they decided to call this quantity energy. Most such situations don't matter to us, but converting between a rocket's speed and its height above an object is hugely important.

I promised that there wouldn't be any lengthy algebraic derivations, so I'll just give you the formula. If you're in orbit about some celestial body, let your speed relative to the body be v and your distance from the center of the body be r. Then there is some constant k such that v^2 - k/r is constant, even though both v and r will probably change as you move through your orbit. The constant k varies by celestial body. For those who are previously familiar with conservation of energy in a gravitational sense, I've factored out some terms and folded some constants into each other.

Furthermore, your total energy gives you information about the status of your orbit. If it is positive (i.e., v^2 > k/r), then you're on an escape trajectory and not coming back. If negative (i.e., v^2 < k/r), then you're either in orbit or else going to fall and crash.

If you are in a circular orbit, then v and r will be constant. A circular orbit implies constant distance from the planet, after all, which is what makes r constant. Furthermore, in a circular orbit, you will always have k/r = 2v^2, and your total energy will be -v^2 = -k/2r. This gives you a fairly easy way to compute k: get to a circular orbit and compute k = 2rv^2. This works regardless of the height of the circular orbit, so long as it's a stable orbit. You'll have to add the radius of the body you're orbiting to the altitude above sea level that the game displays for you to compute r. For v, you want the speed relative to orbit, not relative to the surface.

Remember that if you're in orbit and not on an escape trajectory, your energy is negative. A higher orbit (greater altitude) corresponds to higher (less negative) energy, even though you're moving slower.

Describing orbits

To describe your trajectory, we'd like an appropriate coordinate system. One could specify your current position and velocity as vectors, with three coordinates for each. But this is awfully inconvenient, as you'll have six coordinates, all of which are constantly changing in seemingly weird ways.

What we really want is a different coordinate system that is better suited to describing orbits. We'll need six coordinates, but we'd like one of those six to be your position on the orbit. Furthermore, we'd like for the other five coordinates to not be changing as you drift along in space on your orbit.

Those who don't have a strong math background may be surprised to learn that not only is it possible to devise such a coordinate system, but there are a lot of ways to do it. The game has one such coordinate system built-in that it will display for you. I'll present an alternative that is sometimes more illuminating than the one that the game gives you.

In-game coordinate system

Let's start with the game's coordinate system for describing an orbit. One coordinate is the altitude of your apoapsis, which is the highest point in your orbit. Another is the altitude of the periapsis, which is the lowest point in your orbit. The third coordinate is the argument of your periapsis, which is what would change if you rotate the orbit while leaving it in the same plane. The fourth argument is your inclination, which is the angle between the plane that contains your orbit and the equator of the body you're orbiting. THe fifth coordinate is the longitude of the ascending node, which is where along the equator of the body you're orbiting your orbit passes from below the equator to above it.

The game displays the apoapsis and periapsis prominently for you. Inclination is somewhat prominent on the map, though the numerical display shoves it off into the advanced orbital info tab. Longitude of ascending node (LAN) and argument of periapsis (LAN PE) are displayed numerically in the advanced orbital info tab. They're implicit in the drawing of your orbit on a map, but not displayed numerically there. The math is a little complicated, but those five coordinates uniquely determine your orbit.

You may find it puzzling that the game sometimes displays your apoapsis as negative. It does this when you are on an escape trajectory, rather than in orbit. There is a sound mathematical reason for it, and it is meaningful information about an escape trajectory. After all, you don't have a highest point when you're going to go off to infinity. I'll get to this in a later section.

Alternative coordinate system

The alternative coordinate system that I would propose keeps the argument of periapsis from above, but replaces the other four coordinates. The other four coordinates are your energy and your angular momentum, both divided by your mass. Your angular momentum is a vector, so it encompasses three coordinates. We'll effectively use spherical coordinates to describe your angular momentum, with one coordinate for the magnitude of it and two for the direction.

The direction of your angular momentum is basically equivalent to the inclination and longitude of ascending node as the game displays for you. Indeed, it can be explicitly written that way, with the longitude of the ascending node as the theta angle and the inclination as phi, at least up to a sign issue where the coordinates remain the same if you traverse the orbit in the opposite direction. Because you usually don't want to change the direction of your angular momentum other than to make it the same as that of your target, I find it easier to think if the two coordinates as just a direction on a sphere rather than two separate things.

Your energy and the magnitude of your angular momentum (both divided by your mass) are equivalent to your apoapsis and periapsis in the game's built-in coordinate system. You can compute either pair of coordinates from the other. If your energy is E, your angular momentum L, your apoapsis altitude A, your periapsis altitude P, and the radius of the body you're orbiting R, then you can compute L = sqrt(k(A+R)(P+R)/(A+P+2R)) and E = -k/(A+P+2R). In the other direction, A = (-sqrt(k^2+4EL^2)-k)/(2E) - R and P = (sqrt(k^2+4EL^2)-k)/(2E) - R. The exact formulas don't particularly matter, but that there are formulas to convert proves that the coordinates are equivalent.

At this point, you may be wondering why I'm pushing energy and angular momentum as coordinates rather than apoapsis and periapsis. The latter pair is graphically intuitive, after all, while the former is definitely not. The answer is that when you thrust, how it changes your apoapsis and periapsis is weird and unintuitive. How a thrust changes your energy and angular momentum is much easier to understand. I'll come back to this in a future section.

Conic sections

The shape of the path of one object as it passes by another while affected by the gravity of the latter object has some nice structure. Algebraically, it is a quadratic equation in the two variables for the plane in which the object's path lies. Geometrically, it is a conic section, that is, the intersection of a plane with a cone.

There are two main cases. If your energy is negative, so that you're in a stable orbit, the path will be an ellipse. Geometrically, an ellipse has two foci, one of which is at the center of the object you're orbiting. The ellipse itself is the collection of all points whose sum of the distances from the two foci is some fixed value. So basically, there is some point in space such that at any point on your orbit, the sum of the your distances from that point plus the center of the body you're orbiting is constant. The other point is geometrically intuitive, as the two foci are symmetric about the center of the ellipse.

If your energy is positive, so that you're on an escape trajectory, the path will be a hyperbola, or perhaps more properly, one arc of it. A hyperbola also has two foci, but the arc is the collection of points such that the difference between the distances to the two foci is constant. So basically, when you're on an escape trajectory, the distance to the object you're flying by minus that of some other point in space is constant.

The algebraic equation for a hyperbola actually gives something with two separate arcs, not just one. One arc is for points closer to one of the foci, and the other arc is for points closer to the other. When on an escape trajectory, if you regard the nearest point in the other arc to the body you're escaping as being the apoapsis, the negative of that height will be the apoapsis that the game reports for you. It also matches the formula that I gave in the previous section to compute the apoapsis from your energy and angular momentum. This probably isn't helpful, but a negative apoapsis does have actual meaning and isn't just a bug in the game.

The degenerate cases also give you a conic section. If your energy is exactly zero, your path is a parabola, which is another conic section. If you are traveling directly toward (or away from) the center of the body you're orbiting, your path is a line, or rather, half of one, as if you don't escape to infinity, you're going to go splat and stop. Geometrically, a half-line is also a conic section, obtained when the plane is tangent to the cone.

Modifying orbits

In order to get to where you want to go, it isn't enough to just know where you're going on your current trajectory. You need to know how to change your orbit so that it goes where you want. That's what this section is about.

When near a planet, thrust to go up, down, or sideways is intuitive enough. When off in space, it really isn't. Thrust in one direction at one point can have you going in a very different direction much later in the orbit. The best way to understand this is by understanding the results of thrusting in each possible direction. We'll break down what thrusting in the coordinate axes presented by the game does for you.

In order to rendezvous with some distant body, whether a moon, another rocket, or whatever, you basically need to make all of the coordinates of your orbit match those of the other object. If you use the game's built-in coordinates with the apoapsis and periapsis, how this works is simple enough if you only thrust at those two spots. Thrusting at apoapsis changes your periapsis and vice versa. Burning prograde increases the altitude of the other end and retrograde decreases it. Burning normal or anti-normal doesn't change your apoapsis or periapsis.

One problem with this is that burning inradius or outradius does weird things. Another problem is that it gives you no intuition at all about what happens if you thrust anywhere else. And sometimes, you'll want to thrust somewhere else, so that you can time where you cross paths to get there at the same time as your target. It is possible to make all prograde or retrograde thrusts off in space either from a circular orbit or else at periapsis or apoapsis, often to circularize an orbit. But that's rather limiting.

Burning prograde/retrograde

Burning prograde increases your velocity and angular momentum. Burning retrograde decreases both of them. The amount by which it changes your energy is proportional to your speed. A slight thrust when you are moving at 2000 m/s thus increases your energy by 10 times as much as if you were only moving 200 m/s. Here, it is critical to use your velocity relative to orbit, not relative to the surface. Thus, a given amount of delta V changes your energy the most when you were already moving very fast.

In order to see what this does to your angular momentum, a different coordinate system would be more natural. Earlier, we said that we wanted two coordinates for the plane in which your orbit lies to be the direction you're going and the direction away from the body you're orbiting, or more colloquially, "up". But usually, those aren't orthogonal to each other, so the outradius direction is as close to "up" as we can get while still being orthogonal to the prograde direction.

To see angular momentum, what you'd really like is for "up" to be one of the coordinate axes, and another one to be as close to it as we can get while still being orthogonal to it. This basically means taking the same basic vectors that you started with, but swapping their order before doing Gram-Schmidt. In this new coordinate system, thrusting in the modified "prograde" direction that is orthogonal to "up" increases your angular momentum by an amount proportional to your distance from the center of the object you're orbiting. Thrusting up or down does not affect your angular momentum.

Burning prograde or retrograde does not affect the direction of your angular momentum. Thus, it does not affect the equivalent coordinates of the inclination and longitude of the ascending node.

Note that the effect of burning prograde on your energy depends on your current speed but not your position, while the effect on your angular momentum depends on your position but not your speed. When you do the burn at periapsis, this makes the largest possible change to your energy, but the smallest change to your angular momentum. At apoapsis, it is the other way around.

Burning inradius/outradius

Burning inradius or outradius changes the shape of your orbit. It will typically change both your apoapsis and periapsis in peculiar ways, unless the burn is done at one of the two apses. It does not change your energy at all, however. Its effect on the magnitude of your angular momentum is as explained in the previous section. Burning inradius or outradius does not affect the direction of your angular momentum.

Burning normal/anti-normal

Burning normal or anti-normal does not affect your energy or the magnitude of your angular momentum. As such, it does not affect your apoapsis or periapsis. It likewise does not affect the argument of your periapsis.

You may have noticed that a large burn in the normal direction at a maneuver node makes your orbit end up higher than it was initially. I just said it wouldn't do that. The reason is that as you do the burn, you change which direction is your normal direction. The start of the burn could be exactly in the normal direction, but as the burn goes along, your direction is partially prograde or inradius or something else that isn't purely normal or anti-normal. You can avoid this effect by using SAS to point in the normal or anti-normal direction and turning as you go. For small burns in the normal direction, this doesn't matter much, but you may wish to compensate for it somehow if you need to change your inclination by something large like 50 degrees.

Burning normal or anti-normal modifies the direction of your angular momentum. I think it is pretty intuitive about what direction it turns your orbit in if you think of angular momentum as a direction rather than your inclination and longitude of ascending node as two completely independent coordinates. The rate at which it changes the direction of your angular momentum is inversely proportional to your speed relative to orbit.

Thus, you can make a given change in your inclination or whatever using much less delta-v when you are high above the body rather than close to it. For small adjustments, this doesn't matter much, but if you need to make large changes, or in the most extreme case, turn around to orbit in the other direction, it is more efficient to do this at a whichever of your ascending and descending nodes has greater altitude.

It can sometimes even save a lot of delta-v to first burn prograde so that your orbit reaches a very high apoapsis, then do a small burn at apoapsis to change your angular momentum, and then do a retrograde burn at periapsis to return your orbit to its previous shape. If you need to turn around to orbit in the opposite direction, this will use less than half as much delta-v as the brute force approach of a very long normal or anti-normal burn.

Hohmann transfers

Above, I said that the optimal directions to change your energy and angular momentum using as little delta-v as possible tend to be different directions. At apoapsis and periapsis, however, they coincide. Thus, it is more efficient to do your burns at these two locations when possible. You do a burn at apoapsis by however much you want to change your periapsis, and then the other way around. Or you can do them in the other order. This is called a Hohmann transfer.

It isn't always possible to do a Hohmann transfer. For one thing, if you're trying to land on a planet or dock with another rocket or whatever, it might get you there at the wrong time. If you're not already in a circular orbit, to first circularize the orbit so that you can have a second burn happen at the right time may take more delta-v than just changing your orbit in a single burn.

Another problem with Hohmann transfers is that as an ideal case, it basically assumes an instantaneous thrust, rather than one spread over a long period of time. If your angle in your orbit changes very little over the course of a burn, this is a very good approximation. It's not a good approximation to a five minute burn at periapsis when you start out orbiting on a forty minute period. That doesn't make Hohmann transfers into a bad idea so much as that it sometimes makes them impractical.

Bielliptical transfers

Pop quiz time: you're orbiting the Sun in a circular orbit with a speed of 10000 m/s. There are no planets in this system, so there isn't anything that you can use for a gravity assist. You want to crash head-on into the very center of the sun, or perhaps rather, burn up as you get close while traveling directly toward the center of the sun. How much delta-v does it take to do this?

There's an obvious answer: 10000 m/s. That's what it would take to stop so that you can go directly toward the sun. That's what it would take for the first step of a Hohmann transfer to a very low orbit. But that's not the correct answer.

Rather, you can do it in under 4200 m/s of delta-v. Instead of thrusting retrograde to stop, you thrust prograde to bring your rocket to just shy of an escape velocity. For a circular orbit of 10000 m/s, the minimum escape velocity would be 10000 * sqrt(2) ~ 14142 m/s. So you thrust by perhaps 4140 m/s, then wait a very long time until you reach apoapsis. If you reach apoapsis at, say, 1000 times your periapsis, then by conservation of angular momentum, you'll have 1/1000 times the speed. At that point, you're traveling about 14 m/s, and it only takes 14 m/s of delta-v to come to a dead stop. Then you wait a very long time and crash into the center of the Sun.

This is an extreme case, of course, but this sort of bielliptical transfer is the optimal way to make very large changes to your orbital height. The idea is that you first thrust prograde to get just shy of an escape velocity. Then you wait until apoapsis, where you're barely moving, so it costs very little to dramatically change your periapsis. Then you thrust retrograde at your new periapsis to circularize the orbit. One downside of this is that it takes a very long time to get to a very high apoapsis, however.

What is going on here is that at a very high apoapsis, it takes very little delta-v to change your angular momentum to whatever you want. If you want to change the direction of your angular momentum, this can be a relatively cheap way to do it. For example, if you're in a low equatorial orbit of a planet and want to shift to a low polar orbit, this approach is much cheaper than just burning normal for a long time.

A bielliptical transfer intrinsically costs a lot of delta-v. From a circular orbit, it takes sqrt(2)-1 times your current speed to get up to the very high apoapsis, plus sqrt(2)-1 times your final speed to get back down to your new orbit. Thus, it is a very bad choice for making small changes to your orbit. Still, it's good to understand for when you need to make very large changes to a low orbit.

Spheres of Influence

The way that gravity is believed to work is that everything in the universe has some force on everything else in the universe. One could quibble about what counts as part of "everything", but it certainly includes everything with mass. I say the way that gravity is believed to work because it really isn't well understood. The best known formulas are measurably wrong, not just the classical mechanics approach that dates to Newton, but also the adjustments suggested by relativity.

Gravity is hard to study because it is such a weak force. For example, two electrons repel each other because they have the same charge, and also attract each other due to gravity. The former effect is on the order of a tredecillion times as large as the latter. This is why after Newton wrote down his law of gravity (force = GMm/r^2, where M and m are the two masses, r is the distance between them, and G is some constant), it took about a century before Cavendish made the first effort at calculating the constant G.

One of the problems with implementing this model of gravity in a game is that the collection of all pairs of objects in the entire game is quite a lot. That's going to be computationally expensive. It also doesn't lend itself to nice simplifications such as orbits being known ellipses or hyperbolas.

Another problem with it is that it would make the game a pain to play, as there would be no such thing as a truly stable orbit. You'd put your satellite in some position and it would seem to stay there for months or years, then sometimes wander off and crash or blow up. Real-life space programs have to deal with this, but the game would be a lot easier if players didn't.

For example, you might think of Earth as being in a stable orbit about the Sun, but it's a lot less stable than you might think. That doesn't mean we're in imminent danger of crashing into the Sun. Rather, consider the length of a year. That's one orbit about the Sun, right?

But what counts as an orbit? If two observers are rotating relative to each other, they might disagree. For example, if an observer is slowly rotating at a rate of one rotation per year, he might think that the Earth is always on the same side of the Sun. The idea of a sidereal year is that we take how long it would look like it takes for the Earth to revolve about the Sun once, as viewed from very distant stars. A tropical year doesn't want to rely on some distant points, but is the time between two consecutive summer solstices. An anomalistic year tries to measure purely based on the orbit itself, and is the time between two consecutive times that the Earth is at its periapsis.

These are all reasonable definitions of a year, but they all give different year lengths. An anomalistic year is currently more than 20 minutes longer than a tropical year. And all three of these definitions of a year also have the length of a year change with time due to the effect of other objects pulling on Earth and the Sun besides each other.

The game's approach to simplifying this is to use spheres of influence. The celestial bodies (the Sun, the planets, and their moons) operate on fixed orbits. Everything else is affected by gravity of a celestial body, but does not exert any force due to gravity on anything else. For example, two rockets don't affect each other due to gravity, even though they would in real life.

Furthermore, an object is only directly affected by the gravity of one celestial body at a time. For all others, the effect of gravity on you is assumed to be the same as the effect of gravity on that one particular object. For example, your rocket could be affected by gravity properly measured from Kerbin or Minmus, but not both at once. Which one affects you depends on where you are. Loosely, the game ignores all but the strongest gravitational effect, but that isn't quite right.

More properly, each celestial body has a sphere of influence. If you are outside of its sphere of influence, then it has no effect on you. If you are inside the sphere of influence of multiple bodies, then you are directly affected only by whichever has the smallest sphere of influence, as being in that small sphere ensures that you are much closer to it than to the others. You are also implicitly affected by the bodies with a larger sphere of influence, but the effects of their gravity on you is presumed to be the same as that of the body in your sphere of influence.

For example, if you are not in the sphere of influence of any planet, then the game will compute the effect of the Sun's gravity on you, but no planets will affect you at all. If you are in the sphere of influence of Kerbin but not Mun or Minmus, then the game will compute the effect of Kerbin's gravity on you directly. It will not compute the effect of the Sun's gravity directly, but will assume that it is the same as the effect of the Sun's gravity on Kerbin. If you are in Minmus's sphere of influence, then the effect of Kerbin's gravity is assumed on you is assumed to be the same as on Minmus. The effect of the Sun's gravity on you is assumed to be the same as its effect on Minmus, which is itself assumed to be the same as its effect on Kerbin.

This is a hack that is not true at all of real life. It's the price of making a game playable. It usually isn't that far off from real-life gravity, at least on short time scales. But it does have some weird effects when you transfer from one sphere of influence to another.

One thing that you absolutely should consider when switching spheres of influence is what your velocity will be when escaping. Recall that v^2 - k/r is constant by conservation of energy. If you have just barely enough velocity to escape a sphere of influence, your speed will be basically zero when you leave. But adding a little bit of thrust long before you reach the boundary can give you a lot of speed upon leaving. If you were barely at an escape velocity before, so that v = sqrt(k/r), and then you burn prograde to increase your speed by t, then new velocity upon leaving the sphere of influence is sqrt(2vt + t^2). This will be greater than t, and for large planets like Eve, Jool, or even Kerbin, can be massively larger.

For example, if you're barely on an escape velocity from Kerbin at v = 3000 m/s, and then you add a mere 15 m/s, your speed upon leaving the sphere of influence will now be over 300 m/s. Add 60 m/s and your speed upon leaving will be over 600 m/s. That's an extremely efficient use of delta-v, and unless you're traveling to another planet with a fairly nearby orbit (e.g., from Kerbin to Eve or Duna), you nearly always want to leave the sphere of influence of a big planet with a lot of speed.

Vehicle controls

In order for a ship to go where you want, you have to have some way to control it. There are two basic approaches: manned and unmanned. In this section, we'll consider both.

Manned pods

There are a variety of pods that can hold kerbals and that you can use to control a ship. These only work to control a ship if there is a kerbal inside. Any kerbal can control the ship, but pilots can do it better than scientists or engineers.

The pods differ in a lot of ways, including size, shape, mass, and the number of kerbals that they can hold. Many pods have some degree of built-in batteries, reaction wheels, or monopropellant storage, though these tend to be pretty meager and not a viable replacement for dedicated units in any but the smallest of cases.

The cockpits are not radially symmetric, and are intended for planes, not rockets. As a consequence, they're pretty terrible as a way to control rockets.

The Mk1 Command Pod, Mk2 Command Pod, and Mk1-3 Command Pod command pods have good aerodynamic properties for launch, and are intended to go at the top of a rocket. They vary in radial size and number of kerbals. Their aerodynamics are not so great for landing, however, as they'll try to flip the rocket prograde and then you don't slow down as quickly as you might want. They're also relatively heavy for their number of kerbals.

The KV line of reentry modules have aerodynamics optimized for an atmospheric landing. So long as your lander is just a the pod on top of a stack of things with a radial size of small, you just need to get into the atmosphere at a low enough velocity as to not burn up and then aerodynamics will force you retrograde for a nice landing, at least if you have enough parachutes. Their aerodynamics are bad for launching a small rocket, however, and can easily flip you over.

The Mk1 Lander Can and Mk2 Lander Can are optimized to get kerbals into a lightweight module so as not to waste fuel. Their aerodynamics are terrible, and they're really only intended for use in a vacuum. Most planets and moons have no atmosphere, though, and the lander cans have the lowest mass of any command pods for their number of kerbals.

The PPD-12 Cupola Module is a dumb part whose only real use is contracts that require a base to have a cupola module.

The EAS-1 External Command Seat gives you a very lightweight way for a kerbal to control a ship. It's needlessly dangerous in most situations, but if you absolutely need to get your mass as low as possible for some purpose, this is a way to do it. Be warned that it cannot run crew reports.

Probe cores

In addition to the manned pods, there are unmanned pods that allow you to control a vehicle without needing to have a kerbal on board. This can be useful for a variety of purposes. They don't allow you to reset experiments like a scientist, repack parachutes or repair wheels like a parachute, gather a surface sample, or anything else that you need a kerbal for. But they can be perfectly appropriate for missions that aren't going to do any of those things, such as leaving a relay or telescope in space indefinitely. Unmanned command modules can also be useful for vehicles that will only sometimes have a kerbal present, so that you can control the vehicle without the kerbal.

By far the most important feature of an unmanned module is its SAS level. We'll get to what that means in the next section. But you'll want to get to the SAS level 3 modules as quickly as possible, and then completely ignore all of the ones with a lower SAS level, with rare exceptions. Because probe cores can offer high SAS levels, they can often make having a pilot unnecessary even on manned missions.

The probe cores that offer SAS level 3 can also store science experiment data, in addition to the normal probe core functions. Less advanced probe cores cannot do that.

SAS levels

SAS, or Stability Assist System, allows you to automatically rotate your ship in a particular direction. Rather than having to manually adjust the pitch, yaw, and roll, it can do this for you to get your ship pointing in the desired direction and keep it there. SAS can use both reaction wheels and engine gimbal to point you in the intended direction. This is very useful, and you'll want to get to SAS level 3 quickly. Higher levels of SAS give you more directional options of which way you want to point.

Your SAS level is determined by the highest SAS level of any unmanned command pod or pilot kerbal in a manned command pod on the ship. The possible SAS levels range from 0 to 3. For an unmanned probe core, the SAS level is determined by the module. For a pilot, it is his experience level, at least up to level 3. Only pilots offer SAS; engineers and scientists do not. It is also possible to have a vehicle that offers no SAS, not even level 0.

SAS level 0 offers only simple stability assist. Whatever direction you're pointing, keep you pointing in that direction. If this doesn't sound useful, its utility becomes immediately obvious when you try to fly a ship using only a scientist or engineer and no SAS. Without it, your ship will constantly rotate a little in one direction or another. When in a vacuum, you can make the ship stop rotating by briefly turning on time warp, but you can't do that in an atmosphere.

SAS level 1 adds prograde and retrograde as options. Retrograde is very, very useful for landing. Prograde is useful in a lot of situations.

SAS level 2 adds inradius, outradius, normal, and anti-normal as options. These are occasionally useful, but not very. The difference between SAS level 1 and 2 isn't important.

SAS level 3 adds pointing toward your target, away from your target, and in the direction of a maneuver node as options. The maneuver node option is extremely useful, and makes it much easier to use maneuver nodes. The target and anti-target options are only occasionally useful, but are so valuable for docking in space that I'd hold off on even attempting to dock until you have SAS level 3.

Passenger modules

Sometimes you want to take a lot of kerbals on a single mission. There could be a lot of reasons for this, such as having a lot of tourists to transport. You could load up your ship with a lot of manned command modules, and get the kerbal capacity you need that way. But that is inefficient.

A better approach is to use the passenger modules from the utility section. These don't offer any SAS, and don't give you any way to control the ship. You'll still need either a manned module or an unmanned command core, in addition to the passenger modules. But the passenger modules can carry more kerbals per ton than any command module other than the EAS-1 external command seat. They're also built to be in-line rather than designed to go on the top of a rocket, which makes it much easier to stack them and thus pack a lot of them in.

Coupling

It is possible and commonly even necessary to disconnect a ship into multiple pieces, or connect separate pieces into a larger ship. What you build on Kerbin usually isn't the shape that your rocket will keep for long.

Staging

In most cases, you'll need to stage rockets to get very far. That is, you have some big rockets that provide a ton of thrust to get you off the ground and take you well into Kerbin's atmosphere. After a while, those rockets run out of fuel, so you disconnect them, and have a smaller ship with smaller rockets that can take off from there. Depending on what you're trying to do, you may need to stage like this several times in a single journey.

As an example, suppose that we have a payload of 5 tons for command pods, science equipment, or whatever. We want to get that 5 ton payload to its destination. For simplicity, suppose that we start in a vacuum. Suppose that our last stage has a 4.5 ton fuel tank (which has 4 tons of fuel, counting both the oxidizer and liquid fuel, as well as the tank itself weighing half a ton) and a terrier engine, which ways 0.5 tons. That is good for a delta-v of 1729 m/s, with acceleration that starts at 6 m/s and increases to 10 m/s as the fuel tank empties.

Now suppose that we treat that 10 ton rocket as a payload and add another stage. The next stage will have 9 tons of fuel tanks and two terrier engines. That adds delta-v of another 1729 m/s, and also starts at 6 m/s of acceleration, increasing to 10 m/s as this stage's fuel tanks empty. I'm ignoring the mass of a decoupler for simplicity, but that wouldn't change the values much. After that, another stage that has 18 tons of fuel tanks and four terrier engines would add another 1729 m/s of delta-v with the same acceleration as before to get the 20 ton payload started. Another stage with 36 tons and eight terrier engines would do likewise. The net result of this four-stage rocket is that we have an 80 ton rocket that ends with a 5 ton payload, and has about 6915 m/s of delta-v and always has acceleration of at least 6 m/s available. That won't get you off the ground on Kerbin, but if it starts from orbit, that will get you pretty far.

One might ask, why do we need to make this several stages? Why not have the 80 ton rocket as a single stage with a ton of fuel? If we have just a single terrier engine, and have the other 74.5 tons as fuel tanks, that only gets you 5953 delta-v, which is less than before. Worse, your initial acceleration will only be 0.75 m/s, which won't even get you off the ground on the Mun. If you have eight terrier engines like in the previous example for the same initial acceleration, that reduces your delta-v to 5264 m/s. Having multiple stages works better. And that's even before we consider that later stages give you a smaller, lighter, more maneuverable rocket, which is a major advantage except when trying to take off in a dense atmosphere.

So why? Why does staging work? Without staging, when we finish a fuel tank, we have to carry that empty fuel tank around with us forever. Staging lets us discard the fuel tank and be rid of its extra mass. That allows the same remaining thrust to offer more acceleration than before. Discarding engines, too, is sometimes a drawback, but staging is still a net win if done properly. It is sometimes possible to discard empty fuel tanks without also discarding engines, but the mechanics of doing this properly and still having a decently shaped rocket are tricky. We'll come back to that in a bit.

Vertical decouplers

Perhaps the simplest method of staging is using the vertical decouplers. The TD-12 Decoupler, and about the same thing with other numbers, gives you a way to split two stages vertically. You can put the later stage on top of the earlier one, then disconnect them when you please. There are six such decouplers, and they correspond to the six radial sizes that the game offers.

The vertical decouplers all have arrows on them. When you fire a decoupler, it will disconnect the piece that the arrows point toward, but stick to the other side. You usually want the arrows to point up, as you discard the lower piece while letting the upper piece ignite its engines and take off. There are less common reasons to disconnect in a different direction, and the ability to rotate the decoupler before attaching it gives you this capability when you need it.

Usually the way that decouplers are used are as part of the game's staging sequence. Rocket engines, decouplers, and some other things can be grouped into stages. When you press the space bar (or whatever you reassign it to), it starts all of the parts on a single stage. The simplest, most common example of this is whatever decouplers are needed to discard empty fuel tanks and unwanted engines from your previous stage, while also enabling the engines that you'll fire for your next stage. You don't want to fire the engines for later stages too soon, or else they'll blow up the decoupler and whatever it is immediately attached to from the previous stage. Rather, you fire them when you decouple whatever they were attached to.

Radial decouplers

Using exclusively vertical decouplers tends to lead to some very tall, narrow rockets. That's fine for two or three stages, but once it gets too tall, this can make your rocket not be mechanically stable, so that it falls apart as you try to fly it. It's much like how if you hold a relatively short length of wire, it can seem plenty rigid, but a much longer wire of the same gauge will be bent downward by gravity.

The solution to this is radial decouplers. Rather than having all of the stages stacked vertically on top of each other, you attach some of them horizontally. This allows for a wider, shorter rocket. It also allows connecting pieces more rigidly, so that the rocket doesn't fall apart as you try to launch it.

There are three radial decouplers: the TT-38K Radial Decoupler, the TT-70 Radial Decoupler, and the Hydraulic Detachment Manifold. The TT-38K is the basic one, and the best choice for small, cheap projects. The hydraulic detachment manifold detaches the discarded portion with more force, but has such a high mass for the coupler itself that I've never seen a reasonable use for it. The TT-70 barely detaches with more force than the TT-38K, but it does stand off further, which reduces the chances of the detached piece immediately smashing into remaining parts of your rocket.

For large projects, I like the TT-70 best, as the extra force of the hydraulic detachment manifold barely matters when detaching debris weighing tens of tons, but the extra space that you start with can help. Additionally, the TT-70 makes it easiest to see exactly how things are lined up, so that if you need to separately attached multiple decouplers at almost exactly the same height, you can.

It is probable that one or more of your early attempts at using radial decouplers will fail spectacularly. Basically, you'll decouple something to toss it aside, then the next stage of your rocket will immediately accelerate into it. This causes a high-speed collision of the sort that causes parts to explode. Once you lose some of the rockets that you had counted on having, and might no longer have a symmetric center of mass, you're doomed.

The solution to this is that, if you use a radial decoupler in an atmosphere, make you're that you're accelerating prograde relative to the surface when you do it. Prograde relative to orbit or any direction that isn't particularly close to prograde is no good, as the air is likely to throw the debris that you rejected right back at you. Prograde relative to the surface means that you're acceleration is parallel to the direction in which the air will push debris, and so you don't get an unwanted collision. In a vacuum, this usually isn't a problem unless you have a really dumb design.

Stack separators

Sometimes you want to detach two sections of your ship but keep both. This can be the case if you want to take several small probes to the same area, so you make them various parts of one larger ship for simplicity to get them there. With normal decouplers, the decoupler itself will stick to one piece or another when you try to separate them.

The solution to this is stack separators. These work like vertical decouplers, except that they disconnect from the parts on both sides. As with the vertical decouplers, there is a stack separator for all of the radial sizes of rockets in the game. Stack separators cost a little more than vertical decouplers and add a little more mass, making them an inferior option if one of the pieces that you disconnect is debris that you want to be rid of, as it usually is. But anything that can be done with vertical decouplers could, in principle, be done with stack separators.

While the game has dedicated stack separators available, it is often better to build your own out of vertical decouplers. The reason for this is that while making an implicit stack separator just out of two vertical decouplers is dumb, you can put other things between the vertical decouplers. For example, you could put some batteries or reaction wheels, then attach I-beams to them. From there, you could have a lot of struts that use the "stack separator" as their base point, so that they won't be tied to either of your real vehicles when you separate them. I'll discuss this more when I get to struts later.

Engine plates

It is common for rockets to have a fuel tank with one rocket engine immediately below it. Or sometimes you have a rocket engine immediately below a stack of two or three fuel tanks. When you do that, you generally want the rocket engine centered on the fuel tank, and then vertical decouplers will disconnect the way you want.

Sometimes, though, you want to have a big fuel tank with several rocket engines attached below it. A ring of six nerv engines pushing a Mk3 Liquid Fuel Fuselage Long is my most common case of this. Sometimes you may want to have several dart or vector engines under an S3 or S4 fuel tank. I've had reasons to load up with a bunch of spark engines. The normal vertical decouplers don't work very well if you have several engines like this, as a vertical decoupler must attach to exactly one piece.

The solution is engine plates. So long you don't have an engine at the center of the piece it is attached to, you can attach an engine plate instead. This functions like a vertical decoupler, but has structure to allow you to attach the next stage to the fuel tank or whatever the engines are attached to, rather than having to pick an engine. For example, you could have a Kerbodyne S3-14400 Tank with six dart engines attached to it, then an EP-37 Engine Plate, and then another Kerbodyne S3-14400 fuel tank for the next stage. The engine plate will be attached to both fuel tanks, with the dart engines covered up under the engine plate but not required for structural strength.

If you use engine plates, make sure that you see the option to choose a length. You can adjust to any one of five lengths in the vehicle assembly building. You usually want to pick the shortest length that will fit the engines or whatever else you're hiding under there without clipping into the previous stage.

FTX-2 External Fuel Duct

When you discard previous stages, you might sometimes wish to only discard the empty fuel tanks while keeping the engines. This is possible, though sometimes it makes the rocket so awkwardly shaped as to be a bad idea. What you can do is to have several fuel tanks that are all there to feed the same engine. You use FTX-2 external fuel ducts to connect the fuel tanks to each other, so that fuel can flow from one to another. You wait until the first tank(s) are empty, then discard them by staging, while keeping the others.

An alternative version of this is to have several fuel tanks each of which have a rocket attached, and fire them all simultaneously to get enough acceleration for what you need. You route the fuel ducts such that all of the engines draw their fuel from one or a few of the fuel tanks, and then when that first round of tanks is empty, you discard them, as well as the attached engines. Meanwhile, you keep the rest of the engines firing into the next stage, then all drawing fuel from a different set of fuel tanks.

Taken to its extreme, this is called asparagus staging, as you end up with rockets that look like a handful of asparagus. This was more common before the aerodynamics model was redone in version 1.0. The problem is that a handful of asparagus is not known for its good aerodynamic properties, so you end up with rockets that would be fine in space, but struggle to get out of Kerbin's atmosphere without flipping over, falling apart, or other things that ultimately cause rockets to blow up. Rather than having a large amount of asparagus staging, it's usually better to just use bigger fuel tanks and bigger rockets for better aerodynamics and better structural stability.

That said, a modest amount of asparagus staging can sometimes be useful. Just don't get carried away with it.

It is also important to realize that if two fuel tanks are connected by a coupler or stack separator, you don't need a fuel duct to pass fuel from one to the other. While couplers disable fuel crossfeed by default (to prevent an engine from an earlier stage from consuming the fuel intended for a later one), you can enable it if you want to.

Docking

Suppose that you design your dream space station. It has some of this, some of that, and a bunch of some other things. Space for 72 kerbals. 50 tons of monopropellant. Four science labs. In all, the space station has a mass of about 1300 tons. And you want to put it into a low polar orbit of Jool.

So you design a magnificent rocket to deliver your station to Jool. With all of the staging needed, your gigantic rocket weighs over 40,000 tons. You press the launch button to take it to the launchpad. Then you see that you've got boosters hanging far off of all sides of the launchpad. So far off that the lack of structural support beneath them makes the rocket unstable. It falls apart and blows up on the launchpad before you get a chance to launch. Oops. Does this mean that your dream is dead? Hardly!

In the previous section, we talked about starting with big rockets and splitting them into smaller pieces, commonly to discard empty fuel tanks or other debris. It's also possible to do the reverse of this. You can launch multiple pieces, then connect them to create a larger ship.

There are a variety of reasons why you might want to do this. One is as a way to create larger bases or space stations than it is practical to launch all in one go. Another is to temporarily connect two ships so that you can transfer kerbals, fuel, scientific data, or whatever else you want to transfer from one to another. A vehicle may run out of fuel and become stranded, and you may want to send a rescue ship to pick it up and bring it home. You can have a base or rocket with a bunch of detachable modules, so that you can have that science lab or mining gear when you want it, and not have to carry it around with you when you don't.

Docking ports

One way to connect ships is with docking ports. There are three radial sizes of docking ports available (tiny, small, and large), with multiple form factors for the small radial size. If you want to connect two ships in the future, you give them both a docking port of the same radial size in the places where you will want to connect them. Later, you can have the two docking ports touch, and they will stick together. We'll talk about how to actually dock in a much later section, as it is tricky to do.

One advantage of docking ports is that you can pick exactly where the two ships will dock. They could be rotated a little differently from how you planned if you don't have some way to control that axis when you dock. But other than that one rotational degree of freedom, they'll end up attached exactly how you planned.

In addition to docking, you can also undock. Click on a docking port that is linked to another and you can undock to disconnect them. Thus, the connection from a docking port can be only temporary if you want it. You can dock, transfer fuel, data or whatever, and then undock and carry on.

Advanced grabbing unit

The other option for docking is the Advanced Grabbing Unit, or its recently added smaller cousin. The idea is that one component doesn't have to have any docking equipment, but the other ship can latch on using an advanced grabbing unit. This is the only option when you don't get to design one of the ships, such as if you want to grab an asteroid. It is also an option for grabbing other ships.

The advanced grabbing unit generally doesn't give you nearly as precise of an assembly as the docking ports. You get to pick the precise point on your own ship that has the advanced grabbing unit, but you don't get to pick the precise point that it will latch on to on the other vehicle. Rather, it's probably going to be off somewhat from what you had planned. In addition to being rotated wrong, the point that you latch on to can be off in two dimensions.

When using an advanced grabbing unit, the resulting, combined ship isn't likely to still be radially symmetric. Sometimes your center of mass can be significantly off from your center of thrust, which makes it very hard to control. You can adjust how you've grabbed it after making the initial grab, but realistically, you're never going to get it exactly perfect.

Connecting two ships via an advanced grabbing unit allows you to transfer scientific data and kerbals between them. It does not allow you to transfer fuel, however. When you only want to transfer data or kerbals, using an advanced grabbing unit is easier than needing to line up two docking ports perfectly.

Landing gear

You don't actually need any of the equipment in this section. When you want to land, you can burn retrograde to slow to a near stop, then touch down gently, landing on your engines or whatever the lowest point of your rocket is. So long as you positioned equipment correctly, you can have kerbals get out, plant a flag, reset science equipment, or whatever else you need, and then get back into the vehicle. All that said, a lot of the gear in this section sure does make landing a lot easier.

Lander legs

When landing, there are two basic problems. One is that you could hit the ground too hard, causing parts to explode as part of the collision. The other is that you could land in area so uneven that your ship falls over. The latter is sometimes okay if you're landing on Kerbin at the end of a mission and just going to recover the vessel anyway, but usually means that you're stuck and can't take off. Lander legs can help with both problems.

All parts in the game have some maximum velocity at which they can hit the ground without breaking. Deployed solar panels will generally shatter at the slightest direct touch, but so long as you're not landing on the solar panel itself, everything can handle touching down at 4 m/s, and just about everything can handle up to 6 m/s. Depending on how you build your rocket, you may be able to handle a little higher than that.

So what happens if you hit the ground at a little over 6 m/s? If whatever touches the ground first can't handle that speed, it explodes. If the lowest part can handle that speed, but is a rigid part connected to something above it that can't, the part above it can explode. If what touches the ground first is lander legs, then their springs can absorb a lot of the shock of landing, so that other parts further up the rocket don't explode. This won't always make it safe to touch down at 12 m/s, but it might make it safe to hit at 8 m/s. Ultimately, you'd like to land at under 6 m/s, but lander legs can bail you out if you go slightly over that.

Lander legs are springy, and they explode not by whether they touch the ground at higher than their rated speed, but whether that provides enough force to crush the leg and destroy it. For example, a LT-2 Landing Strut is officially rated at 12 m/s impact tolerance, but I've had a vehicle land at over 35 m/s on LT-2 lander legs with no damage.

The springs in lander legs don't help you if you land in water, however. They just submerge right into the water, and whatever you were try to protect by putting lander legs under it then smacks into the water, and may explode.

The other advantage of lander legs is that they stick out further from your vehicle. A given position of the rocket touching the ground is stable if the line through your center of mass and the center of the planet or moon you land on passes through the convex hull of the collection of places where your vehicle touches the ground. You may not be familiar with the mathematical concept of the convex hull of a set, but it's a pretty simple concept and easy to look up. Lander legs stick some points that hit the ground further out from your rocket, giving you a significantly larger convex hull, and allowing you to land on a steeper slope without tipping over.

Another use of lander legs is that you can adjust the spring in them after landing to raise or lower your entire vehicle slightly. I've used that to line up pieces for docking. Be warned that if you don't revert the spring strength to automatic before switching away from the base, it is likely to explode when you switch back. I'm pretty sure that that is a bug.

That said, lander legs are hardly indestructible. Too much force on them will cause them to explode themselves. This can happen because you hit the ground too hard, or because you have too few to hold up your rocket. The game says that engineers can repair broken lander legs, but I've never seen them break in a repairable manner. Rather, they explode and are gone.

There are three models of lander legs in the game. The largest, the LT-2 Landing Strut, is usually what you want to use. Only for landing very small vessels does it really make any sense to save some mass by using the others.

Rover wheels

If you want to land in a particular spot, you can aim carefully and land right there exactly. Depending on the precision needed, that can sometimes be very difficult. For scanning surface features, you need to be within 4 m, and that sort of precision can be very difficult to achieve when landing from space. One solution to this is to put your vehicle on wheels and then roll around on the ground. Get kind of close, such as within 1 km, then drive over to the surface feature and stop right next to it.

Rover wheels can also give you a lesser degree of the same benefits as lander legs. They can't support as much mass as lander legs, and they don't stick out as far, so you should prefer lander legs to wheels if you don't actually want to roll around.

Rover wheels are also prone to breaking, and will not roll after they break. A level 3 or higher engineer can fix wheels if they break. They can also explode, but the threshold that it takes for them to explode is much higher than for them to merely break.

Rover wheels vary in their size, how much weight they can support, how fast they can go, and how much torque they can apply to brake or push up hills. I generally prefer the TR-2L Ruggedized Vehicular Wheel, as it can support more weight and move faster than the smaller wheels. The RoveMax Model XL3 is the largest rover wheel by far, but it cannot steer, so a vehicle based on them cannot turn.

Ladders

Sometimes, you need a kerbal to go outside and do something. It is nice to be able to get back into the craft without needing the awkwardness of firing up the jetpack. For a simple EVA report or surface sample, you can stay holding the door. If you need to plant a flag, repack parachutes, repair wheels, or reset certain science equipment, ladders can often make it so that you just climb up or down at your leisure to get to where you need to go. On Kerbin, Eve, Tylo, and Laythe, gravity is stronger than your jetpack, so you can't go up at all unless you have something to climb.

There are three types of ladders in the game, all placed in the utility section. For the most part, the Kelus-LV Bay Mobility Enhancer is the best of them, as it is the longest, and they all have the same mass.

Ladders other than the Pegasus I Mobility Enhancer can be deployed and retracted as needed. That allows you to get them out of the way when they aren't needed, land safely, and then deploy your ladders and have them exactly where you need them.

Airplane wheels

In addition to rover wheels, there are also airplane landing gears. They are built to allow you to take off and land, which means they have to function while rolling on the ground at very high speeds. They are also built to keep the rest of your plane well off of the ground, so that you don't crash due to a slight bump.

The problem with all of this is that it assumes that you're building a plane, which you probably aren't. If you are, then yes, do look at the airplane wheels. If not, then ignore them.

Parachutes

The final type of gear intended for landing is parachutes. As with ladders, these are found in the utility section, not the ground section.

As you pass through an atmosphere, drag from the air will slow you down relative to the surface. It is important here that your speed is relative to the surface, not relative to orbit. The idea of a parachute is to have a large surface area that will catch the air to slow you down a lot more than just ordinary air resistance would. Depending on your design, this can sometimes slow you down enough that once you enter the atmosphere, you don't need any further thrust to land safely. Other times, it just slows you down most of the way, so that you only need a little bit of thrust at the very end to land.

Parachutes only work at all in an atmosphere. That means that you are restricted to Kerbin, Eve, Laythe, Duna, and Jool. Parachutes are completely useless everywhere else, and merely a waste of mass.

Furthermore, parachutes will slow you down more in a denser atmosphere. They would provide so little force in a thin, upper atmosphere that they won't even deploy. Rather, they wait until there is some substantial amount of air before they deploy. That means that parachutes aren't that effective on Duna, but are extremely effective on Eve. Parachutes are generally ineffective on Jool because they won't fully deploy until you get near sea level, by which point, the pressure is so high that rocket engines won't work at all.

Parachutes effectively harness the air to exert force to pull your ship in a retrograde direction. But they can only exert so much force without tearing off. By default, parachutes won't deploy until you're traveling slowly enough for it to be safe. In some cases, you can rely on simple drag with the air before parachutes are deployed to slow you down enough to reach this threshold.

On Eve or Jool, you can't just rely on a bunch of parachutes as the only way to slow you down. Those planets are large enough that you'll burn up in the atmosphere before you slow down enough for parachutes to deploy unless you either burn retrograde or use a heat shield. That can happen on Kerbin, Laythe, or Duna, too, if you come in too fast, but parachutes alone are enough from a low orbit.

There are two types of parachutes: drogue and main. Drogue parachutes are smaller and tougher, so they can safely deploy at higher speeds. They don't offer as much drag once deployed as main parachutes, however. Ultimately, you probably want some of each type.

Parachutes also partially deploy at one stage, then fully deploy at another, lower stage. If they fully deployed too soon, the huge amount of force to slow you from high speeds could tear your ship apart. The partial deployment is based on atmospheric pressure, while full deployment is based on altitude. Normally, the order of parachute deployment is that drogues partially deploy, then main parachutes partially deploy, then drogues fully deploy, and then your main parachutes fully deploy. Breaking this into four stages makes it easier to have progressively increasing drag without too big of a spike all at once that tears your ship apart.

That said, you do have to be smart about parachute placement. You generally want to place them high up on your craft. They'll pull you retrograde from wherever they are placed. If they are placed up high, this pulls your ship right-side up, so that you can land in the direction you want. If placed too low, they could flip you upside-down.

Still, that doesn't mean that you want to put a lot of parachutes all on the highest point. For a heavy vehicle, that much force applied to a single part can sometimes yank it off entirely. Rather, you want to spread them out quite a bit to apply their force somewhat evenly, while keeping the center of parachute force substantially above your center of mass.

If landing is the end of a mission, such as to recover a vehicle on Kerbin or leave a probe permanently located on another planet, then parachutes can be single use. If you have an engineer of level 1 or higher, you can repack parachutes to use them again. This allows you to use parachutes to land once, then repack them, then deploy them again the next time you land. The engineer has to be able to get close to a parachute to repack it, so you may need to have a lot of ladders available. This can also restrict parachute placement to places you can reach.

The game has five particular models of parachutes, but other than the extremely early game when the Mk16 Parachute is the only one available, the Mk2-R Radial-Mount Parachute and Mk12-R Radial-Mount Drogue Chute are really the only ones that are useful. In particular, the larger Mk16-XL Parachute and Mk25 Parachute are completely useless. Using two of the analogous radial parachute (and an aerodynamic nose cone where the larger parachute would have gone) instead will get you more deployed drag for less mass and less non-deployed drag.

Communications

There are two basic reasons why you'll want to have your ships be able to communicate with the home base on Kerbin. One is sending information from Kerbin to the ship to tell it what to do. If you have a pilot on board, you always have full control of the ship, as the pilot can do whatever he needs to. But probe cores don't know what to do, so they won't be fully functional unless you can contact them from Kerbin to tell them what to do.

The other reason is sending information from the ship back to Kerbin. When you run some science experiment, you can recover the data by flying the ship all the way back to Kerbin and landing. But you can also get some science immediately by transmitting the data back. The latter often gives you less science than returning the vessel, but you can also transmit the data, immediately rerun the experiment, and get the rest of the science that way. That gives you some science now and some later, rather than all of it having to wait for later.

Controlling probes

If you have a pilot on board, you'll always have full control of the vessel with whatever SAS capabilities the pilot can offer, even without any communications link back to Kerbin. But without a pilot, you'll either have only very limited controls (no SAS) from a scientist or engineer, or only what controls a probe core can give you. And if you can't contact the probe core, you can't make it do what you want.

Exactly what you can make a probe core do while you cannot contact it depends on your difficulty settings. The default is that it will not let you create maneuver nodes, and will not let you do any amount of thrust beyond maximum or nothing. You can also set it to give you no control of the ship at all. Or you can make things easier on yourself and always have full control of a probe even without a communications link.

Communications gear

There are two types of communications gear: antennas and relays. They work just as well for transmitting data, but relays can receive data, as well. Relays allow a spacecraft to act as an intermediate node when some other ship wants to transmit data, while antennas cannot do this. As such, if you're going to bring a relay, there is scarcely any point to bringing an antenna, too.

That might lead you to ask why use antennas at all. The answer is that antennas are smaller, cheaper, lighter, and can be deployed to avoid aerodynamic issues. You generally need to ask whether you need a vessel to relay communications from other vessels. If not, then make things simpler and bring an antenna instead of a relay. Ground-based relays aren't very useful, as the planet they're on blocks them at least half of the time, so you likely don't want a relay for vessels that are going to land somewhere and stay there.

There are six strengths of antennas for you to use. The weakest is built into command pods, but other than doing experiments around Kerbin (or Mun, once you upgrade the tracking station), is really only intended to let you contact some other relay. The next two are really only intended to connect to another vessel in the same planetary system, and likely the same planet or moon within the system.

If you're using an antenna, you might as well use the most powerful one you have access to, with exceptions for very small and light vessels. Even the top end Communotron 88-88 is smaller, cheaper, and lighter than the RA-2 Relay Antenna that is only 2% as powerful as it. For a relay, it can depend on just how much of a problem the bulk and awkward aerodynamics of an RA-100 are. Regardless, it is pretty much always better to use one of a larger relay than to combine multiples of a smaller one.

While weak, the Communotron 16-S can be handy for flying in an atmosphere. Unlike all other antennas, it is surface mounted, rather than deployed, so wind won't snap it off. Unlike the surface mounted relays, it is very lightweight and does not cause aerodynamic problems.

CommNet

In order to be able to communicate with a vessel out in space, you don't necessary need a direct signal from Kerbin to the ship. Indeed, sometimes that is impossible because there is some planet or moon in the way--often the one you're landed on. Rather, you can have the ship connect to one satellite, that satellite connects to another satellite, and the second satellite connects back to Kerbin. Or however many hops you want.

Your network of satellites that can act as intermediate hops to connect any spaceship to Kerbin is called CommNet. Only vessels that have a relay rather than an antenna can act as intermediate hops. Larger, more powerful relays allow connecting over longer distances. You can also put several relays on a satellite, and they will partially combine to further increase distances.

A communications link isn't necessarily just there or not there. There can be intermediate amounts of strength. For purposes of controlling a probe, any weak connection is good enough. For transmitting science, a stronger connection will get you more science. This is unrealistic, as what they would do in real life is to still get all of the data back, but just take longer to do it. For example, transmit every bit 5 times instead of 1, then do a majority vote to determine what the real bit is.

Exactly how many relays you need to send out depends on your communications needs and how reliable you need the link to be. For example, if you have one powerful relay near a planet, any other craft near that planet only needs to connect to that one relay, which can send the data back to Kerbin. And that might work fine most of the time, but occasionally, you'll be on the opposite side of the planet from that relay and lose the connection. Or if you're going to land, then "occasionally" might mean about half of the time.

That is solvable by having a bunch of relays about the planet. It is generally better for them to be in a relatively high orbit, so that the planet only infrequently blocks one relay from seeing another. You can have one satellite with a bunch of relays on it for the main jump back to Kerbin, and the rest be much weaker. That way, if your vessel can see any one of the relays, it can connect to it, which will connect to other relays to get to the big, powerful one, and from there, send the data back to Kerbin.

The transmission strength matters for both ends of the link for a connection. The strength of the link is basically the geometric mean of the strength at the two ends. You can also put a satellite with a bunch of relays in orbit about Kerbin, to have a far stronger connection to it from deep space than any of the ground-based satellites offer.

Transmitting science

Any part that is capable of storing science experiments results can ask to transmit the results back to Kerbin. It will actually use any antenna or relay to do the transmission. Transmitting data back uses electricity, and if you run out of electricity before you finish the transmission, it fails. If this happens, you still have the data on your ship, but don't get any science for it.

The amount of science that you get by transmitting data depends on the strength of your connection back to Kerbin and the particular experiment. An EVA report or crew report will give you the full science value by transmitting it. Other experiments will only give you a fraction of the science value from transmitting it, and you'll have to go land back in Kerbin to get the rest of the science value. To a scientist on Kerbin, someone telling you about a moon rock just isn't as good as actually having the moon rock in your hands.

Heat

When traveling through space, it is quite possible for a spacecraft to overheat and explode. This section is about what causes that and how to avoid it. While rocket engines put out considerable heat, I'll ignore them for the rest of this section, as they don't put out enough heat to cause any parts to overheat and fail unless you botch your design by having a rocket engine pointed right at some other part of your ship.

Atmospheric entry

The main source of overheating and burning up is moving too fast inside of an atmosphere. It is sometimes called re-entry, as the most natural place for it to occur is when a ship returns to Kerbin. It is also possible to overheat and explode before you get out of the atmosphere in the first place, though doing so on Kerbin takes a sufficiently botched design that it's unlikely that you'll ever do so by accident.

The reason why atmospheric entry causes overheating is mysterious to a lot of people. Some think it is due to friction with the air, but this is completely wrong. Traveling at 2500 m/s at a height of 40 km above Kerbin can cause serious heat issues, even though it results in far less friction with the air than traveling at 100 m/s at sea level. You can readily verify this by looking at how quickly your velocity changes due to air resistance. And traveling only 100 m/s at sea level causes no heat problems at all.

It is sometimes said that the heating of atmospheric entry is caused by compressing air, as in the ideal gas law, PV = nRT. This is kind of true, but not very helpful. It's not at all obvious what to use for the volume, and whatever you use, air is rushing in and out. Having P, V, n, and T all changing wildly makes it difficult to glean any insight. (R ~ 8.314 J/K-mol is a constant and does not change.)

A better model is that of gas molecules bouncing around randomly. The kinetic energy of a molecule is .5mv^2, where m is the mass of the molecule and v is its speed. An atmosphere may be composed of a mix of numerous gases, but a single molecule isn't going to cause your ship to overheat, so we may simplify this by assuming that all of the molecules in an atmosphere are average in some sense (but not velocity, where the average velocity vector is 0). Thus, the temperature of a molecule is proportional to the square of its speed.

The key insight here is, speed in which reference frame? Oxygen molecules on Earth typically have a speed of around 500 m/s relative to the nearby surface of the Earth. But if you're in a spaceship and moving at 2000 m/s relative to the surface, those oxygen molecules aren't moving at 500 m/s relative to you. They're probably moving at around 2000 m/s relative to you. And that means that, to you, they seem many times hotter.

If an air molecule is moving at v m/s relative to the planet it is near, and you are moving at w m/s relative to that planet, then the molecule is moving at somewhere between w-v m/s and w+v m/s relative to you. For complicated reasons (you can derive this with a double integral over a sphere if so inclined), if the direction of the molecule relative to the planet is uniformly random, then the root mean square (not average when doing kinetic energy computations) speed of the molecule relative to you is sqrt(w^2 + v^2). If you're traveling fast enough for atmospheric entry to be an overheating problem, then w is going to be much greater than v, so this will be a little greater than w.

The upshot of this is that, when you're approaching an atmosphere at high speeds, the apparent temperature of that atmosphere will be approximately proportional to the square of your speed relative to the surface of that planet. And yes, it's relative to the surface, not orbit, though in the game, that doesn't make a very big difference other than on Jool. Still, a given orbital speed will be a smaller speed relative to the surface if you're traveling east near the equator.

The rate at which the atmosphere will heat your ship is proportional to (the difference between the atmosphere's apparent temperature and your ship's temperature) times (the density of the atmosphere). The first component of temperature difference is just how thermal transfer works. The second is because heat is transferred by collisions with individual molecules, and the more of them that are there for you to hit, the more heat can be transferred.

Or at least, that's what it would be if you weren't moving. The front part of the ship will hit many more molecules as it cuts a path for the rest of your ship to follow. The exact term is complicated, but at high velocities, you roughly have to multiply by (your speed relative to the atmosphere) / (average speed of an air molecule). This means that the front part that is hitting the brunt of the atmosphere will heat up much faster than side parts, even if both see the same apparent temperature of the atmosphere.

The upshot is that the temperature to which the atmosphere will heat your ship is roughly proportional to your speed squared, and the rate at which it will push the front parts of your ship toward that temperature is roughly proportional to your speed cubed. That 100 m/s at sea level ship doesn't cause overheating because the equilibrium temperature is cool enough to not be a problem. But if you enter an atmosphere at 3000 m/s, that's likely to cause enough heating to cause your ship to explode, at least once you get to denser portions of it. Still, the very top of an atmosphere is so thin that even very high velocities are okay.

Still, it is not the case that the effective temperature of air depends only on your speed. The effective speed of individual molecules will be roughly your own speed when you are traveling fast enough, but different gases will have different root-mean-square speeds even at the same temperature. At a given temperature, all gases will have about the same kinetic energy per molecule, but that means that those with lower masses will tend to have higher speeds. While I haven't done precise measurements, it is fairly obvious that Jool's atmosphere causes much less heating than would be expected from your speed as compared to other atmospheres, while Eve's seems to cause more of it.

The Sun

The other major source of heat that can cause your ship to explode is the Sun. Basically, if you get too close to the Sun, you die. Technically, this could add to atmospheric entry heating, but no atmospheres are close enough to the Sun to be a real problem. Thus, other than when trying to get into a low orbit about the Sun, you can generally ignore the Sun's heating.

For science purposes, the boundary between a low and high orbit about the Sun is one million km, or one thousand Mm, as the game will display it when you approach that threshold from above. So long as you're either in a high orbit about the sun or barely in a low orbit, you can largely ignore such solar heating. You'll get warnings that your ship is hot while near the edge of a low orbit, but it won't actually blow things up. If you want to get much closer to the sun, you absolutely can cause your ship to explode.

Blackbody radiation

The main source of cooling in the game is blackbody radiation. All normal matter emits electromagnetic radiation unless it is already at absolute zero. That's just how the universe works.

To explain the name, an ideal blackbody is an object for which radiation reflected is negligible as compared to radiation emitted. There are basically two ways this could happen. One is that very little radiation reaches the object, so that radiation reflected will be neglible regardless of whether it is reflected or absorbed. The Sun is a good example of this. The other is an object that absorbs nearly all radiation rather than reflecting it. An object that does this for the visible light spectrum will visibly appear black, which is the source of the name. Other portions of the electromagnetic spectrum matter, too, especially infrared if dealing with objects near room temperature.

According to the Stefan-Boltzmann Law, the intensity of blackbody radiation that an object emits is proportional to the temperature to the fourth power. The temperature here has to be a distance from absolute zero, so it is customary to use Kelvins (not Celsius or Fahrenheit!). There are some complications, in that some objects will radiate more heat at a given temperature than others. In particular, those that reflect more energy (so as to absorb less) also emit less. But for a given spaceship, the rate at which you cool down via blackbody radiation is proportional to temperature to the fourth power. Which is to say, it scales up very quickly as you get hotter.

This allows you travel in an atmosphere at a high enough speed for it to have an apparent temperature of 3000 K without your ship ever exceeding 2000 K, at least so long as the atmosphere is thin enough not to heat you up too quickly. So long as the rate of heating from the atmosphere (or from the sun) is less than the rate that you'll shed that heat via blackbody radiation at a temperature just shy of what will cause you to explode, you'll be fine.

The spectrum of blackbody radiation emitted also depends on the temperature. At room temperature, it is almost entirely in the infrared range, but as an object heats up enough, it can start emitting a lot of visible light. That's what causes very hot objects to start glowing red. Or orange or yellow if they get hot enough. The game doesn't modify the color changing as objects heat up, though, other than by making things turn red.

Thermal control systems

Most of your cooling will come from blackbody radiation, but you can also use thermal control systems to transfer heat within your ship. This is mainly used to cool mining parts, but you can also use it to transfer heat from the front portion of your ship that is heating up tremendously to a radiator that isn't, and then the radiator can dissipate that heat off into space. That's typically not a great idea for handling atmospheric entry, as the good thermal control systems will break off from drag with the air. It can help if you want to go unreasonably close to the sun, however.

Part fragility

All parts have some maximum temperature for safe operation. If they go above this, they are liable to explode. Many parts have a maximum temperature of 2000 K. It is often handy to think of your entire ship as having a maximum safe temperature of 2000 K. So long as the ship stays below that, you're fine.

Some parts have a lower maximum temperature, however, most commonly 1200 K. That's true of all science equipment and rover wheels, for example. Such equipment largely needs to be protected from overheating. In some cases, this means putting them inside of a service bay, so that they won't get hot during atmospheric entry. In others, it can mean leaving them out of the mission entirely. You really don't need rover wheels to go diving into Jool's atmosphere or low orbit about the sun. If you can't protect them, such as when trying to land a large rover on Eve, you'll just need a much more robust retrograde burn than normal to protect them from atmospheric entry.

There are also some parts with a maximum temperature greater than 2000 K. Most of the time, this doesn't offer any benefit as compared to a maximum temperature of 2000 K, as if something else reaches 2000 K and blows up, your mission probably still fails. The key exception is for the front parts that take the brunt of the heating during situations where parts are likely to overheat.

Heat shields

One strategy to protect your ship from death by overheating is to put some parts that can handle very high temperatures in the front of the ship, so that the brunt of the heating is borne by parts that can handle it. While there are some parts that could be reappropriated for this use, heat shields are specifically designed for it. All heat shields have a maximum temperature of at least 3300 K. Furthermore, most of them have some ablator that can boil off to absorb heat and protect the heat shield even against heating loads that would otherwise have caused it to exceed 3300 K and explode.

Heat shields aren't really intended for getting closer to the sun. They're unnecessary if you just want to get to low orbit for science purposes. They can help if you want to get closer than necessary for science reasons, but even heat shields will overheat and explode if you get too close.

Rather, the real intended use of heat shields is for heating from atmospheric entry. That's obviously useless for bodies that don't have an atmosphere. It's also pretty easy to land on Kerbin, Laythe, or Duna without a heat shield. If you're in a low orbit just outside of the atmosphere, then slow down a little to get your periapsis into the atmosphere and wait, you'll reach the ground without overheating, at least provided that the atmospheric entry heating is mostly hitting parts that can handle 2000 K.

Rather, the real use of heat shields is if you need to hit an atmosphere at higher speeds. If you want to land on Eve or reach Jool's lower atmosphere, then expect to overheat and explode unless you either have a heat shield or use a lot of fuel to burn retrograde and slow down.

Alternatively, a heat shield can allow you to approach a planet at a higher velocity without having to burn fuel to get into a low orbit first. For example, if properly shielded, you could set your Kerbin orbit to a periapsis of about 30 km while orbiting one of Kerbin's moons, enter Kerbin's atmosphere at around 3000 m/s, have the heat shield take the brunt of the atmospheric entry heating, and survive. If you wanted to first return to a low orbit about Kerbin before entering its atmosphere, you'd need about another 1000 delta-v of fuel to burn retrograde. That sort of aerobraking can save you a lot of fuel.

Still, heat shields can only do so much for you. If you want to enter an atmosphere at 20000 m/s, your heat shields will overheat and explode, and then so will the rest of your spacecraft. So while they increase the speed at which you can enter an atmosphere, they hardly make it infinite.

Additionally, while it usually isn't that hard to use heat shields to protect a small craft that only needs to land to finish its mission, it's much harder to properly shield larger vehicles that will have additional stages and need to subsequently move around. Heat shields are unaerodynamic, which makes it easy for drag to cause your ship to flip over, have something else besides the heat shield take the brunt of the heating, and still explode. Heat shields having a lot of drag is an intentional and necessary feature of their design, as otherwise, they wouldn't slow you down to survive landing. Try leading with aerodynamic nose cones and watch your ship crash into the ground at speeds too high for the parachutes to safely deploy, which would be the alternative if heat shields were more aerodynamic.

Mining and refueling

One challenge to any mission is that you only have so much delta-v. Once you've used up your fuel, you can't thrust anymore, and you're done. Hope you've made it back to Kerbin, or at least reached your intended destination.

Except that the universe is made out of rocket fuel. All that you have to do is land somewhere, pick up some dirt, and fill up. That's not how real-life works, of course, but it is how the universe of Kerbal Space Program works.

In order to refuel, there are three things that you need: mining drills to dig up ore, tanks to hold the ore, and converters to process the ore and turn it into your needed fuel. You can't create xenon, but you can convert ore into all of the other types of fuel: liquid fuel, oxidizer, and monopropellant.

You can refuel on planets or moons. You must be landed, however; splashed down doesn't count. And you can't drill for fuel on Jool or the sun, since you can't land there. You can also refuel on asteroids or comets, though asteroids have a limited amount of ore that you can drill up. Planets and moons have unlimited ore.

Excavators

There are two excavators in the game: the 'Drill-O-Matic Junior' Mining Excavator and the 'Drill-O-Matic' Mining Excavator. As you might guess, the latter has higher cost, mass, size, and output.

The critical difference is that the full excavator can dig up ore anywhere that there is ore at all. The junior version can't get any ore at all if the concentration is too low. At default ore concentrations, the larger excavator can get ore absolutely anywhere that you're landed, while the junior one won't be able to find anything in some places. If you reduce the ore concentration of the universe, there will also be places that the larger excavator can't pick up any more, but still fewer of them than where the junior one will fail.

It can be quite a nasty surprise to land somewhere in a mission that requires you to refuel, and then learn that there is no ore to be had. Mission failed. Because of that, I don't recommend using the junior drill at all unless you absolutely have to.

Both drills are radially mounted, so if you only have one, your center of mass will be off center. As such, if you're going to use mining drills at all, you probably want two, placed in a radially symmetric manner.

Ore

The game regards ore tanks as a type of fuel tanks. There are three, in different sizes: radial, small, and large. They all helpfully give their size in their name. Unlike most fuel tanks, ore tanks can jettison their contents without needing a drain.

You have to have at least one ore tank or else mining drills won't have anywhere to place their ore. They can't pass ore directly to a converter. But even the smallest ore tank as a small buffer is plenty for most purposes. If using radial ore tanks, you might want two, so that you can make them symmetric. But if you're only ever going to run a converter while you're on the ground mining, two radial tanks or one small (whichever is easier to fit into your design) is plenty for a lot of purposes.

There are some non-obvious reasons why you might want more ore holding capacity, however. One is that in career mode, there are missions to drill up a particular amount of ore on a particular body, generally less than 3000 ore. If you have two large holding tanks, and dump their contents just before leaving a base to return to the space station, but leave the drills running, they'll fill up with 3000 ore while you're away, at least if you're away for long enough. If you later pick up a mission to mine some amount of ore on that particular planet, you can switch back to the base, instantly complete the mission (as it credits you with acquiring the ore when you switch to the base), and dump the ore again in preparation for the next mission.

Full ore tanks have a very high density, as they have far more mass than a rocket fuel container of the same volume. Most rockets will float if they splash down in the water. If you have some full ore tanks around, you can make your ship heavy enough to sink. If you sink to the bottom of an ocean, you can perform science experiments while landed in the ocean, rather than merely splashed down. That gives you separate science rewards--including some on Laythe that are otherwise unobtainable. You can also return to the surface if so inclined by jettisoning your ore tank contents.

A third reason to consider having a lot of ore tanks is that they have a better ratio of wet mass to dry mass than liquid fuel tanks (without oxidizer), as well as offering a different and often more convenient form factor than the jet fuel tanks. By packing ore instead of liquid fuel, then converting it to liquid fuel while in flight, you can get more delta-v for nerv rockets from less mass and much less space than if you had instead packed jet fuel directly. You do need at least one jet fuel container as a buffer for conversion, however. This only works for very long flights that have plenty of time to convert the ore into jet fuel, and really only lets you burn as much at a time as you have space to store jet fuel. But nerv rockets tend to be targeted at very long distances, especially interplanetary, so this fits their typical use case perfectly.

Converters

There are two converters: the Convert-O-Tron 125 and the Convert-O-Tron 250. As you would probably guess, the latter has higher cost, mass, size, and output. But while the large converter will give double the output per unit time of the small converter, it actually burns only one fifth as much ore. As such, the larger converter gives you ten times the ore efficiency of the smaller one.

The two converters use the same amount of electricity while running. Both converters and excavators use a lot of electricity, so you'll likely want some pretty robust electricity generation methods to power them. Alternatively, you could use the trick of waiting for your batteries to fill, starting both the converters and excavators, and then switching back to the space center. Your electric charge level only changes while you're watching a base, so the converters can keep running without needing more electricity while you're elsewhere.

Unlike with excavators, the smaller converter does fundamentally work, however, at least when landed on planets and moons. It just takes ten times as long to refuel as the larger one would. The smaller converter is basically unusable on asteroids, where you can only recover a finite amount of ore before the asteroid runs out. But elsewhere, it's really just a question of how long you're willing to wait.

Thermal efficiency

Excavators and converters burn a lot of electricity, and that mostly gets turned into heat. If not cooled properly they can overheat. They do need to get fairly hot, as they work better once they've heated up, but overheating reduces their efficiency.

You can make excavators and converters work by strobing them off and on. Turn them on, let them heat up, then turn them back off and let them cool down. But the faster solution to let them run continuously is to use thermal control systems. Those will automatically cool excavators and converters down to their optimal running temperature if they had been running long enough to exceed that. Thermal control systems have a finite cooling capacity, so make sure that you bring enough to handle however many converters and excavators you want to run at once.

Scanners

The ore concentration varies by biome, and is rolled randomly when you create a new game. Rather than just landing somewhere and finding out how much ore is there (possibly none, depending on your settings), you can also use a scanner to find out before you land.

There are three scanners. The M700 Survey Scanner must be used first. The idea is that you put a satellite in a polar orbit of moderate height, and then run a survey. What would happen if this were realistic is that a survey would take place over an extended period of time, as you pass over every portion of the planet over the course of many revolutions. The polar orbit allows that, while a non-polar orbit does not, as it does not take you over the poles. But that would be a pain, so instead, the game just gives you the results of the scan almost immediately.

The game uses your antennas or relays to transmit the results of the survey back to Kerbin. As with transmitting science, this takes electricity, and if you run out, the transmission can abort. For most bodies, this doesn't take very much, but it takes quite a lot for Jool, which is huge. As such, you'd better bring either a lot of batteries or some very robust electricity generation, which that far away from the sun, probably means fuel cells. You cannot do a survey of the Sun.

The other two scanners are intended to get you a higher resolution of the ore concentration in particular locations. As the ore varies by biome, you can largely figure out where to go by comparing the survey scanner results to a biome map from any device that gives you KerbNet access. As such, I don't personally find the smaller scanners useful.

Electricity

A number of pieces of equipment use electricity. As such, you need to have sufficient electricity available to power them. The game doesn't have any restrictions on voltage or current, but only on how much electrical charge you have. If you're generating electrical charge faster than you're using it, your stored electrical charge goes up until all of your batteries are at maximum capacity. In the reverse scenario, it goes down until it reaches zero, at which point, some things that are using electricity must shut down. We'll break this into three sections, to cover generating electricity, storing it, and using it.

Consuming electricity

First up is the things that consume electricity. Deciding how to handle electricity for a given ship generally starts with determining how much you need. That's driven by your mission, and what equipment you need to run. Only after you know how much you need does it make sense to choose how to store and generate it.

Probe cores

Unmanned probe cores use a very modest amount of electricity, ranging from 1.2 to 4.8 charge per minute. For many purposes, that is negligible. If you have no means of generating electricity at all, however, that is very much not negligible. Slowly drain electricity for days and eventually you run out. That forces the probe core to shut down, which leaves you with absolutely no control of the satellite. Often, this means that a satellite is dead and useless, though it can be recoverable if you have solar panels that eventually pick up some sunlight. Remember that once a probe is out of electricity, you cannot give it any commands, so forgetting to deploy solar panels before you run out of electricity can sometimes cause a mission to fail. Having a nuclear generator on board will mean that you always have far more than enough to power a probe core.

You can greatly reduce the electricity consumption of a probe core by putting it in hibernation mode. That limits your control of the probe, but that's fine if it only hibernates while doing a time warp. That can help with short missions that have no electricity generation, or for missions that have very limited power generation, such as relying on solar panels near Jool or Eeloo.

Reaction wheels

Reaction wheels also use electricity, though typically not very much. Even the largest of them only uses 0.6 charge per second, and you usually don't run reaction wheels for very long. As such the electricity usage of reaction wheels is usually negligible. The main exception is if you have a manned spacecraft with no means of generating electricity. If your mission is too long, you can run out of electricity and then be unable to turn. This can also be a problem if you were relying on solar panels and then have to operate in the dark for too long.

Rover wheels

Rover wheels also use electricity to power the rover. They range from 1 to 5 electric charge per wheel per second. The TR-2L Ruggedized Vehicular Wheels that I usually recommend use 3.5 charge per second per wheel. Multiplied by several wheels, this can easily cost you tens of charge per second.

Even so, rover wheels only use electricity when accelerating. Even moving fast while not accelerating doesn't use charge. As such, it can work to bring plenty of battery capacity and only modest electricity generation, then stop and park for a while when you need to recharge.

Rover wheels are only used when landed, and when landed, whatever you've landed on will block the sun about half of the time. Or more, if you're in a crater. As such, you may not wish to rely on solar panels to power a rover, as that will make the rover only usable in the daytime.

Antenna transmissions

Having antennas transmit science can burn electricity quickly. Antennas range from 20 to 200 charge per second, with the larger relays all using 68.6 charge per second. That's quite a lot, but the transmissions tend to be in short bursts. If you start a transmission and then run out of charge, the transmission fails. You'll still have the data, but have to start over on transmitting it. The usual solution to this is to have sufficient battery capacity to handle an entire transmission, and then let the batteries recharge over a potentially longer period of time.

Dawn engine

Each dawn engine uses 8.741 charge per second at maximum thrust. As that maximum thrust is only good for 2 kN, they're really only good for very small spacecraft, and even then, you might want several. As such, dawn engines can burn through electricity in a hurry.

Furthermore, the nature of dawn engines greatly restricts how you can reasonably power them. If you use fuel cells to generate their electricity, then the mass of rocket fuel burned to generate the electricity will be about 2.25 the mass of the xenon fuel used. If you count the fuel in addition to the xenon when computing the specific impulse, then you basically divide the specific impulse by 3.25. A specific impulse of 1293 would still be the highest in the game, but it's not that far superior to nerv engines, and with a lot more drawbacks.

Relying on nuclear generators can be a problem because of their mass. You'd need nearly a ton of generators per dawn engine, and all that added mass would greatly decrease the delta-v. If you have too few nuclear generators to power the dawn engines continuously, then you can run them at lower power. That can work, but it's something of a nuisance, as it can turn a one hour burn into a five hour burn. And you have to be there watching that spacecraft the whole time. And remember that you can't time warp while burning, though you can physics warp, but only up to x4 speed.

That really leaves solar panels as the ideal way to power a dawn engine. But that only works if you have access to plenty of solar power, which you won't if in the shadow of some planet. And even solar panels don't generate very much energy if too far away from the sun. If near Jool, they generate much less electricity per mass than a nuclear generator. Near Dres, they're close to even with a nuclear generator, and even that assumes that the angle is optimal. You probably don't need dawn engines to go to Eve or Duna, leaving trips to Moho or a low orbit about the sun as the places where they work well. But they do work really well in a low orbit about the sun.

Mining gear

The 'Drill-O-Matic' Mining Excavator uses 15 charge per second, and the Convert-O-Tron 250 uses 30. As you probably want to run multiple excavators and the converter all at once for long periods of time, this can burn quite a lot of electricity.

One approach is to effectively cheat by starting up the mining gear, then switching to a different ship. So long as you switch before you run out, the mining gear will keep running, but the stored electric charge won't change while you aren't watching the ship.

The other approach that makes it easy to run continuously is to use however many fuel cell arrays (plural!) you need, typically packing one per excavator and two for a converter. Yes, this burns fuel, and the point of mining is to replenish your fuel. But apart from an extremely low ore concentration, mining will tend to replenish your fuel much faster than the fuel cells burn it. On net, you're still gaining fuel, but only a little slower than before. That can often be worth it for the convenience.

Robotics

Robotic arms use electricity to run. For servos and cylinders that only move briefly, this can often be negligible. For rotors that are intended to run for long periods of time, this can use a lot of electricity quickly. If trying to power a helicopter, using fuel cells is nearly mandatory.

Generating electricity

There are several basic methods of generating electricity, and they all have their uses.

Solar panels

One way to generate electricity is with solar panels. Basically, if a solar panel is pointed in the right direction to pick up sunlight, then it will convert that sunlight to electric charge.

There are two basic types of solar panels: static and deployable. The OX-STAT and OX-STAT-XL Photovoltaic Panels are fixed in place and cannot be moved or rotated. The other solar panels can rotate on one axis to point in a better direction and pick up more sunlight. One drawback of deployable panels is that they're far more fragile, and will break off if traveling very quickly through an atmosphere. They also tend to shatter if you so much as touch them. Static panels are far more durable.

Deployable panels do have some advantages, in that they can pick up more sunlight by changing their angle. A static panel pointed in a random direction will on average only pick up 1/4 as much sunlight as if it were pointed right at the sun, while a deployable one will on average pick up 1/2 as much sunlight. Or at least it would if it weren't blocked by other parts of your spaceship, which tends to happen more to deployed panels than static ones. If you're smart, you place a static solar panel in a location where it won't be blocked by the rest of your ship.

The amount of sunlight that reaches a panel also varies with your distance to the sun. Sunlight intensity is proportional to distance to the negative second power. This means that when near Moho, you tend to generate five times as much power as when near Kerbin. Near Eve is a little less than double Kerbin, while Duna is less than half. Dres gets you about a tenth of the power of Kerbin, and Jool about 4%.

How far away is far enough that solar panels don't make sense anymore is a judgment call. Even near Moho, nuclear generators always work and solar panels only when not blocked by Moho. Meanwhile, solar panels can be competitive with nuclear on an electricity per mass ratio as far out as Dres if aimed properly, and on an electricity per funds basis all the way out to Eeloo.

Nuclear generators

The game only has one nuclear generator for general use, the PB-NUK Radioisotope Thermoelectric Generator. It generates 0.75 electric charge per second at all times, and without requiring fuel. The key drawback is that they cost 23300 funds each, which is quite a lot for career mode. And if you want to generate a lot of electric charge using them, that will take a lot of generators. In some cases, a ship can cost several hundred thousand funds just for the generators alone.

Still, depending on a spacecraft's electrical needs, sometimes it is very convenient to be able to just put a single nuclear generator on the ship, have all the electricity you need, and be done with it.

Rocket alternators

Some rockets have an alternator that will generate electricity while the rocket is running. This is a very inefficient way to generate electricity, but it is a free bonus if you were going to use the rocket anyway.

Fuel cells

If you want to burn fuel to generate electricity, the way to do it is fuel cells. Fuel cells burn liquid fuel and oxidizer in the usual ratio, and will generate electricity at a rate of 80000 electric charge per ton of fuel. That can be a problem if you're relying on fuel cells to generate electricity for long periods of time when in deep space. When landed and readily able to mine for replacement fuel, the fuel consumption of the cells usually isn't a problem. As such, fuel cells are largely a way to power whatever you need when on the ground, as opposed to in orbit or in deep space. Fuel cells can also readily provide the power for short missions.

Storing electricity

You can store electric charge in batteries. Adding more batteries increases the maximum electric charge that the spacecraft can store. Command pods and probe cores generally have some modest electrical storage capability. For most missions other than putting a simple relay into its intended orbit, you'll want to add some batteries for additional electrical storage capacity.

There are in-line batteries of the tiny, small, and large radial sizes that can be placed in a spacecraft in much the same way that you'd place a fuel tank. There are also radial attached batteries that can be placed anywhere on the side of something. Both conveniently have their charge storage capacity in their name. For all batteries, the mass is proportional to the storage capacity, at 20000 charge per ton.

Radial batteries are less robust than in-line batteries, with a max temperature tolerance of only 1200 K, as compared to 2000 K for the in-line batteries. Radial batteries are often intended to be placed inside of a service bay, which will protect them during atmospheric entry.

Radial batteries can be packed very densely inside of a service bay. To place them, turn off the snap to grid option, and turn on the rotational symmetry option to place however many you want--likely eight. You can place batteries partially on top of each other, and it's pretty easy to fit three rings of Z-400 batteries on the bottom of a 2.5m service bay. You can then fit three more rings on the top if so inclined, for up to 48 batteries and a total charge of 19600 in a single 2.5m service bay. Or you can have fewer batteries and leave space for other equipment such as generators or science gear.

Aerodynamics

Aerodynamics is basically for what happens when you're in an atmosphere surrounding a planet or moon. Some planets and most moons don't have an atmosphere, which makes aerodynamics irrelevant. But the atmosphere is quite important when you're in it.

Atmospheres have several effects in the game. The cause parts to blow up if you travel to fast through them, as covered in the heat section. They slow you down when trying to take off, so that it takes more fuel to escape. They also slow you down when you approach for landing, so that the act of landing can take far less fuel than it would otherwise. And they also threaten to flip you over if you do something wrong.

Atmosphere density

The amount of drag due to air resistance for a given shape moving at a given velocity is proportional to the density of the air through which you're traveling. That drops off roughly exponentially as you get higher. Because it is zero on some planets and most moons, there is zero drag there.

You can compute drag as (some constant for the shape of the vehicle) * (density of the atmosphere) * (the square of your current speed relative to the surface). The vehicle shape constant can and probably will vary as your vehicle rotates. When relying on parachutes to land, those parachutes will typically provide nearly all of your drag, so it's basically your number of parachutes, at least if weighted properly due to some parachutes being larger than others.

It's important to understand that drag is proportional to the density of the atmosphere where you are, which is not the same thing as atmospheric pressure. For those who know calculus, if we ignore the fact that gravity varies with height, the atmospheric density is basically the first derivative of atmospheric pressure as a function of height, or possibly the negative of it, depending on how you orient your axes.

For those who don't know calculus, the force that the atmosphere exerts on a given patch of ground is the total weight of the air that is above that patch of ground. On level ground, we can compute that the force is equal to the air pressure at that altitude times the area of the patch of ground. If we make an arbitrary rectangular box with axes pointed in the appropriate directions to have top and bottom sides, the amount of air above the bottom of the box is equal to the amount of air above the top of the box plus the amount of air inside the box. You can see this by examining what happens to a particular molecule: if it is above the bottom of the box, it is either also above the top, or else below the top and hence inside the box. Thus, the difference between the force on the bottom of the box and the force on the top is the weight of the air inside the box. With a bit of arithmetic, the average density of air inside the box is ((pressure at the bottom of the box) - (pressure at the top of the box)) / (height of the box). By normalizing the box height, you can get that the atmospheric density at an altitude of between k and k+1 km on a given planet or moon is roughly proportional to (pressure at altitude k) - (pressure at altitude k+1).

Drag is proportional to speed squared, so when traveling at high speeds, you'll have a lot of drag even in a relatively thin atmosphere. Even so, if you're pointed in a direction where your ship is too good aerodynamically, it is possible to crash all the way into the surface while still going too fast for parachutes to deploy. Approaching a planet at a wide angle so that you have to pass through a lot more atmosphere before you touch down can often fix that problem. For example, when coming to land on Kerbin, you might pick an orbit with a periapsis of about 30 km, then let air resistance slow you down enough to land safely.

Of the objects that have an atmosphere, Duna has the thinnest. At sea level, it is 1/15 of the pressure of that of Kerbin, and about 1/20 of the density. That's not quite thin enough to ignore it, but it won't give you that much trouble unless you have egregiously awful aerodynamics. Laythe's atmosphere has 3/5 of the pressure of Kerbin's at sea level, and about 1/3 of the density. Eve's atmosphere is five times the pressure of Kerbin's at sea level, and about three times the density. Jool's atmosphere at sea level has 50 times the pressure of Kerbin's, though once you get deep enough into Jool's lower atmosphere that rockets don't work at all, is scarcely matters exactly how thick it is.

In real life, provided that an atmosphere isn't so dense that there isn't very much space to pack in more air, each gas component of the atmosphere has its concentration drop off exponentially with height. For example, every 5 km of altitude could drop the concentration by half. But how fast it drops off with altitude depends on the temperature, the force of gravity, and the molecular weight of the particular gas. The temperature and force of gravity at a given altitude are the same for all gases, but the molecular weight is not. Heavier molecules drop off faster with altitude. For example, the concentration of carbon dioxide will decrease with altitude faster than that of water vapor, which in turn, drops off faster than helium. This is why the Earth's upper atmosphere consists almost entirely of hydrogen and helium, even though for the entire atmosphere, they are present in far smaller amounts than nitrogen, oxygen, or argon.

The game does not explicitly model having different gases in an atmosphere like this, as demonstrated by there being portions of the atmosphere of Laythe and Eve where density goes up as altitude does. For game purposes, you can just think of the density of an atmosphere as something that drops off pretty quickly with altitude.

Cross-section area

Most of the time, you'll want to reduce the effects of the atmosphere. Drag basically acts on the cross-sectional area that gets hit as you travel. If you view your rocket from far away with the camera oriented such that the rocket is traveling directly at you, what you can see is roughly the part that the atmosphere acts on. Making your rocket wider will cause more drag, but making it longer will not. Thus, to reduce drag, it is ideal for a rocket to be very long and narrow. That is, of course, the opposite of what you want it to be in order to land.

It's also important that your rocket be symmetric. If it is pressing a part of the rocket on one side to slow you down, you want it to also have an equal force on the opposite side. Otherwise, drag could provide a potentially strong net torque and flip you around in a direction that you don't want.

Aiming rockets

A rocket that is built to be rotationally symmetric only has drag provide no net torque if it is rotationally symmetric around the direction that the rocket is traveling. If it is going sideways, the portion that the atmosphere acts on is not symmetric at all, so it can provide a strong net torque, and that could flip you in a direction that you do not want.

If your rocket is rotationally symmetric and pointed directly prograde relative to the surface (since the atmosphere gets dragged along with a planet's surface), then there will be no net torque, and you don't flip over. Directly retrograde also works for the same reason. Usually you want to be prograde when taking off and retrograde when landing. Importantly, these are relative to the surface, not orbit.

Usually at launch, you want to point straight up initially. If your rocket landed on some planet and is taking off from wherever it landed, then you probably won't be directly vertical at launch, but you want to get pointed that way quickly. You have a little bit of time, as you'll initially be moving slowly enough for there to be minimal drag.

You may wish to tilt a little to one side to start your gravity turn early on. But you're going to have to point directly prograde for a while, which will allow gravity to move your prograde direction more and more horizontal as you go. If you tilt too far to the side, too soon, you don't get out of the atmosphere.

Once you pick up some speed in the lower atmosphere, you need to stay exactly prograde, or at least very close to it. Otherwise, you'll flip over. Perhaps not on Duna, but certainly on any of the other places with an atmosphere. Once you get to a high enough altitude for the air to be very thin, you can then change your direction to adjust your gravity turn without further fear of flipping over.

Nose cones

Some shapes naturally allow air to flow by them much more easily than others. Most of the functional parts in the game such as fuel tanks and rover wheels really aren't very aerodynamic. The game offers aerodynamic nose cones that are designed specifically to reduce drag. The idea is that you put them on the top of your rocket so that most of the portion of the rocket that is cutting through the air is nose cones that are designed to have minimal drag. This can greatly reduce your drag at takeoff, and thus allow you to reach orbit with less fuel.

Nose cones don't do much to prevent you from flipping over, though. If you're turned to the side, the atmosphere is acting strongly on other portions of the rocket besides the nose cones, and that's what flips you over.

Service bays

One way to prevent awkwardly shaped parts from causing a lot of drag is to hide them so that they don't hit the air at all. Service bays allow you to do this with small equipment such as batteries or science gear. They don't just protect the gear from blowing up, but also prevent it from causing undesirable drag.

Fairing

Sometimes, you need to put something that is awkwardly shaped on the top of a rocket, and it just can't be covered with nose cones. Trying to carry a rover to some distant planet is a common situation. Needing to put a large relay on your satellite is another. You can build fairing to go around whatever your awkwardly shaped object is, and reduce drag in a manner similar to nose cones.

The idea of fairing is that there are several fairings of different radial sizes, and you can place one in-line in your rocket, like a fuel tank. You can then build the fairing by having several slices at chosen radii and lengths to cover whatever comes above it. That will give you a more aerodynamic shape when taking off from Kerbin. Once you leave Kerbin's atmosphere, you can discard the fairing.

Be warned that the act of removing fairing is explosive, and discarded portions of fairing can hit other parts of your rocket and destroy them. It's really only safe to have one fairing on a rocket, and only at the very top of the rocket, above all other portions.

Science

One of the major activities in the game is acquiring science information. In both science and career modes, this is how you unlock most of the equipment in the game. Even after you've unlocked everything, getting the rest of the science available is kind of the point of the game. That said, the game is open-ended enough that if you want to make something else besides science into the point of the game, you're welcome to do so.

Each combination of a situation, a biome, and an activity can yield separate science data. Well, sometimes. Your situation depends largely on your altitude, and includes things like being landed on the ground or flying low in space. Your biome is which portion of the planet you're over, as being over an ocean will probably be a different biome than being above a mountain. The activity is the type of science measurement, such as measuring air pressure or temperature. All of these deserve further explanation.

Situations

There are four basic situations: landed, splashed, flying, or in space. Flying and in space each break up into two different situations on the basis of your altitude. Depending on your altitude, flying could count as flying low or flying high, which are two separate situations. Similarly, in space low and in space high are separate situations. As such, there are six possible situations. The boundaries between flying low or high and between in space low or high seem to be set at some arbitrary threshold for each body, and are not a simple function of the moon's size, for example, though larger ones tend to have higher thresholds.

If any portion of your ship is touching solid ground, then you're landed. If you're touching water but not solid ground, then you're splashed. In particular, being in water but having some portion of your ship touching solid ground counts as landed, not splashed. I once had a situation where my craft was splashed, but if I opened a service bay, the bay door touched the bottom of the lake I was in, which made the ship count as landed instead. The game won't directly tell you whether you're landed or splashed, but you can query it by attempting an activity that cannot be done while splashed and seeing if the game will allow it. Splashed is only possible on bodies with oceans, which is to say, Kerbin, Eve, or Laythe. You cannot have the landed situation on Jool, as it has no solid ground to touch.

Flying means inside of an atmosphere, but not landed or splashed. Flying is thus only possible where there is an atmosphere, which means Kerbin, Eve, Laythe, Duna, or Jool. The sun also had an atmosphere in early versions of the game, and might still have one, but you can't fly there, as you'll burn up long before you get there.

In space means not landed, splashed, or flying. For planets or moons with an atmosphere, you must pass through flying low and flying high to get from landed or splashed to in space or vice versa. On planets or moons without an atmosphere, you go directly from landed to in space low.

Biomes

A biome is a geographic region. Some biomes are strongly correlated with things that are readily visible from space, such as a large crater, but many are not. Even when the biome is mostly visible from space, the edges aren't quite what they look like. Being in a particular biome when flying or in space basically means that that biome is the one you're above. More precisely, if you were to draw a straight line from your current location to the center of the planet, it's the biome where that line would pass through the surface.

Some combinations of a situation and an activity give science data that varies by biome, while some will only give one result for an entire moon. For example, a temperature scan when flying low will give different results for each biome, but when in space low, will only give one result globally. Thus, you could get separate science data for each of 11 separate temperature scans when flying low on Kerbin, one for each biome. But you can only do one temperature scan when in space near Kerbin, as trying to repeat it when above another biome will give the same results and not separate science data.

You can identify the biome that you're currently in by running an activity whose results depend on the biome. That doesn't help very much if you're trying to find a particular biome that you're not currently in. Rather, you can find biomes by using KerbNet. Relatively advanced drone cores have a biome scanning mode, as does the mobile processing lab. This will show you a map of the biomes near you. Your current location is at the center of the map, and the other biomes are color-coded. You can click on a location to see the biome at that location. Up on the map is the direction that you're currently traveling relative to orbit. When landed, it will generally be east, as not moving relative to the surface is moving east relative to orbit.

Acquiring data

There are several different ways to gather science data. If you want to get all of the science data from a planet, you'll have to hit every possible combination of a situation and a biome. That means landing in every biome, and also splashing down in every biome where that is possible. You generally want to land once, do all of the experiments that can be done at once, and then leave. I recommend getting the flying low data shortly before landing, as you'll naturally hit all of the biomes that you're about to land it. For moons without an atmosphere, you may also get the in space low data that way shortly before landing.

For planets with no atmosphere, the most efficient way to get the data from all biomes while high in space is to get into a polar orbit just above the threshold to count as high in space rather than low. Stop thrusting, but just pick up data from each biome as you cross it. As the planet rotates, things that were not under your orbit initially will eventually come under it, and then you can pick them up without further thrusting.

For planets that do have an atmosphere, you can repeat this process three times to pick up high in space, low in space, and flying high separately. You can see what is coming on future orbits and time warp when you can see that you won't pick up any new biome for quite a while. For flying high, you have to be in an atmosphere, so you cannot have a stable orbit. The key here is to just barely be in the atmosphere, with both your periapsis and apoapsis just below the edge of the atmosphere. Your orbit will slowly decay, and you may have to thrust a little occasionally to prevent it from decaying very far, but this will make thermal heating inconsequential, as well as making it safe for a kerbal to go on EVA. You can use 4x physics warp pretty safely in this situation to prevent it from taking a ridiculously long time, and may wish to just barely leave the atmosphere for some long time warps.

Sensors

There are nine different pieces of equipment to gather science data for you by doing discrete experiments. All of the sensors produce data that can be transmitted back to Kerbin, but with imperfect transmission efficiency. In order to get the full science data, you have to bring the data physically back to Kerbin, not just transmit it. Furthermore, for some of the experiments, even bringing the data back and landing on Kerbin doesn't get you the full value, and repeating this subsequent times will add some additional science.

Most science sensors are relatively fragile equipment. They won't break if you touch them, but most of them will explode at 1200 K. As such, it is often advisable to place them inside of a service bay for protection, though you cannot do that with the SENTINEL Infrared Telescope or the Magnetometer Boom. The SC-9001 Science Jr. also has a crash tolerance of only 6 m/s, making it one of the most fragile items in the game. It can readily be placed at the center of a Service Bay (2.5m).

The Mystery Goo™ Containment Unit and science jr. can be used in any situation. They provide separate data by biome when splashed or landed, but do not depend on the biome in other situations. These two experiments also have the issue that once their data is removed once (whether by transmission or transferring the data to be stored elsewhere), the equipment is left in an unusable state. It can be restored to be able to run another experiment by a scientist or by a mobile processing lab. If you are going to rely on a scientist to restore the equipment, then it is highly recommended that you place it very near the door of the command pod, with perhaps a ladder for access. Relying on the scientist to use a jetpack to fly around every time you want to restore the equipment is a major pain. Another approach is to bring multiple units that can run experiments in different locations without needing to restore any particular unit.

The 2HOT Thermometer and PresMat Barometer can also be used in any situation. In particular, you can check atmospheric pressure even while in a vacuum. Both have data that varies by biome while landed or splashed. Temperature data varies by biome while flying low, but pressure does not. When flying high or in space, data does not vary by biome.

The GRAVMAX Negative Gravioli Detector can be used while landed, splashed or in space, but not while flying. Its results always vary by biome. A gravity scan is the only thing that varies by biome while high in space, so it is the one that forces you to hit every biome while high in space if you want to get all of the science data.

A Double-C Seismic Accelerometer can only be used while landed, and its results vary by biome. As such, there is no need to bring the seismic accelerometer for satellites that will never land.

The Atmospheric Fluid Spectro-Variometer can only be used while in an atmosphere. It can be used while landed, flying low, or flying high, but not while splashed or in space. It also cannot be done at all on planets that have no atmosphere, even while landed. As such, there is no need to bring it on missions that will only visit a planet or moon with no atmosphere. Its results always vary by biome, and it is the only thing that varies by biome while flying high.

The telescope and magnetometer can only be used while in space, and not while landed or in an atmosphere. Their results never vary by biome. The telescope can only be used while high in space, though the magnetometer can be used whether high or low in space. As such, the telescope and magnetometer can only return one or two experiment results per planet or moon. While the other science sensors can be radially attached just about anywhere, these need a mounting node to attach to.

Manned reports

There are five types of reports that can be made by a kerbal, without requiring any special scientific equipment. A kerbal can do a crew report from inside of a command pod. This is done by interacting with the command pod itself. A kerbal can also do an EVA report while outside. The crew report and EVA report can be done in any situation. Both vary by biome while landed, splashed, or flying low. The EVA report also varies by biome while in space low. Otherwise, they do not vary by biome.

A kerbal can also collect a surface sample if landed or splashed, but not while flying or in space. The kerbal does not actually have to be on the surface to collect a surface sample. Rather, you can land your ship, go on EVA, collect a surface sample while holding on to the door, and then go back inside. A surface sample always varies by biome.

The final two types of manned reports are the asteroid sample and the comet sample. This requires being near an asteroid or comet, but can otherwise be done in any situation. Asteroid sample data varies by biome if splashed, landed, or flying low, but not otherwise. Asteroid sample data also varies by asteroid, so you can get separate data from testing different asteroids in the same biome and situation. This makes it possible to get effectively infinite science by repeating everything on different asteroids. Actually doing this is quite repetitive and boring, however, so I actually recommend ignoring asteroids entirely.

Rover scanner arms

Every planet and moon that you can land on has some surface features. It varies from one to four types by planet. In order to find them, it is very helpful to turn off surface scatters in the game's graphical options. Once the surface scatters are gone, odd looking things laying around will tend to be be valid surface features.

Some surface features are small enough that a kerbal can pick them up and return them to the vehicle. Otherwise, you'll need a scanner arm to pick them up. There are three different scanner arms in the game, but the smaller arms can only get some of the science, while the OP-E Large Scanning Arm can get all of the science for a feature in a single scan. As such, the smaller arms are pretty useless. The small features that can be picked up by a kerbal will give you the same data if you either have the kerbal pick it up or scan it with a large scanner arm, so it is unnecessary to do both. On Ike and Pol, there is only one type of surface feature, and it can be picked up by a kerbal, making a scanner arm unnecessary for a manned expedition.

In order to use a scanner arm, you must be very close to the surface feature, with the base of the scanner arm within a few meters of the feature. It is difficult to land this close, other than perhaps on Gilly, so it is much easier to use a rover on wheels. The idea is that the rover can land kind of close to a feature, then drive to park right next to the object and scan it.

Surface feature data can be transmitted with 100% efficiency. As such, there is no need to bring it back to Kerbin. Depending on your goals, it may be sensible to drop an unmanned rover to scan surface features and transmit the data without the rover needing a way to leave the surface.

Deployed science

The final category of science equipment is deployed science. The idea is that rather than doing an experiment once, you set up equipment to run the experiment continuously over the course of months. The equipment should be placed on the ground, but can do separate science experiments for different bodies. There are several different pieces of equipment, and you generally want to set them all up together. A full deployment generally involves laying out seven pieces of equipment.

You always need a Probodobodyne Experiment Control Station near the rest of the equipment. That controls and monitors everything else. It also counts as a separate vehicle in flight that you can switch to, even while no other ship is remotely nearby.

The Go-ob ED Monitor, Ionographer PD-22, and PD-3 Weather Analyzer do the main experiments. You always want the Go-ob ED Monitor. The Weather Analyzer only works while in an atmosphere, while the Ionographer only works if not in an atmosphere, so you bring one or the other, depending on where you're going. These pieces of equipment basically just have you set them up once and then ignore them. They will generate science data faster if placed by a high level scientist.

The Grand Slam Passive Seismometer will monitor earthquakes caused by crashing vehicles into a moon. The amount of science generated is proportional to the kinetic energy when the object hits the surface, so it scales with mass times the square of your speed, at least up to the maximum amount of science that can be cumulatively gathered from it on a moon. The amount of science generated is also decreased by the distance from crash to the seismometer. It generally takes much larger crashes to get the maximum science on larger planets and moons.

The Communotron Ground HG-48 will transmit data back that the other experiments generate. It isn't strong enough to get a good connection from the outer planets all the way back to Kerbin, but it can use CommNet and go through relays. It is strong enough that for a first link, it should be able to get a good connection to any relay that it finds orbiting the same planet--or a different moon of the same planet.

Finally, you need power generators to run the rest of the equipment. There are two options here: the OX-Stat-PD Photovoltaic Panel or the Mini-NUK-PD Radioisotope Thermoelectric Generator. The only advantages to the former are that it is cheaper and available earlier in the tech tree. The advantages to the latter are that it works both day and night, and also still works on the more distant planets. Unless you want to do deployed science on or near Kerbin and don't yet have access to the nuclear generator, there is no good reason to use the former.

The amount of power generated depends on the level of the engineer that deploys it. For a level 2 or higher engineer, you will need two generators to power a full installation. For a level 0 or 1 engineer, it will take three generators. If placed by a scientist or pilot, it will take five generators. So basically, you want to bring an engineer with some experience.

Generating data for the seismometer is much easier if there is no atmosphere, as you can crash things into the surface at very high velocity. You can send an unmanned probe to the planet aimed to crash straight into it and not try to slow down to circularize an orbit, but just crash at several kilometers per second. Alternatively, you can sometimes have some vehicle that you want to keep shed a stage while aimed directly at the moon, then have the next stage slow down and circularize the orbit while the debris crashes at high velocity. In an atmosphere, it is much harder, as coming in at several kilometers per second will mean you burn up and don't cause any crash at all, and even coming in at lower speeds has you slowed down much further by air resistance.

Storing data

Any equipment that can run science experiments can store one experiment result, and only one. For example, a PresMat Barometer can store the results of exactly one atmospheric pressure scan. If you want to do another in a different situation or biome, you have to remove the first.

If you wish to rerun experiments in many different situations or biomes on a single mission, it helps to have another place to store the data. That is what the Experiment Storage Unit is for. It can store unlimited data, though it cannot have two copies of exactly the same data. For example, it cannot store two atmospheric pressure scans while landed at Mun's midlands. But it could have multiple atmospheric pressure scans in different situations or biomes, as well as all of the other types of experiments.

The Experiment Storage Unit is basically the indestructible black box for data that you've heard that airplanes use. While not truly indestructible, it is rated for a maximum temperature of 2900 K, which is higher than anything else in the game besides heat shields. It is also rated at an impact tolerance of 15 m/s, which is higher than most other equipment.

Probe cores with SAS level 3 also have the same data storage functionality as the experiment storage unit. That may make the latter superfluous, or you may still want some extra experiment storage to store several copies of the same data. You generally don't want to load up on extra probe cores as a way to store data, however, as they have more mass than the experiment storage unit, and are also more fragile.

Consuming data

For data other than generated by the deployed science, there are three basic things that you can do with it. One is to transmit the data, which uses it up, but gets you some science. Crew reports, EVA reports, and surface features can get you the full science value when transmitted, but everything else cannot. You can also run an experiment, transmit the results, and then rerun the experiment so that you have the data again and can return it to Kerbin.

The second thing to do with data is to physically return it all the way to Kerbin. You don't necessarily have to return all of the science equipment, but just the data. A small rocket intended to return an experiment storage unit loaded with data works for this.

The third thing that you can do with data is to process it in a Mobile Processing Lab MPL-LG-2. This allows you to convert data to science, then transmit the science. The science is then transmitted with perfect efficiency. A given experiment can both be converted to science in a lab and also returned to Kerbin, and you get the full science for both. It takes the mobile processing lab a long time to convert data to science, and you'll have to come back every seventy days or so to transmit the science and add more data.

Structural components

A lot of the components that you'll use have some dedicated function. You have fuel tanks, rocket engines, command pods, batteries, and so forth. If you try to build a rocket entirely out of such functional components, sometimes it just won't work. It will fall apart, or not have the shape you want. That is why there are structural components to hold your rocket together. They are commonly lighter and/or more durable than than functional components of similar sizes, but without having any function besides holding the ship together.

EAS-4 Strut Connector

The most important structural component is the EAS-4 Strut Connector, or more colloquially, struts. Large rockets inevitably need a lot of struts. If your rocket falls apart in space, it probably means that you should have added more struts.

One critical thing to understand about the game's physics model is that, apart from struts, anytime you add a new component, it is only attached to the rest of the rocket in exactly one place. If two things are laid against each other such that it looks like they have a long common surface, they are connected only by a single point and the rest of the common surface can flap freely. If you lay out four things in a square such that it looks like each of them is touching two others, the last one placed will only be connected to one of the two others, and one of the apparent connections won't actually physically hold in place.

Struts are the exception to this. You lay out your rocket however you want to, and then add a strut to force the components at its two ends to remain a fixed distance apart. Struts do add mass and drag, but they also make it possible to build rockets that are much larger and much sturdier than can be done without them.

It is also legal to strut together components that will be part of different stages. When you decouple the stages, the strut will automatically release. The mass of the strut will remain with the piece on which you placed the first end when laying out your struts. Thus, you want the first end of the strut to be the part that is discarded earlier.

Couplers and adapters

Sometimes you want to have different stages use different sizes of rockets, or otherwise connect two things of different radial sizes. Some fuel tanks are shaped appropriately for this, but sometimes, that just isn't what you want. You can just directly attach things of different sizes, but that can look ugly as well as being poor aerodynamically.

As such, the game has a variety of couplers and adapters to allow properly connecting things of different sizes. For example, if you want a small radial size on one end and a large radial size on the other, the Rockomax Brand Adapter will get the job done. Couplers can do this in a many to one manner. For example, a TVR-2160C Mk2 Stack Quad-Coupler can attach one small size object on one side and four on the other.

There are also two cubical nodes with a separate attachment point on each side. The Rockomax HubMax Multi-Point Connector does this for a small radial size (not the large that most Rockomax gear uses!), while The Not-Rockomax Micronode does this for a tiny radial size. I commonly find the former useful for attaching a bunch of relays to a large satellite that is intended to transmit data from the orbit of one planet to another.

Finally, there is the BZ-52 Radial Attachment Point. This basically allows you to create a proper node wherever you want. One end is radially attached, so it can be placed just about anywhere, and then you can attach whatever you want that cannot otherwise be attached radially.

Girders, I-beams, structural panels, and tubes

Sometimes the basic problem with your rocket layout is that you want this item here and that item there to be far apart, with nothing in between. That's what girders and I-beams are for. They are quite sturdy with relatively little mass and drag. There is no fuel crossfeed across an I-beam, but there is across a girder.

The game also has a variety of structural panels and tubes. Often, these are targeted more at airplane wings. But if you want a sheet of metal of a particular size in a particular place, you may be able to find it. Or you may have to attach several to each other to make what you want. I personally don't find them very useful.

Robotics

Most types of parts in the game have some canonical use. Rocket engines provide thrust, batteries store electric charge, science equipment runs experiments, and so forth. Robotics parts really don't have a canonical use. There are a lot of things that they can be used for, none of which you really need to do in order to play the game. But they do have a lot of creative uses.

My personal favorite use is for docking on the ground. Have a base with mining equipment on the ground, and a lander that explores the planet. Park the lander near the base, then use robotics to have the base move a docking port around to connect to the lander. That makes it possible to dock them together to transfer fuel without needing to make precise movements with either the entire base or the entire lander. And that makes it possible for the lander to refuel without needing to carry around mining equipment.

But more generally, you can use robotics for anything that needs to make small, precise movements that don't require that much force. The rotors and blades can also be used as an alternate propulsion system that doesn't burn rockets.

Hydraulic cylinders

The idea of a hydraulic cylinder is that it can extend and contract in one direction. Thus, the distance between two fixed parts can become shorter or longer when you need it to be. The telescoping cylinders can extend further than non-telescoping cylinders, but this comes at the expense of additional cost and mass.

Cylinders can provide only a limited amount of force, so you can't expect a single cylinder to lift your thousand ton rocket. But they can reposition smaller craft just fine, or even provide a way to jump without thrusting.

Hinges and servos

Hinges and servos provide a way to rotate. Hinges can rotate up to 180 degrees around a particular axis, while servos can go up to 360 degrees. They do not provide a way to rotate perpetually like a fan, but only to move from one angle to another. You could think of a these as adjusting an angle of the location of the end object for one of the angular coordinates in a cylindrical or spherical coordinate system.

Rotors and blades

Rotors exist to spin in one direction and keep spinning. This is very different from servos that might go 30 degrees in one direction, then decide to come back by 10 degrees. Rotors can't make such precise movements, but they can say, I'm going to rotate at three revolutions per second and keep doing that perpetually.

Rotors generally exist to make fan blades spin, and thus push against the air to provide some thrust. The blades can be helicopter blades or propeller blades. They can also be the newer fan blades which don't need as much space. It is also possible but not recommended to use arbitrary structural components as the blades.

Because rotors spin pretty hard in one direction, they provide a considerable torque. If not accounted for, this can make your entire vehicle spin out of control. One common way to handle this is to have paired rotors that spin in opposite directions.

If mounted vertically, rotors can lift your entire vehicle upward, as a helicopter. In the opposite direction, they can push you down toward the ground. Usually, this would be a design failure, but it could also submerge you if you want to land on the bottom of the ocean.

Rotors can also be mounted horizontally, as propellers to make a propeller plane. This will mean you have to struggle with all of the finicky aerodynamics of a jet plane, so I don't recommend it, but you could.

Rotors can also be mounted horizontally to provide some forward thrust to a vehicle that isn't meant to leave the ground. Staying on the ground will mean that the ground provides considerable torque to offset the rotors' attempt at flipping you over, at least if they don't provide all that much net torque. This can be useful to allow a rover to ascend steeper hills on Kerbin, Laythe, and Eve. It can also be useful to allow a boat to travel across the water. For such uses, you don't have to have the center of thrust exactly right, but it should be close to the center of mass in order to avoid flipping over.

Rovers

When landing from space, it isn't that hard to land within about 1 km of where you want to land, at least in a vacuum. But sometimes, you need to reach a much more precise location than that. To scan a surface feature, for example, the base of the arm must be within 4 m of the feature for the largest arm, or closer yet for smaller arms. It's not that hard to land with that sort of precision on Gilly, but good luck doing so on Tylo or Laythe. If you want to dock with a base, landing 1 km away, or even 100 m away, doesn't get it done.

Rather, when you need to reach a precise location, it's much easier to only need to land within 1 km or so, then drive the rest of the way to your location. That commonly makes it not particularly difficult to get to within a few meters of where you wanted to go. Extending a rover arm or robotics can then cover the rest of the gap. I refer to any vehicle that can drive around like that as a rover, and that's what this section is about.

While there are four types of rover wheels in the game, that doesn't mean they're all useful. The TR-2L Ruggedized Vehicular Wheel is the one you want for just about any purpose. Do yourself a favor and ignore the others.

Ascending slopes

As with vehicles based on lander legs, if you try to build a tall, narrow rover and then land it on a steep slope, you'll fall over. Rover wheels don't stick out as far as lander legs, so a rover is more prone to this than other vehicles. But that's easily fixed by making your rover short and wide.

The situation with rovers is considerably worse, however. If you land on a slope on lander legs, then unless the slope is steep enough to make you slide, you probably just sit there. If you land on wheels, you could easily start rolling down the slope. Brakes can supply some force to slow you down, and trying to roll in the opposite direction can provide more. But if you can't provide enough force to counteract gravity pulling you down the slope, you start rolling, and often gain speed as you go. Depending on the weight (not mass; the strength of gravity matters) of your vehicle and how many wheels you have, it could be easy to stick on a 40 degree slope, or you might be unable to stop yourself from rolling down a ten degree slope.

One way to stop yourself on a slope is to turn sideways. Wheels can only go forward or backward and not skid sideways, or at least not without a tremendous amount of force. You might be unable to stop yourself from going forward or backward due to a slope if you're pointed straight down it, but if you're pointed orthogonal to the slope so that forward or backward doesn't change your elevation, you can probably stop.

Often, however, you don't merely want to stay put. You could stay put on lander legs. You want to go somewhere, and sometimes, that somewhere is up a hill from where you are. The ratio of the weight of your vehicle to the amount of force that your wheels can provide (which is proportional to the number of wheels) determines the steepest slope for which your wheels can provide enough force to ascend. That commonly pushes rover designs toward having a lot of wheels but not very much mass, so that it is possible to roll uphill when you need to.

Or at least that's the case if all of your wheels are touching the ground. Wheels that are hovering in the air don't provide you with any thrust. It is very important when designing a rover to make sure that all of the wheels are at exactly the same height. Symmetry tools can sometimes help with this somewhat, but ultimately, you're going to have to eyeball it and get the wheels as precisely the same height as you can.

The steepest slope that a given rover can ascend on a given planet or moon is determined by the design of the rover, and can't be changed once you've landed, at least unless you have a way to drop additional weight. If you discover that you need to ascend a steeper slope than your rover can handle, you can often make it work by approaching the slope at an angle. For example, suppose that you want to ascend a 30 degree slope, but your rover doesn't provide enough force to handle more than 20 degrees. Instead of going straight up the slope, you could approach at a 60 degree angle away from the direction you actually want to go. That will reduce the slope to a 15 degree slope upward, with the slope mostly trying to tilt you sideways instead. Go off to one side for a while, then turn to to at a 60 degree angle away from the direction you wanted to go on the other side. That's kind of a pain, but it does work.

Managing electricity

Rover wheels use several electric charge per second per wheel. If you need to drive very far, that can easily run you out of electricity very quickly. That means that you'll need a considerable source of electricity generation. I find nuclear power preferable to solar panels, as solar panels only work during the day. When you're landed, the sun is going to be blocked half of the time, unlike how you can mostly see it while in space. You can frequently park and wait to recharge. I find it more convenient to have several PB-NUK Radioisotope Thermoelectric Generators and a large battery so that you don't have to stop and wait to recharge as often.

If you are going to have to stop and wait to recharge, then make sure you get to a stable place to stop, where the brakes alone can prevent you from moving. That can sometimes mean turning sideways on a hill so that gravity can't pull you down the hill.

Flipping over

It's very easy to make a rover flip over, then have parts break off when they hit the ground. Even if parts don't break, if your wheels are up in the air, you're not going to keep moving. You don't just have to be able to land on wheels without immediately tipping over. You'll likely end up driving to a steeper slope than the first place you land. Furthermore, the act of accelerating can also cause you to tip over even when you would have been stable if you stayed where you were.

The classic example of how this happens comes from people riding a bicycle. If you're going too fast and slam on the brakes, the force applied by the brakes can't be pointed directly at your center of mass. Rather, it's along the ground, where the wheels actually touch the ground. That's far below your center of mass, so it provides a considerable torque to try to flip you over the point where the front wheel touches the ground. Gravity provides a torque in the opposite direction, but if you're going fast enough and hit the brakes hard enough, the torque of braking can be larger than that of gravity, in which case, you go flying over the front of the bike and take quite a spill.

The classic fix for this is to have no brakes on the front wheel. Instead, only the rear wheel has brakes. If the braking torque starts to flip you over, then the rear wheel comes off the ground and applies no more braking force. That prevents the bicycle from flipping over. It also prevents the bike from stopping, so you could easily crash into whatever you were trying to avoid by hitting the brakes in the first place. And it doesn't necessarily work on a rover that, unlike a bicycle, sometimes needs to go backwards.

About the same effect can easily cause rovers to flip over. The reduced braking fix doesn't entirely work, though, as sometimes you hit the brakes because you really need to stop. Sometimes the implicit braking is caused by turning sideways so that the wheels can't continue rolling in the direction you're traveling, which is why turning at high speeds can often cause a rover to flip over.

Rover wheels have advanced tweakables to reduce your acceleration and help avoid flipping over. The effect of the brakes slider is pretty obvious. The traction control slider allows you to reduce the acceleration from your motor in low gravity. A higher numerical setting means weaker motors.

What is really going on here is that there are two main forces on you. Gravity pulls you down toward the center of the body you're driving on. Accelerating in one direction is equivalent to an additional gravitational force in the opposite direction. If you add the implicit force of gravity from your acceleration to the actual force of gravity, you get the direction of the net pull that may try to flip you over.

The next key is to determine the convex hull of where your wheels touch the ground. The convex hull of a set of points is the smallest convex set containing all of the points. That might seem abstract, but it's a very simple concept that you'll immediately understand if you see a picture, so look it up if you need to. If you start at the center of mass of your vehicle and go in the net direction that braking, driving, and gravity are pulling you, the key question is whether that line will go through the convex hull of where your wheels touch the ground. If it does, then you're stable. If not, then you have a net torque that will flip you over the edge of the convex hull nearest to that line.

There is also a third implicit force on you: the centripetal force of being on a rotating body. Centripetal forces are fake forces, but it's easier to think of it as a fixed force than to do all of the adjustments for proper orbital mechanics. This centripetal force is very weak, however, at about 1.3% of gravity at the equator of Eeloo or Gilly and much weaker yet everywhere else that you can land. I'll come back to this in a later section.

There are several points to be made here, to help you avoid flipping over. First is that gravity alone always makes you stable or else you wouldn't have been able to hold still. For that matter, gravity pulling you down a hill can easily make you stable even if you'd fall over by stopping, as accelerate going down the hill. It's trying to slow down that threatens to flip you over. Even so, the stronger gravity is, the higher the acceleration you can handle without flipping over. If you double the force of gravity, you can double your acceleration while keeping the net direction of the pull constant. Thus, flipping over is a far larger risk in light gravity environments such as Minmus, Bop, Pol, and especially Gilly.

Second is the fairly obvious point that steeper slopes tend to make you more likely to flip over. Slopes rotate the points where your wheels touch the ground, moving the force of gravity closer to the edge that you risk flipping over. You're also likely to be inclined to try to stop rolling downhill, thus accelerating in the opposite direction, which also helps you to flip over. Furthermore, slopes increase the vertical distance between your center of mass and the lowest wheels, which also makes you more likely to flip.

A third critical point is that it helps tremendously for a rover to have a low center of mass and a large convex hull of the wheel base. If your center of mass is only 1 m off the ground, but 5 m away from all of your wheels, then it's pretty easy to remain stable while maneuvering on a 30 degree slope. If your center of mass is 5 m off the ground, and your wheels are all within 1 m of each other, it's not going to take much to send you tumbling. As with landers, the ideal rover is shaped roughly like a pancake with wheels attached.

Finally, even if you would flip over if a net torque stayed constant, it takes some time to flip over. Sometimes you can see that you're starting to flip and let go of the brakes to avert it. Small rovers flip much faster than large ones. Recall that if you scale a vehicle in all dimensions by a factor of n, the moment of inertia scales by a factor of n^5. Simply making a rover larger in all dimensions while keeping the same basic shape gives you more time to adjust if it starts to flip.

It's also important to consider the effects of reaction wheels. By default, the controls to rotate are the same as the controls to drive. That can mean that when you try to drive forward, your reaction wheels also start spinning, and reaction wheels alone can try to flip you over. This can mostly be avoided by setting your reaction wheels to SAS only. You may also want to turn SAS off entirely to avoid wasting electricity. This can also be fixed by changing the controls such that rotating reaction wheels uses different keys from driving a rover.

Rover size classes

As I see it, there are four basic size classes of rovers.

Small

When first building a rover, some people see that the Probodobodyne RoveMate is intended as the body of a rover and try to use it as the base. Attach some wheels, some electrical equipment, and whatever else you want, and away you go. That gives you a small rover that is easy to transport. You can cover it with fairings or whatever you need, and don't need a ton of struts.

The problem is that while it's easy to transfer a small rover to its destination, it's hard to do much with it. A small rover with a narrow wheel base is easy to flip over. It can be made to work, but it's more work than it is worth, which is why I recommend against small rovers.

Medium

The next step up is the medium rover, which has plenty of electrical equipment, several wheels, a wide wheel base, and likely a command pod. It may also have scientific equipment, beyond the standard rover arm. A medium rover is likely to have I-beams or girders to push the wheels further apart. It may also be large enough to need struts to hold together. To me, the defining step that makes a rover count as medium rather than small is that it's large enough that you can't try to hide it inside of a fairing. What the medium rover does not have, however, is rockets.

A medium rover is generally the best class for the large planets and moons: Kerbin, Laythe, Tylo, and Eve. The medium rover will need to be delivered somehow, but you likely have some rockets attached to deliver them, then stage to drop the rockets after you land. In an atmosphere, you'd also discard any parachutes that were used to help you land.

The idea of a medium rover is that it is large enough that it is easy to have a wide wheel base, a low center of mass, and plenty of wheels. Many wheels with light weight allows you to ascend slopes as necessary in heavier gravity. It's not particularly hard to build something that is basically unflippable at moderate gravity such as on Moho or Vall, and easy to avoid flipping even on the lighter moons such as Minmus and Pol.

A medium rover specifically avoids adding rocket engines and fuel for them so that it doesn't have to carry all that extra weight around. That makes it easier to keep a low center of mass and a high wheel force to weight ratio. The downside of this is that if you need to travel very far, it's going to take a very long time.

Lander on wheels

The next step up from a medium rover is to add rocket engines and fuel. At this point, you still don't want to add too much. In order to keep your center of mass low, it helps to use very short engines such as a terrier or spark. Radially attached engines such as a cub or twitch can also allow you to have your fuel tanks very near to the ground.

This class of rover is often constructed similarly to how you would build a lander, except that you use wheels instead of lander legs. For that matter, you might use the rover as a lander and have it jump from one biome to another picking up scientific data. The advantage to using wheels is that when you need to roll around to reach a particular spot, you can. A standard lander on legs can't do that. This can allow you to pick up surface features, or to dock with a base on the ground.

The lander on wheels is most useful in relatively light gravity. It's not very hard to make such a rover that won't flip. The added weight of rockets and fuel tanks makes it very difficult to ascend steep slopes in high gravity, but isn't such a problem in lighter gravity.

Base on wheels

The largest class of rover is basically a mobile base. In addition to rockets, you also add mining equipment so that you can refuel. You may also add a science lab, docking ports, or whatever else you might want in a base. You probably need a lot of struts to hold the base together.

The advantage of having a base on wheels is that you can refuel yourself and don't need a bunch of separate vehicles for different purposes. The disadvantage is that the high weight can make the rover awkward to position precisely. In heavy gravity, you may be unable to ascend even modest slopes. For that matter, strong enough gravity could cause your base to crush and destroy your wheels. Even in lighter gravity, it can be annoying to start rolling downhill and have to work to stop nearly every time that you land.

That said, the base on wheels approach is most viable for moderately light gravity such as on Ike, Dres, Mun, and Eeloo. Heavier gravity makes constantly rolling downhill awkward, while lighter gravity makes frequent refueling unnecessary.

A different use of the base on wheels approach is to have a base that stays roughly in the same spot, while moving to refuel nearby landers. Rather than putting a small lander on wheels, you can put the larger base on wheels so that the small lander can land more easily. While this may seem counterintuitive because the small lander can more easily maneuver regardless, the point of it is that the larger base doesn't need to move very far. Rather, you can pick a particularly flat place to land the base, and then when you want the lander to dock to the base, the lander only has to land near the base, and then the base can roll the last few hundred meters or whatever to dock. The idea is that the lander has to fly around and land far more often than the base, and likely also on much steeper slopes, so you optimize the lander to make it easier to handle, at the expense of the larger, lumbering base having to roll around, but only on relatively flat terrain.

Portions of a mission

Other than for missions that take place around Kerbin, many of the things that you'll want to launch a rocket for have three main stages. First, you get off the ground and into orbit around Kerbin. Then you transfer from orbit around Kerbin to orbit around somewhere else. And finally, you land on whatever other body is your target. The third stage of landing is optional, and for space stations or relays, you likely won't want to. Some missions involve taking off again after landing on some other body or docking with another vehicle, so we'll cover those, too.

When designing your ship, you generally construct it in the reverse order. You start by assembling whatever you want to have in low orbit about your destination. After that, you add one or more stages to get it from low orbit about Kerbin to low orbit about your destination. And then you add additional stages to get it from the launch pad into low orbit about Kerbin. How much fuel and rockets and so forth are needed in the early stages is largely driven by how large the payload is that you need to deliver.

Getting to orbit

Let's start by discussing getting your initial rocket into orbit. There are a lot of important considerations, and a lot of ways that this can go wrong.

Thrust to weight ratio

One important place to start is by looking at the thrust to weight ratio at each stage. If it's not above 1 for the first stage, you're not getting off the ground. Even if it is slightly above 1, you'll burn enormous amounts of fuel to barely move, which is inefficient. Thus, you need a thrust to weight ratio well above one, at least early on.

You don't want a thrust to weight ratio that is too high, however. If you get going too fast too soon, you can burn up before you even get out of Kerbin's atmosphere. While that takes a lot of work to do, it's a lot more common for moving too fast too soon to cause too much air resistance and flip your rocket over. You can reduce the thrust of liquid fuel engines, but then you're carrying weight for those engines that you're not using. It's fine to reduce your thrust somewhat for part of your ascent, but extreme cutbacks generally mean that you should have used lighter or fewer rockets.

Your thrust to weight ratio also changes as you ascend. Burning fuel reduces your weight, without changing your thrust, so your thrust to weight ratio increases as a stage burns. Different stages can have independent thrust to weight ratios, of course.

I typically like to have a first stage consist of a mix of solid fuel boosters and liquid fuel rockets. For huge spaceships, that would mean clydesdales and mammoths, respectively, though it will tend to mean smaller rockets for smaller ships. At the launch pad, I want a thrust to weight of somewhat under two, and then as the first stage burns, I can lower the throttle on the liquid fuel rockets to keep the thrust to weight ratio around two. Once the atmosphere is thin enough to not be much of a concern, open up the throttle to go as fast as you can.

Technically, your thrust to weight ratio ought to increase as you ascend because gravity gets weaker. For example, at an altitude of 100 km, Kerbin's gravity only applies about 73% of the that it does at sea level, so your weight should be about 73% of what it would be for the same craft at sea level. The in-game computations do not compensate for this, but compute a thrust to weight ratio that assumes that you are at sea level.

For the upper stages of your ascent, it can be acceptable to have a lower thrust to weight ratio, sometimes even of less than one. Once you're already ascending pretty fast, you don't need to continue ascending ever faster. Rather, you want to increase your horizontal velocity enough to reach orbit, and before you stop ascending. Sometimes you'll have a few minutes from the time that your apoapsis is about where you want it until the time that you fall back into the atmosphere, and then a thrust to weight ratio of somewhat less than one may still be enough to stabilize your orbit.

Staging

You'll likely have to stage two or three times during your ascent. Especially if your first stage has a mix of liquid and solid fuel rockets, they generally won't run out of fuel at the same time, and you want to drop whichever one is done to reduce weight while the other continues to burn. While it is possible to reach orbit without staging, this is generally indicative of inefficient design unless you're specifically trying to avoid staging, such as for a rocket that needs to land on Kerbin, refuel, and take off again.

When you drop a stage, its throttle remains in whatever position it was when you ejected it. Recall that you can't turn off solid fuel boosters once they are ignited. Usually, this is handled by waiting until rockets are completely out of fuel to drop them. If you need to discard liquid fuel rockets early for some reason, it is typically best to turn them off, then stage, then turn rockets back on. Otherwise, the ejected rockets will continue to burn, and without being attached to your remaining vehicle to weigh them down, will likely shoot right past the rest of your ship. That risks a collision that blows up your ship.

Discarded rockets continuing to burn is hardly the only thing that risks post-staging collisions. Another is that you can discard rockets and fuel tanks, then collide with them, causing an explosion. For stages that basically drop off the bottom of your rocket, this isn't much of a concern. For stages that are attached radially, they can easily bump into the rest of your rocket rather than dropping off smoothly. This is mainly caused by drag, which will mostly push your rocket in the direction retrograde relative to the surface. If you're thrusting directly prograde, then this is parallel to your rocket, so there is usually no problem. If you're thrusting in some other direction that isn't terribly close to prograde (or retrograde, but that's dumb during ascent), that can easily make the discarded rockets slam into your rocket pretty hard.

It's critical to realize here that the key direction that you want to travel is prograde relative to the surface, not relative to orbit. The atmosphere gets dragged along with the surface, and your direction relative to orbit is irrelevant while you're in an atmosphere. The game will automatically switch your coordinates from being relative to the surface to relative to orbit at about 36 km of altitude above Kerbin. If you're using SAS to thrust prograde, that switch can easily cause you to no longer be going prograde relative to the surface, and then you slam into discarded rockets and blow up. The solution to this is to manually switch the coordinates to be relative to the surface, and don't discard any radial stages while just before the transition unless you switch SAS to stabilization mode. That's true of every planet with an atmosphere, not just Kerbin, though the exact altitude for the automatic reference frame change differs in other places.

Drag

We've already covered drag pretty in previous sections, but this is one of the main places that you have to deal with it. So long as you're pointed directly prograde, the drag largely balances out to provide minimal net torque, but it can be a much bigger problem if you try to point in some other direction. It's okay to point in another direction while moving slowly, and it's also okay once you reach the upper atmosphere where drag is minimal, but you may want to point directly prograde in between. If your rocket is flipping over during ascent, you may need to go slower so that there is less drag to flip you over. Alternatively, you may need more gimbal on your rockets to be able to provide enough torque to offset whatever drag is doing. You usually want rockets with significant gimbal in the early stages. It can work fine to have a mix of some rockets with gimbal and some without, but traveling through a lower atmosphere with no gimbal whatsoever puts you at considerable risk of flipping over.

Engine efficiency

All rocket engines lose efficiency at higher pressures. The game implements this as reduced thrust with the same fuel burn rate. But some lose a lot more thrust than others at a given pressure. You generally need your early stages to only use rockets that work well at high pressures. That includes most of the rockets in the game, but it pointedly excludes the ant, terrier, poodle, wolfhound, cheetah, and rhino engines that are really intended for upper stages. It also excludes the dawn and nerv engines that are really intended for deep space use.

That said, you hardly have to get out of the atmosphere before upper stage engines become appropriate. All rockets work well at sea level on Duna, for example, which has about the same pressure as 15 km of altitude on Kerbin. Dawn and nerv engines are usually a bad idea during ascent because of their low thrust to weight ratio, but the liquid fuel engines that are intended for upper stages will be fine to use by the time you reach 20 km of altitude, which likely makes them acceptable for any stages that aren't firing directly from the launch pad.

Engine efficiency concerns are also important when taking off from Eve and Laythe, though you can largely ignore them on Duna. You can even use purely nerv rockets as your only stage from Duna and it's fine. Eve has such high atmospheric pressure that near sea level, darts and vectors are pretty much the only engines that are reasonable to use.

There is also the issue of engine efficiency in terms of spatial efficiency. By spacial efficiency, I mean thrust per cross-sectional area. The problem is that you cannot stack rockets vertically and fire them all at the same time, as a higher one will be ejecting mass right at the lower one, likely causing it to explode. Very long rockets will tend to have a very high weight per cross-sectional area, which means that you need a lot of thrust per area. You can't always just make the first stage wider without falling off of the launch pad. When you really need an enormous amount of thrust per cross-sectional area, clydesdales are the best at it. Earlier in the tech tree, other solid fuel boosters such as kickbacks can be useful for the same reason, though you probably aren't trying to get a six thousand ton behemoth off the ground when still early in the tech tree.

If doing career mode, there is also the question of cost efficiency. This will often push you to use solid fuel boosters in your first stage. Solid fuel boosters offer far more thrust per dollar than any of the liquid fuel rockets. If not playing in career mode so that you don't have to buy parts, this isn't a consideration.

Gravity turn

It does work to thrust straight up into space, then once you're in space, turn horizontal to circularize your orbit. The problem is that it is inefficient. If you're thrusting upward at a 45 degree angle, that gets you the same effects as thrusting upward at a little over 70% of the force and also horizontally at over 70% of the force, and at the same time. It is similar in principle to how cutting across a corner allows you to get where you're going in less distance traveled.

That doesn't mean that you want to aim at a 45 degree angle at launch, however. That would get you going very fast through Kerbin's lower atmosphere, and the drag would waste copious amounts of fuel and likely flip you over. There is also the concern that you want to be pointing in a direction close to prograde much of the time, and if you try to just stay at a fixed angle, gravity will pull your prograde direction far away from that fixed angle. That is also likely to flip you over.

Rather, the efficient approach is called a gravity turn. You point directly up at launch, then soon afterwards, tilt a little off to the side. If you try to stay pointed in some fixed direction, gravity will pull your prograde direction below your chosen direction, so you just follow where gravity tries to take you. Often, you can spend much of your ascent with SAS holding your angle directly prograde. If you need to make adjustments, it is usually fine to move your angle a little off of prograde.

How soon to start your gravity turn and at how large of an angle depends tremendously on your thrust to weight ratio. It takes some practice to get the hang of it, but you don't have to get it perfect every time. Being off by a ways might mean that you wasted 50 or 100 m/s as compared to a perfect gravity turn, but that's not a big deal unless you're perilously tight on fuel.

Maneuvering in space

The next phase of most missions is to go from a low orbit of Kerbin to a low orbit of somewhere else. Let's talk about how to get there.

Rocket choices

The key difference that maneuvering in space makes is that you don't have to worry very much about how long it takes to burn. Thus, for the stages intended for deep space, you can have a very low thrust to weight ratio that only gives you something like 1 m/s of thrust, and that's often fine. That can often push you to use nerv atomic rockets due to their very high specific impulse. If nervs are not viable for some reason, then wolfhounds, rhinos, cheetahs, and poodles are the next most efficient liquid fuel rockets at very low thrust to weight ratios. Terriers can also fill in well if you need something smaller.

Because nerv rockets have a very poor thrust to weight ratio, they become inefficient if you need higher thrust to weight ratios, even in deep space. There is no reason to use them if you need over 7 m/s^2 of acceleration, and they become dubious somewhat before that. But they far outshine any other liquid fuel rockets if something below 3 m/s^2 of acceleration is acceptable.

Even so, you might not want to rely on a single nerv rocket to push your 1000 ton load. Real-life burns in deep space can easily take days or weeks, but you don't want to sit and wait that long. Remember that you can't do a normal time warp while accelerating, and physics warp can't go above 4x speed. An hour-long burn that takes 15 minutes at 4x physics warp isn't terribly exciting. I commonly pack enough rockets to keep my acceleration around 1 m/s in deep space.

When trying to do a gravity assist near some large planet, you don't necessarily have a lot of time near periapsis. This includes leaving Kerbin when you need to head off into deep space at high velocities. If you try to do a half-hour burn while you have an orbital period of 45 minutes, it's not going to work well. In some cases, that could cause you to dip into the atmosphere and burn up. You may need to get into a higher orbit with a longer period before your burn, and that means a less efficient gravity assist. Trying to avoid that can push you toward a higher thrust to weight ratio even in space.

Maneuver nodes

When taking off or landing, you don't have a lot of time to plan, but have to just go. When maneuvering in space, you do have a lot of time. Furthermore, without drag from an atmosphere, orbits are far more predictable. As such, you should use that time to plan exactly where you're going to go. Maneuver nodes are designed to help you with that.

Maneuver nodes allow you to plan that at a particular point, you will apply some particular amount of thrust in some particular direction, and then plot out where your path will go from there. You can change the conic patch limit in the game's settings to extend how far it will project your trajectory further out if you want. You can also place multiple maneuver nodes, and have the game plot what will happen if you use the first maneuver node exactly as planned, and then add a second one.

I generally recommend that you plot one maneuver node from orbit of Kerbin to reach the sphere of influence of Mun or Minmus if that is your destination. For any other destination, have one maneuver node to leave Kerbin orbit, and then a second and possibly third while orbiting the sun to reach the sphere of influence of your intended planet. That way, you make sure that you can get where you're going in a reasonable amount of fuel before you start your burn. Don't plan out exactly what you'll do after reaching some other planet's sphere of influence, even if your ultimate target is a particular moon, as your first burn just won't be precise enough for your plans near another planet to matter.

Even if you plan out two or three maneuver nodes ahead of time, after your first burn, you should delete the other nodes and recreate them. Your first burn won't be quite what you planned, and you'll need to adjust the later ones anyway if you want to get to where you're going. At the last maneuver node to put you on a trajectory to reach the sphere of influence of some particular planet, you likely want to fine-tune your trajectory such that you get very close to the planet, as this will save you quite a bit of delta-v when you reach the planet and try to get into your intended orbit. A few m/s of delta-v when in orbit about the sun can sometimes be the difference between a low periapsis about a planet and a high one when you reach its sphere of influence, and that can save you several hundred delta-v when trying to get into your intended orbit.

One coordinate at a time

When maneuvering in space, it is often best to adjust only one coordinate at a time, with a separate burn for each coordinate. This is almost never optimal in terms of minimizing the delta-v required to get where you're going, but it is much easier to understand, especially when you're new to the game.

For example, in order to rendezvous with an object in the same sphere of influence as you, you might first have a burn at either the ascending node or descending node to get your orbit into the same plane as your target. This actually fixes two coordinates, not one, as it makes the direction of your angular momentum match your target. Equivalently, it makes your inclination and longitude of ascending node match the target. Sometimes it can take two burns, as the first ends up off a little so that you're still off by 0.2 degrees, and then a second burn at the new ascending or descending node gets you much more precisely into the same plane. But once you're in the right plane, you only have to worry about four coordinates, not six.

When trying to travel from one planet to another, it is common to have one burn done at the starting planet to change your apoapsis or periapsis to be about right in order to hit the other planet. Then partway through, you have another burn at your ascending or descending node in order to change to be in the right plane. After that, you may need another small burn to fine-tune your velocity to make the intended encounter actually happen. But adjusting one coordinate at a time makes it easier to understand what is happening.

Encounters

An encounter is when you enter a sphere of influence. It is basically the reverse of leaving a sphere of influence. The game switches your velocity relative to the center of the previous sphere of influence to the new one. There are basically two stages of handling an encounter. First is the burn to cause the encounter. Second is that, upon entering a new sphere of influence, it is good to adjust your trajectory a little so that you end up going more precisely where you want to go.

The easy way to cause an encounter is to previously adjust coordinates so that you are on a roughly circular orbit, and your own orbit is in the same plane as that of the planet or moon that you wish to encounter. After that, you create a maneuver node with just enough prograde burn (if in a smaller orbit than the other body) or retrograde burn (if in a larger orbit) to make your new orbit tangent to the orbit of your target. Move the node around until you find the right time to make the burn such that your target will be at the place where the two orbits are tangent at the same time that you are. Then make the burn at the node you set up and you're on your way.

Larger targets and those in higher orbits tend to have larger spheres of influence, which makes it easier to set up an encounter. There aren't any that are genuinely hard to encounter, however. You just have to be more precise when trying to create an encounter with Moho or Gilly than some others. Jool and Tylo are easy enough to encounter that you're likely to do so by accident at various points.

Maximizing your delta-v

One reason why I like the energy and angular momentum based coordinate system is that it makes it more intuitively clear where you ought to thrust in order to minimize your use of delta-v. When changing your plane, you are changing the direction of your angular momentum without changing its magnitude, and without changing your kinetic energy. The amount of change in angular momentum to make is the same regardless of where you make it, but the amount of delta-v it takes to make that change is not.

Meanwhile, when you are trying to change your energy, you get the largest energy changes per unit of delta-v when you are traveling as fast as possible. That means doing your thrusts near a large planet or moon when possible. That this is more efficient is sometimes called the Oberth effect.

One of the most important things in order to be efficient is that when you approach another planet or moon in order to land on it or get into orbit, your own orbit is nearly tangent to that of the other body, and going in the same direction. For example, you might be traveling at about 19 km/s relative to the Sun as you approach Moho, while Moho itself is traveling at about 16 km/s. If you're going in nearly the same direction, you'll come in traveling at about 3000 m/s relative to orbit when you enter Moho's sphere of influence, and you'll need a retrograde burn of more than 2000 m/s to get into a stable orbit. That's quite a bit, but it is manageable.

If instead, you come in the direction opposite of that which Moho orbits the Sun, you'll enter its sphere of influence at about 35000 m/s relative to Moho. If you come in that fast, you're not going to be able to get into a stable orbit. For that matter, you'll zip right through its entire sphere of influence in under six minutes.

But while it is likely obvious that coming in the wrong direction won't work, coming at even a modest angle can also be a problem. If you come in at a 45 degree angle from Moho's orbit, you'll be traveling at about 13700 m/s relative to Moho. A 20 degree angle would mean you're at about 6800 m/s relative to Moho. 10 degrees would be about 4300 m/s. You don't need your angle to be exactly right, but you do need it to be close.

While trickier to set up, it is sometimes possible to combine burns. For an analogy, if you need to walk 4 miles to the east and 3 miles to the north, you could move in one direction at a time and walk seven miles in total. Or you could walk directly to your destination and walk 5 miles in total. Similarly, if you need to thrust 400 m/s prograde and 300 m/s normal, you could use 700 m/s of delta-v in total, or you could combine them into a single 500 m/s thrust at a direction between the two.

Or at least that's how it works if the two thrusts can happen at the same time. Often, they can't. For example, you might need to thrust prograde at periapsis and normal at the descending node, and those may be nowhere near each other. But sometimes, you can manipulate things such that the periapsis and descending node are almost exactly the same spot. Or sometimes they happen to be close enough that you can get away with, say, a 520 m/s burn at prograde that does the full prograde portion, and enough of the normal portion to only require a 50 m/s burn at the modified descending node later.

Sometimes it's not just what you do after launch that matters, but also the time that you choose to launch. For example, the ideal trip from Kerbin to Duna would be to have a thrust from low orbit at Kerbin that puts you into an elliptical orbit about the Sun with your periapsis at the Kerbin's orbital distance and the apoapsis at Duna's. And you'd like for Duna to just happen to be there when you arrive at your apoapsis. That's unlikely to happen by random chance if you just pick a random time to launch. However, you can largely make it happen by choosing the right time to launch. There are tools such as Alexmoon's launch window planner to help you find the right time to make coincidences like that happen.

Gravity assists

One particular approach to squeezing more acceleration out of your rocket is called a gravity assist. The idea is that if a particular planet or moon is not your target, but you fly by it on your way to your target, its gravity pulls on you for a while. So long as its gravity is pulling you in the direction that you wanted to go anyway, it provides some free acceleration without using up any fuel.

The idea is that you use a gravity assist to pull you into a higher or lower orbit without changing your plane very much. If you want to get to a higher orbit, you pass by an object going behind it so that it pulls you forward and speeds you up. If you want to get to a lower orbit, you pass by the object going in front of it so that it slows you down.

The easiest way to demonstrate this in-game is to do a gravity assist using Mun. Get into a low, circular orbit about Kerbin with an inclination near zero. Create a maneuver node that would put your apoapsis somewhat higher than Mun's orbit, but much lower than that of Minmus. Try moving the node around. If you line it up so that you pass behind Mun, you can probably get a gravity assist that would take you out of Kerbin's sphere of influence entirely. Pass in front of Mun, and you can get into a lower orbit around Kerbin.

Gravity assists are a tremendously important way to save cost in real life. For example, the Parker Solar Probe is scheduled to do seven separate gravity assists off of Venus to bring its periapsis closer to the Sun. Getting the benefit of a few hundred delta-v here and there can add up to many millions of dollars in savings.

But they're a lot less useful in Kerbal Space Program. One problem is that they're very finicky and hard to set up properly. Being off by a small amount when you do one fly-by can mean that you're way off for the next. You can try to correct with additional burns, but that can eat up much of the benefit that you hoped for.

Another problem is that the bodies that you hope to use for a gravity assist usually won't be where you need them when you need them. If you're on Moho and want to use Eve for a gravity assist to get you to Jool, it can work great if you time it exactly right. But there will be various launch windows of how to reach Eve optimally, as well as various launch windows of how to reach Jool optimally, and they won't match. You could end up having to wait many years for them to line up properly to get a good gravity assist.

A third problem is that trying to line up a gravity assist later can often conflict with having a large thrust from a low orbit of Kerbin. Being unable to do that can easily waste more efficiency than you were hoping to gain from the gravity assist.

The easiest place in the game to get a gravity assist that both works properly and is useful is by using Jool's moons Laythe and Tylo. When you enter Jool's sphere of influence, a modest thrust of something like 100 m/s can often line up a gravity assist using either Laythe or Tylo that changes your orbit from a simple fly-by of Jool that will leave the sphere of influence at 2000 m/s to a stable orbit that is lower than Bop's. You can also have a gravity assist to go in the opposite direction when you leave the Jool system. Gravity assists are possible elsewhere in the game, but far more difficult to get any real benefit from them.

Landing

Landing on a planet or moon can be very different depending on whether the planet has an atmosphere or not. As such, we'll consider the cases of landing in an atmosphere and landing in a vacuum independently.

Atmospheric landing

Landing in an atmosphere brings concerns that drag from the air could flip you over, or that it could cause you to overheat and explode. The former can mostly be managed by pointing retrograde relative to the surface, at least assuming that you have enough reaction wheels to keep your vehicle pointed in the intended direction. But those concerns have been dealt with in previous sections.

Once you've slowed down enough that you're not going to explode, the main effect of an atmosphere is that drag slows you down. That can be troublesome if trying to land in a very specific spot, but for the most part, it's helpful, as it means that you don't need an extended rocket burn to slow down. Using drag to slow you down and lower your orbit or take you out of orbit entirely is called aerobraking. For the last stages of landing, you can use parachutes to slow you down far enough to actually touch the ground and live.

Aerobraking

When approaching an atmosphere at high velocities from a high orbit or even a fly-by of the planet, you usually don't want to point straight at the planet. That won't give you enough time for drag with the air to slow you down. Entering a thicker portion of the atmosphere while still traveling at very high velocities can cause you to overheat and explode. Even if you're traveling slowly enough to not explode, having less time to slow down can mean that you're traveling so fast that your parachutes can't safely open before you crash into the ground.

Rather, it's usually better to set your trajectory such that your periapsis is well within the atmosphere, but also well above the ground. On Kerbin, a periapsis of around 30 km often works well. That way, you'll travel a very long distance at an altitude of about 30 km, which gives the relatively thin air a lot of time to slow you down. If you set your periapsis too high, you won't slow down very much before you zip back off into space. When done properly, aerobraking will slow you down enough for your apoapsis to enter the planet's atmosphere, and from there, it's just a matter of time before you touch the ground.

It is also possible but usually inadvisable to use aerobraking to drop from a higher orbit to a lower one without actually landing on the planet. To do this, you set your target periapsis higher, such that you'll have enough drag to slow you down a lot, but not actually enough to bring your apoapsis into the atmosphere. This gets you all of the risks of overheating or flipping over, but without actually stopping and landing. Other than on Duna, it tends to be done from high enough velocities for burning up to be a major concern. And even if it works, it doesn't leave you in a stable orbit, but rather, will require another burn to get your periapsis out of the atmosphere.

Parachutes

When using parachutes, the first question to ask is, what is the goal of your use of parachutes? Are you trying to slow down enough that you can activate the parachute stage, step away, and have the landing finish on its own? Or are you only trying to slow down quite a bit, perhaps to something like 20 m/s, and then fire rockets at the very end to slow down enough to land safely? The former will commonly require a lot more parachutes than the latter. Slowing down to a given velocity will also require a lot more parachutes on Duna than on the other planets with an atmosphere, and fewer on Eve.

If you're relying on rocket thrusts to finish a landing after parachutes slow you to perhaps 20 m/s, then you'd better have rockets available that can provide that thrust. Discarding your final rockets as part of staging your parachutes obviously won't allow this. If all you have left is upper stage rockets intended for flying in deep space, they may not produce enough thrust to slow you down very much near sea level on Kerbin or especially Eve.

How many parachutes you need also depends on where on a given planet you need to be able to land safely. The atmosphere is far thinner at the top of a high mountain than it is at sea level. If you're relying on parachutes only to slow you to something like 20 m/s, and the thin atmosphere means that you're still going 30 m/s instead, you merely have to fire your rockets a little longer. But if you're relying on not needing to fire rockets at landing, you'll need to either have enough parachutes to slow down adequately atop a high mountain or else be able to aim your craft well enough to be guaranteed that you're not going to hit a high mountain. On Kerbin, Eve, and Laythe, this is easy to do provided that you don't care which biome you land in: aim for the middle of the ocean, and if you miss by 50 km, you still land in the ocean, which has the advantages of being at sea level and completely flat.

How slow you need to be going in order to land safely depends considerably on the design of your vehicle, and also where you land. The limiting factor is commonly the 6 m/s impact tolerance of fuel tanks. But fuel tanks usually don't directly touch the ground. That said, if sturdy but rigid rocket engines directly touch the ground, they can transmit that force straight through and blow up the fuel tanks to which they're attached. If lander legs or rover wheels are the only thing that touches the ground, that gives you a lot more impact tolerance and can often make it safe to touch down at 12 m/s--and least on flat ground. On a steep slope, if only a small fraction of your lander legs or wheels touch the ground at first, having to cushion the blow of your entire rocket can cause them to blow up, which then allows whatever they were trying to keep off of the ground to hit hard and also blow up. Furthermore, in a water landing, legs or wheels can't keep the rest of your ship off of the water, so they just sink into the water and then other parts higher up also hit the water, and may explode. Under 6 m/s is pretty much always safe unless you have a creatively awful design or land on an extremely steep slope.

If you're trying to land in a particular biome, it gets trickier. Parachute landings are also far more difficult to fine-tune than vacuum landings, as it's difficult to predict exactly how much drag will slow you down, which moves your trajectory away from what the game displays. When landing from orbit, you can sometimes fine-tune a parachute landing by saving then trying repeatedly. Try to use highly repeatable steps such as varying only the starting time of a retrograde burn, then have the retrograde burn use a fixed amount of delta-v every time and open your parachutes at exactly the same altitude every time. That way, it's easy to see if you started your burn too soon or too late from whether you went too far or not far enough and adjust accordingly.

Whether parachutes slow you down adequately really only depends on how fast you're going when you touch the ground, which depends on your vehicle, your parachutes, the planet's gravity, and how dense the atmosphere is there. Eve's atmosphere is very thick near the ground and tapers off slowly, so that at sea level, it has about three times the atmospheric density of Kerbin at sea level, and even at an altitude of 13 km, it is still denser than Kerbin's at sea level. Kerbin's atmosphere tapers off much more quickly, and at an altitude of 5 km, has only about half of the atmospheric density of sea level. While Laythe's atmosphere has 3/5 of the surface pressure of Kerbin's, because its atmosphere tapers off much more slowly, it's atmospheric density at sea level is only about 38% of Kerbin's, which makes parachutes less effective than you might guess. Laythe's atmosphere is actually slightly less dense at sea level than it is a kilometer or two above it, which is unrealistic. Duna's atmosphere also diminishes relatively slowly, but its atmospheric density at sea level is only about 5% of that of Kerbin, which makes parachutes less effective than the other planets with an atmosphere.

Vacuum landing

When landing in a vacuum, there is no aerobraking and parachutes will not open. As such, you have to burn retrograde in order to slow down and land. It is critical that you burn retrograde relative to the surface, not relative to orbit. The game will automatically switch your coordinates to be relative to the surface when you are near it, but if you need to start burning retrograde higher up, you may need to switch it manually. On some very slow rotating places like Moho or Pol, the difference barely matters. At the equator of Eeloo, it's a difference of about 68 m/s.

The ideal vacuum landing is to be on the proper trajectory to go where you want, then start burning retrograde at just the right time such that continuing to burn until you touch down slows you down enough to land gently, then kill the throttle as you touch the ground. It's nearly impossible to time that exactly right, however, as starting a second too soon can mean that you stop several hundred meters above the ground, while starting a second too late can slam you into the ground at 40 m/s and then you explode.

Realistically, what you do is to start your retrograde burn a little too early, then keep burning until it's clear that you started way too early. Kill the throttle for a while and wait until you're closer to the ground before starting again. Each round if this should result in you being much closer to the ground the next time you start a burn and moving at much slower speeds, so eventually, you're near the ground and moving slowly. The closer you can come to the ideal time to start the burn, the less delta-v you'll need, but if you start one burn a little too late, you crash and explode.

How slow you need to be going in order to touch down properly depends on where you're landing. The same rules of parts exploding if you land too hard apply to vacuum and atmospheric landings, and under 6 m/s is generally safe from that. But vacuum landings in light gravity have another complication: you could bounce rather than sticking. Lighter gravity makes this effect far worse than it would otherwise be. It's generally safe to land on Tylo at 10 m/s if you've got enough lander legs. Doing that on Gilly will bounce you high enough into space that it could easily be several minutes before you touch the ground again.

The way that you generally want to finish a vaccum landing is that you end up traveling almost exactly vertically relative to the surface while close to the ground and at about the speed that you want to touch down. You adjust your throttle to remain at that speed rather than accelerating up or down, then wait until you touch the ground. Turn off the throttle as you touch the ground. For example, if you're trying to land on Mun and touch down at 4 m/s, and you have about 6 m/s^2 of acceleration available at full throttle as compared to Mun's surface gravity of about 1.6 m/s^2, you set your throttle to about 27% in order to stay going about 4 m/s as you descend the final tens of meters. It often helps to use SAS to point directly retrograde, which will naturally turn you toward a directly vertical landing.

Slopes and vehicle stability

One major issue with landing is that you could land on a steep slope, then fall over. In some cases, falling over merely means that you can't take off again, but that's fine if you've landed on Kerbin and only need to recover the vessel. For larger vehicles, falling over can cause a secondary impact of the top of your rocket slamming into the ground hard enough to blow up. Depending on how well you roll, it can sometimes mean rolling down a hill until you gain enough velocity to blow up.

There are two ways to deal with this: don't land on slopes, or have a vehicle that can handle landing on slopes. Having a perfectly flat place to land is really only practical if you're either splashing down on Kerbin, Eve, or Laythe, landing on the polar ice shelves of Kerbin or Laythe, or landing on the flats on Minmus. Anywhere else, it's all about how steep of a slope your vehicle can handle. A very tall, thin rocket could fail catastrophically on a five degree slope, which can make landing it very difficult. A short, wide lander vehicle may be able to handle landing on a forty degree slope easily.

If your vehicle is on wheels and you land on a slope, it may try to roll down the slope. For a slope that is long enough and steep enough, this can accumulate enough velocity to risk blowing up if you hit a bump. To stop the vehicle, it helps to turn on the breaks and accelerate in the direction opposite what the slope will push you in. In some cases, you may need to turn, so that going either forward or backward isn't really up or down a hill, and instead, the slope is trying to push you to the side, in a direction that wheels cannot roll.

Still, no matter how short and wide you make your lander, it can still fail if it tries to land on a sufficiently steep cliff. Some cliffs in Kerbin's mountains biome are slopes of something like 80 degrees. Dres's canyons biome has comparably steep cliffs. Usually you'll want to avoid those biomes entirely unless you're specifically trying to land on them, and then be careful, with plenty of fuel available in case you need to do a considerable thrust to avoid hitting the side of a cliff.

Taking off again

Some missions don't end when you land. In some cases, you need to take off again, whether to return to Kerbin, to land somewhere else, or whatever else you might fancy. The second takeoff is substantially different from your original launch on Kerbin, for a variety of reasons. For one, you likely start on a slope, and possibly a steep one, in contrast to Kerbin's very level launch sites. Unless you're taking off from Kerbin, the gravity is very different from Kerbin. So is the atmospheric pressure and density, and you'll likely be in a vacuum. All of that changes the procedures for launching.

When launching in a vacuum, there is no concern for quickly getting up out of the lower atmosphere. If you're trying to hop a very short distance, it is optimal to thrust at about 45 degrees above the ground. For longer distances, the optimal thrust angle gets lower, and if you're trying to reach orbit, you'll sometimes want to almost immediately have an angle less than 20 degrees above the ground. It is obviously important to have a high enough angle that you don't almost immediately smack into a hill, so do look around before taking off. You also need some net upward force, so the product of your thrust to weight ratio with the sine of your angle with the ground needs to exceed 1.

When taking off from in an atmosphere, you also have to worry about drag both slowing you down and flipping you over. On Eve, you'd better get to directly vertical very quickly after launch or else you're going to flip over. As discussed elsewhere, you probably want to stay directly vertical on Eve until you reach about 40-45 km of altitude. On Kerbin or Laythe, you don't necessarily need to start out going straight up, but you likely want something more like an 80 or 85 degree angle even for a short hop where you only hope to land 100 km away. You also need to get pointed in the right direction and then thrust very close to prograde quickly or else you'll flip over. Since you're probably not starting on level ground unless splashed down, having either high gimbal engines on the first stage or else a lot of reaction wheels is very helpful. To leave Eve, it is nearly mandatory to have a vector engine on your first stage. Duna is somewhat more forgiving due to its much thinner atmosphere. But even there, you want to get out of the lower atmosphere quickly other than for extremely short hops, so you might want to take off at an angle of 60 or 70 degrees.

Another, much less obvious issue is the direction of which way to go when you finally do launch, as it's not what you might expect from looking at a flat map. The Kerbal Space Center is right at the equator, which effectively makes this issue moot. When you land elsewhere, however, it usually won't be right at the equator. And from any location not at the equator, a circular orbit that starts there will slant toward the equator. To take an extreme example, if you start at the north pole, whichever direction you try to travel, you're going to end up going south very quickly.

The way to handle this is to switch to map mode, then rotate the map such that your vehicle icon is directly over the small sphere for the center of the planet or moon you're on. The angle that you want to travel relative to the surface is the angle that it looks like you need to travel from that particular map view. Or at least it would be if the planet or moon weren't rotating, which it is. Still, that will give you a pretty good approximation in most places, off by only however much the planet or moon orbits while you're in your flight.

Docking

Sometimes, you don't want to land in a particular place, but instead, want to dock with a vehicle that is in space. This can commonly be to transfer kerbals, data, or fuel. In order to dock, you first get into the same sphere of influence as your target. You then try to rendezvous with your target in about the same way as you would cause an encounter with a moon: get into the same orbital plane, then make your orbit tangent to that of your target such that both vehicles arrive there at the same time.

Where docking diverges from creating an encounter is what happens when you get close. Your target will be massively smaller than Gilly. Rather than trying to hit your target exactly, you just try to get close at first. As you approach the rendezvous point, you aim your vehicle retrograde relative to the target. You watch as the other vehicle approaches, then burn retrograde until you are completely stopped relative to your target. Then you turn protarget and burn toward the target. Repeat as many times as necessary until you are close enough to be at risk of crashing into the other vehicle. For the protarget burns, you generally only want to go a few m/s. It helps to get over 1 m/s so that the game will allow SAS to point you retrograde automatically, but you don't want to go fast enough to cause an explosion in case of a collision.

Once you are close enough to dock, you want each vehicle to set the other as its target, and have SAS point protarget. Well, usually; I've occasionally put a docking port on the bottom of a vehicle, in which case, SAS had to point anti-target. Alternatively, you can select a docking port and choose control from here, which will definitely make it protarget. If using docking ports, you can also have each vehicle target specifically the other vehicle's docking port, not just the other vehicle.

Once you are close with both vehicles pointed protarget and effectively not moving relative to each other, you have one apply a modest thrust of something like 0.3 m/s, then wait for the collision. Assuming that they have ample reaction wheels, both vehicles will rotate as needed to line up perfectly and then they'll stick together when they hit. If they hit too hard, they might bounce off and not stick. Or if way too hard, they could explode on contact. It helps tremendously if you can thrust while pointed protarget, which requires the docking port to be on the top of at least one of your vehicles.

This assumes that both vehicles have SAS level 3 available, which allows automatically pointing protarget. If you don't, then you can try to point protarget yourself, but there will be some slight errors. If only one vehicle has SAS level 3, then you want to have that one automatically point protarget while you manually adjust the other. If neither does, then good luck. It's still very possible, but just harder. So long as you're moving slowly enough, you can handle the vehicles bouncing off each other a few times until you get it right.

Stageless colonization architectures

Even if you want to collect the science from all twelve of Moho's biomes, for example, you don't necessarily want to have to send twelve separate vehicles to do it. Rather, it's far more efficient to send one vehicle that can fly around from biome to biome and collect all of the science. However, from being landed on Moho in one biome, to take off and then land in another could easily cost you 2000 delta-v. To go from a low orbit of Moho to landing in each of the biomes and then getting back to a low orbit of Moho could easily cost you over 20000 delta-v. Doing that without refueling would take an enormous vehicle and be very awkward.

Rather, what's far preferable is to be able to send a single vehicle to a planet, and then have that vehicle be able to refuel so that it can land in all of the biomes and return to orbit without any further staging. The question is how to design your ships to make that possible. There are a number of possible architectures.

All-in-one rocket base with mining capabilities

Let's start the obvious architecture: build a huge base that has everything you want in it. Have all of the mining equipment, all of the science equipment, and whatever else you want to use all in a single base. This allows you to refuel after every single time that you move from one biome to another.

The problem with this approach is that it means that you're stuck having to move around a big, bulky base every step of the way. If you want to do deployed science, you may also have to put the whole thing on wheels so that you can roll over to a deployed science location. And then you also need to make sure that the wheels have enough force to go up whatever hills you need to ascend, which is awkward when you're carrying around a bunch of mining equipment and many tons of fuel.

That's not to say that this approach doesn't work. It works, but it's awkward. On Kerbin, Laythe, and Tylo, it's pretty much what you have to do if you want to hop around indefinitely. But on the smaller planets and moons, there are other options.

Ground base with a detachable lander

One alternative is to build a mining base that lands in one place, sets out its mining gear, and stays there. Meanwhile, you have a smaller lander that doesn't need to carry around mining equipment that goes to the various biomes to pick up the science. In order to refuel, the lander returns to the base to dock.

One advantage to this approach is that your lander can be much smaller and more agile if you don't have to carry around a bunch of mining equipment. If you want to put your lander on wheels, not needing mining equipment makes it much easier to keep your center of mass very low to the ground so that you don't flip over. This also allows the base to mine while the lander is away, so that you can dock, quickly refuel with accumulated fuel, and leave, rather than having to wait to mine ore.

One key requirement in order for this approach to work at all is that the lander has to be able to fly from the base to an arbitrary other point on the planet, land, and fly back to the base, and land at the base to dock again, all on a single load of fuel. Depending on the size and gravity of various planets on moons, this can range from trivial to impossible. This can be done on Moho, Duna, or Vall, but needing two hops for each biome and still barely having enough fuel is hard enough that it's probably a bad idea to try. It can readily be done on Mun or Eeloo, and is easy on any of the lighter moons.

The other key requirement is that you have to be able to dock. This requires not just having the proper docking ports, but also being able to line them up exactly right. In order to make this work, I generally put a docking port on top of the lander, and have another one dangling from a cylinder attached to the base. The combination of a servo and two cylinders makes it possible to have the base move its docking port to an arbitrary position. Put it directly above the lander's docking port, then lower it by extending a cylinder to make the connection. This still requires the lander to be on wheels so that it can roll up to the base, but having a docking port attached to robotics makes it good enough for the lander to get kind of close rather than needing to be in exactly the right spot.

One warning if you use a detachable lander is that you should always save your game immediately before docking and undocking. It's rather buggy, and occasionally docking or undocking causes vehicles to blow up. Additionally, never return to the space station while leaving the lander docked to the base. If you do, switching back to them will occasionally cause one or both of them to explode.

Orbital space station and detachable lander

Another alternative is to have a mining base and detachable lander, but put the base in orbit. That allows the lander to dock with the station while in space, without bumpy ground potentially causing trouble. Docking in space is commonly easier than on land.

One drawback of this approach is that a space station in orbit can't sit there mining all of the time. Rather, it has to have enough fuel to land, mine to refill, and then use some of that fuel to get back to orbit. Another drawback is that, in order to dock, the lander doesn't just need to land in a particular spot, but has to match a particular orbit, which can take a lot of fuel to adjust inclination from a bad starting point. These issues aren't a very big deal on lighter moons like Minmus, but they can be a serious problem for heavier places like Duna or Moho. You can mostly avoid the inclination adjustment by waiting to launch until you're under the station's orbit, though that could mean waiting a very long time on bodies that rotate very slowly such as Moho or Pol.

Mining rocket base with orbital refueling station

Another alternative is to have a full mining rocket base that is nearly capable of being self-sufficient, but also having an orbital refueling station. This really only makes sense for the heavier planets and moons that are hard to land on, but there are several reasons why it could be useful.

One is that in some cases, it can be difficult to go from landed to in orbit and back to landing somewhere else on a single tank of fuel. This is especially the case on Tylo, and it's much easier if you can refuel while in orbit. Another is that while a vehicle can get from Kerbin or Laythe to orbit without staging, it isn't going to have very much fuel left, and if you want the vehicle to go elsewhere, you'll probably need to refuel. A third is that at the end of some long journeys, especially to Moho, you may have enough fuel left to get into a stable orbit rather than zipping by, but not enough to land. Refueling allows you to land without having to abort the mission.

The orbital refueling station doesn't have to mine the body it orbits to collect fuel. If doing this on Moho, you would, but in most other places, you would pick a different moon as the place to go refuel. Depending on which planetary system you're in, you would probably go to Gilly, Minmus, Ike, or Pol. That allows the refueling station to operate with a very low thrust to weight ratio, and thus have more fuel and more delta-v to get from the other moon to orbit, give away some fuel, and still be able to land back on the other moon. You probably want to use Nerv atomic rockets and liquid fuel for the refueling station, even if it is delivering something else to the vehicles that it exists to refuel.

Interplanetary travel

In addition to wanting to travel between biomes and situations on a single planet, sometimes you want to travel between planets. Many missions are to basically travel from Kerbin to some particular planet or moon and then stay there. In some cases, you may want a single mission to travel between several planets or moons. This is much easier if once you get into space, you don't need to do any more staging, but can refuel at each planet or moon where you stop.

In order to do this, you want for the last stage to rely on nerv atomic rockets and a lot of fuel, as well as having mining equipment to refuel. You can readily get to about 7000 m/s of delta-v with about 3 m/s of acceleration when full on fuel. The larger the payload you want to carry, the more fuel and rockets you'll need in order to reach those thresholds. That's enough to let you get into orbit from Moho or Vall when starting full on fuel. It won't let you get off the ground on Duna with full fuel, but you can leave Duna with half fuel, then land on Ike to refuel before leaving the Duna system. Such a vehicle will not be able to depart Kerbin, Eve, Laythe, or Tylo, but it can land anywhere else that you can land and then get from there to any other planet or moon. It can also get to an orbit about the places that you can't land and rendezvous with another lander.

For the structure of such a vehicle, my preferred approach is to have girders connecting a central section to mk 3 liquid fuel fuselages of some length, and use BZ-52 Radial Attachment Points to attach the nerv rockets to the girders. That's not a very aerodynamic design, but it does work to get the rockets up into the air so that they don't touch the ground, and without having something under them that they blast and blow up. As Duna is the only place with an atmosphere that the vehicle can land at all, it doesn't need to be very aerodynamic.

Locations to visit

There are many locations in the game to visit and acquire science. We list them in this section, though the smaller, easier ones are grouped together.

If you want to acquire all of the science in the game, at least apart from the infinitely replenishable asteroids and comets, the game has three ultimate challenges that I'll focus on more extensively:

1) Eve's surface 2) Jool's lower atmosphere 3) Landed (not splashed) at Laythe's water-only biomes

Just how hard the three challenges are depends on exactly what you want to do. Just getting a probe there isn't too hard. Doing so with a kerbal on board is harder, but necessary if you want a crew report, EVA report, or surface sample. But the real, full challenge is to send the kerbal, pick up the science, and then bring that it all home to Kerbin.

One measure of a moon's "size" is how much delta-v you need there. Let's suppose that you want to go from a low orbit to landing in every biome, and then return to a low orbit to dock with something. If used reasonably efficiently, the amount of delta-v needed is approximately:
Gilly: 100 m/s
Pol: 600 m/s
Bop: 1200 m/s
Minmus: 2000 m/s
Dres: 3000 m/s
Ike: 4000 m/s
Eeloo: 7000 m/s
Vall: 8000 m/s
Duna: 10000 m/s
Mun: 14000 m/s
Moho: 14000 m/s
Tylo: 20000 m/s

Obviously, some of those are far more doable without refueling (or without staging) than others. If used inefficiently, it could take you massively more delta-v than listed, however. I exclude Eve, Kerbin, and Laythe, as the oceans make it much less clear where all the places you want to land are, the heavy gravity makes jumping from one biome to another awkward, and you're probably going to use so many different vehicles that the cumulative delta-v isn't particularly meaningful.

Tiny: Minmus, Bop, Pol, and Gilly

The distinguishing feature of the tiny moons is that you don't need to refuel on them at all. It's pretty easy to go from orbit to landing on every biome and then get back to orbit without refueling at all. You can do that in about 2000 m/s of delta-v on Minmus, and much less than that on the others. Pretty much any of the architectures in the previous section can work fine, which makes it generally preferable to use a small, easily maneuverable lander. If you want to have a refueling capability at all, that can be a separate base.

On Bop, Pol, and Gilly, you can pick up all of the biomes except poles in a relatively small area just by picking a high point, a low point, and traveling from one to the other while stopping at every biome along the way. That doesn't work on Minmus because there are several flats biomes and the slopes biome is irregular.

The tiny moons all have irregular topology with some steep slopes. The steepest that I've directly measured while landed is 47 degrees on Minmus. That can be quite a nasty surprise if you brought a tall, narrow lander and then struggle to find a place where you can land without falling over. But it's easily handled by bringing a short, wide lander, and then touching down softly enough that the torque from one side hitting the ground before the other doesn't flip you over.

You may also wish to use Minmus, Gilly, and Pol as places to mine ore and refuel elsewhere in the same planetary system as other places that are harder to land. This allows you to approach Kerbin, Eve, and Jool's other moons (especially Laythe and Tylo) with nearly full fuel, or to refuel before leaving the system.

Gilly has much lighter gravity than the other tiny moons, at only about 1/10 as strong as Pol. This is so light that it is easy to fall off rather than sticking on Gilly. It is also sometimes preferable to just ignore Gilly's gravity and rely on the docking in space approach to reach locations rather than orbital mechanics.

Small: Mun, Ike, Dres, and Eeloo

The common feature of the small moons and planets is that, while it's easy to land and take off again a few times between refueling, if you want to get all of the science, you're probably going to need to refuel. On Ike and Dres, it is possible to go from orbit to landing on every biome and then back to orbit on a single tank of fuel. But it's difficult enough that it's not a good idea to assume that you'll be able to. Even so, because you can readily do three or four hops before needing to refuel, the fixed land base with a small lander can work well.

The only non-trivial biome on Dres is the canyons. This is a series of east-west gashes visible from space near the planet's equator. The canyons are very deep with very steep side slopes, so you have to be careful to land on the bottom and not on the sides.

Eeloo has two complications. One is obvious: its extreme isolation. Solar panels barely do anything, so you'll want to rely on nuclear power and/or fuel cells instead. You also can't rely much on happening to connect to relays orbiting other bodies such as when you connect to a relay around one of Jool's moons while orbiting another, or connect all the way back to Kerbin while orbiting Moho. You'll probably want to handle this by having several relays orbiting Eeloo, at least one of which is powerful enough to connect directly back to Kerbin.

The other complication is Eeloo's very high rotational speed. Of all of the places that you can land, Eeloo has the shortest rotational period, and the second highest ground velocity behind Kerbin. The other places with a relatively high rotational speed tend to be larger planets or moons that have an atmosphere, so you're moving very fast relative to the planet until you open your parachutes and then aren't moving very fast relative to the surface, which reduces the error of using your orbit to project where you'll land. Eeloo's rotational speed is nearly three times that of Dres, which is the second fastest to not have an atmosphere. This means you commonly have to aim well to the east of where you actually want to land, much more so than on other planets or moons.

Medium: Moho, Duna, and Vall

The medium planets and moons are large enough that it's easy to fly from one arbitrary place on the planet to another on a single tank of fuel, but much more difficult to do two such arbitrary hops. That makes the model of having a small, light lander that returns to a fixed base to refuel awkward to use. Rather, it is better to have a larger base with everything you need that can refuel itself. You don't necessarily need to refuel at every stop, especially for short hops across the border between two nearby biomes. But it is important to have the capability to refuel when you need to.

Alternatively, the medium planets are large enough that you may wish not to rely on refueling at all, but bring several landers with multiple stages and discard one when it runs out of fuel. That can also work.

All three of the medium bodies make their biomes mostly visible from space. This makes it easy to find exactly where you are on a biomes map. The midlands and highlands biomes are backwards on Vall, but it's still very visible that the higher altitude "midlands" and mountains are white and the lower altitude everything else is blue, at least outside of the polar areas.

Duna has a thin atmosphere, while the others have no atmosphere at all. This makes it much harder to take off from Duna, as apart from very short hops, you'll want to get much higher than you would without an atmosphere, and possibly outside of Duna's 50 km atmosphere entirely. It does make landing use much less fuel, however, as you can rely on parachutes and aerobraking. The atmosphere is so thin that you may not want to rely purely on parachutes to land you, but even having parachutes slow you to 20 m/s before firing up rockets to finish the landing can save several hundred m/s of thrust. The other caution about using parachutes on Duna is that if you're going fast enough, the parachutes may not open at all before you crash into the planet. When trying to land from orbit, you'll probably need to burn retrograde quite a bit to get under about 480 m/s. I recommend that you tweak parachute settings to partially open at the lowest pressure available (which on Duna, is about 13 km) and fully open at higher altitude than you would on the other planets with an atmosphere.

With Moho, the big difficulty is getting there at all, or getting back to some other body when leaving. One problem is that Moho is so close to the sun that, even when you enter its sphere of influence, you're likely to be moving at several thousand m/s relative to Moho, and it requires a lot of delta-v to get into a proper orbit. And then you still need to have about 1000 m/s left to land from a low orbit. Another issue is that, at seven degrees, Moho has the largest inclination of any planet. The closer you are to the sun when you make that adjustment, the more delta-v it will take, and it can take a few thousand m/s just for the plane change if you're about as close to the sun as Moho. My preferred way to approach Moho is to wait until Kerbin is roughly at the ascending node (or descending node) to take off, and take off in a northeast or southeast direction from Kerbin, rather than directly east. From a relatively low orbit of Kerbin, do a single burn to leave Kerbin's sphere of influence at a few thousand m/s in such a manner as to put your orbit in Moho's plane with your periapsis on Moho's orbit. It's not practical to get it exactly right, but if you're off by 0.2 degrees on the inclination, fixing that with a later burn is massively cheaper than trying to fix being off by seven degrees.

Kerbin

Among the planets that you can land on Kerbin has the second highest surface gravity, tied for the second largest size, and the second densest atmosphere. So Kerbin could easily be the second hardest place to maneuver. Of course, the easiest way to get somewhere is to start there, and you start on Kerbin. That makes recovering science from Kerbin very different from anywhere else in the game.

You can recover the science from Kerbin by launching a small rocket to land there, pick up science, and recover the vessel. It takes a lot of them to land in every biome, of course. Kerbin has oceans, so you can also recover science for splashed separately from landed. It is possible to splash down in six different biomes. For the water and shores biomes, this is obvious. You can also splash down in grasslands, badlands, deserts, and tundra by landing in a lake small enough that the game doesn't register it as shores. You can also be landed (not splashed) in the water biome. One way to do this is to make a craft that is dense enough to sink to the bottom of the ocean, which counts as landed. Another is to land at the very edge of one of the ice shelves, which counts as water, as the biome boundary doesn't quite match the physical ice boundary.

Kerbin also has a number of small, special biomes for which it is only possible to be landed. If you are just off the ground, it will count as flying above one of the normal biomes, not the special ones. At the Kerbal Space Center, there are biomes for Administration, Astronaut Complex, Crawlerway, LaunchPad, Mission Control, R&D, Runway, SPH, Tracking Station, and VAB. You can find the boundaries of each by seeing what lights up if you mouse over it from the menu, except that the Crawlerway is between the VAB and LaunchPad. There is also a KSC biome between some of the other mini-biomes. There are other biomes for Desert Launch Site, Dessert Airfield, Woomerang, and Island Airfield, and the easiest way to recover science from these is to enable alternate launch sites so that you can start there. And yes, the game seems conflicted as to whether the sites in the desert are "Desert" or "Dessert". The easiest way to pick up the science from surface features is to have a rover start at Woomerang and drive to them, as both of Kerbin's surface features are nearby. This wiki lists a number of other special biomes on Kerbin, but as far as I can tell, they don't exist anymore.

It is possible on Kerbin to build a base that can refuel, do all of the science, and still get to orbit without staging. Basically, you'll need some vector and/or dart engines and a whole lot of fuel. This can be handy if you want to get the Kerbin science into space for whatever reason. Processing science in a mobile processing lab that is landed on Kerbin reduces the value of the data by 90% as compared to being in orbit.

Laythe

Laythe is the moon that is by far the most similar to Kerbin. Laythe is mostly covered in water, though there is a lot of land scattered about the planet. It is 5/6 of the radius of Kerbin and has 4/5 of the surface gravity, so it is easier to move around on Laythe than on Kerbin. Laythe's atmospheric pressure at sea level is only 3/5 that of Kerbin, but its atmosphere tapers off with altitude much less quickly than Kerbin's, leaving Laythe's atmosphere with a higher pressure than Kerbin's at an altitude of 11-46 km, and several times as dense for much of that stretch. This also makes it more difficult to pick up the science in flight high above Laythe, as its atmosphere gets dense much quicker as you enter the edge than other places with an atmosphere. Laythe's atmosphere only 100 m inside of its boundary has density comparable to Kerbin's atmosphere 13 km in or Eve's 20 km in. That said, your orbital velocity on Laythe will be lower, so burning up isn't a real concern at the edge of its atmosphere.

Laythe is the planet or moon with the most science available in the entire game. While it has only ten biomes, it has an atmosphere, so you can get flying low and flying high in each biome. It also allows you to splash down in nearly all of them. The science from being splashed down means that Laythe has more activity/biome/situation combinations than Mun with its 17 biomes, and only slightly fewer than Kerbin and Duna with 11 and 14, respectively, at least if you restrict the count to normal biomes rather than Kerbin's special ones like KSC. While it has somewhat fewer combinations than Eve, it has much higher science multipliers than any of those other planets or moons. And it has far more combinations than the atmosphereless Tylo and Eeloo with their high multipliers.

Laythe's ten biomes break down as four that are predominantly land, five that are predominantly water, and the shores biome that covers most of the boundary between land and water. Peaks and dunes are the only biomes where you can't splash down, and those are the two biomes for the interior of the land on Laythe. While the poles biome is mostly land (or ice) and the sagen sea biome is mostly water, the boundary between them doesn't quite match the boundary of the ice, so you can use that to splash down at poles or land at the sagen sea. The crater island biome is larger than the island itself, which allows you to splash down at it.

Thus, of Laythe's ten biomes, there are seven where it is easy to land (the four land biomes, shores, shallows and the Sagen Sea) and eight where it is easy to splash down (the five water biomes, shores, crater island, and poles). It is also possible to land at the other three water biomes, but that requires sinking to the bottom of the ocean, which is much more difficult to do.

There are two ways to sink: you can make a ship that is denser than water, or you can thrust downward into the water. The latter can readily be done by a helicopter-like structure that thrusts you downward. Relying on rockets to thrust downward works poorly, as the high pressure prevents rockets from functioning once you get very far below the surface. In order to sink under the water, you need your thrust to exceed the weight of the water that your vehicle displaces minus the actual weight of your vehicle.

The problem with trying to make a ship that is denser than water is that your ship is mostly made out of components that are much less dense. Command pods, probe cores, reaction wheels, service bays, and mining equipment are all much less dense than water and will tend to make you float. Full fuel tanks are slightly less dense than water, but the mass drops as the tank empties while the volume does not, so empty fuel tanks provide tremendous force to help you float. Engines are commonly denser than water. The easiest thing to add if you're just trying to add weight is full ore tanks, as those have about double the density of water. Adding a bunch of I-beams can work, too.

It's quite possible to make a reusable lander on Laythe that jumps around from one biome to another to pick up the science from all of the biomes that you can splash down in, as well as the ones where it is easy to land. You can't refuel while splashed down, but all of the biomes except Degrasse Sea are very near to land, so you can refuel on nearby land, have a short hop into the water to pick up the science while splashed down, and another short hop to return to land and refuel. If you do this, you'll want lots of parachutes so that you don't need to burn a large amount of fuel to touch down. You can also pick up the Degrasse Sea science by splashing down with nearly full fuel as the first place you visit when reaching Laythe from space, thus relying on previous stages to get you there.

Alternatively, you may want to consider making a separate vehicle for each biome where you want to splash down or land. You can use parachutes to land without using very much delta-v, but it's much easier to get back to orbit if you can stage. Still, it's easier to jump around on Laythe than on Tylo, at least if you're willing to revert to a save if you were aiming for land and accidentally end up in the water where you can't refuel. It's easy on Laythe to refuel on land, get to a stable orbit about Laythe, and then land on Laythe again without staging.

If you want that stageless lander to be able to sink to the bottom of Laythe's oceans for the remaining science, that is much, much harder to do. Even if you plan on picking up most of Laythe's science with a lander that jumps around, if you want to sink to the bottom of the oceans, it is much easier to do that with a separate, dedicated lander for each of the three biomes where it is necessary. And if you're going to build a vehicle to land at the bottom of an ocean, you might as well have it also pick up the science for being splashed down in that biome while you are sinking.

You may also want a separate rover to be able to pick up the surface features science, as it is difficult to land precisely in such heavy gravity. If you do build such a rover, beware that rover wheels have a much lower temperature threhold of 1200 K than many other parts, so you'll need to burn retrograde or completely shield them from the atmosphere as you descent to prevent the wheels from burning up. Furthermore, in Laythe's environment of heavy gravity and steep hills, many rover designs will be unable to go where you want to go. My solution to this is to make the rover itself the final stage of a vehicle that can shed all other engines and fuel tanks to drop weight after landing.

Reaching Laythe doesn't necessarily take very much delta-v. You'll first need to get into an encounter with Jool, which takes about 2000 delta-v from a low orbit of Kerbin. Once you're just inside of Jool's sphere of influence, do a relatively modest burn so that your projected orbit about Jool is roughly tangent to Laythe's and timed such that Laythe will be there at the same time that you are and going in the same direction. Laythe travels at a little over 3200 m/s relative to Jool, so if done properly, you can enter Laythe's sphere of influence while going somewhat over 5000 m/s relative to Jool, but only about 2000 m/s relative to Laythe. With a low periapsis, that will be about 3000 m/s relative to Laythe at periapsis. From there, you can burn several hundred delta-v to get into a suitable orbit, or even use aerobraking to land without a further burn, at least if you have a suitable heat shield.

Tylo

Of all of the places that you can land, Tylo just might be the most difficult. Its surface gravity of 7.85 m/s^2 is nearly three times that of Moho, the next strongest to lack an atmosphere. Its surface gravity is essentially the same as Jool and Laythe and less than Kerbin or Eve, but with no atmosphere, you can't rely on parachutes or even some modest aerobraking to save fuel on the landing. You're probably going to hit the ground pretty hard at some point, so it can help a lot to have enough lander legs for your vehicle to hit at 12 m/s or so without anything blowing up.

Tylo has nine biomes, and is one of the few places to have no polar biome. It has four large, named craters as biomes, with the other biomes scattered all over the planet. The mara biome is the large, black spots that are visible from space. The minor craters are also mostly visible from space, though without consulting KerbNet, it isn't always clear which craters are officially minor craters and which are just spots on the planet but not the minor craters biome.

It is probably possible to have a vehicle refuel on the ground, get to a stable orbit around Tylo, and then land without docking to refuel in space. But it's difficult to do so, and I haven't done it. If you want a reusable vehicle that jumps from one biome to another to pick up all of the science, it is much easier to do this with a vehicle only capable of making much shorter hops, such as 100 km at a time, as this requires far less fuel. A vehicle with high enough delta-v on a single stage to get to orbit and then land without refueling is going to have a low enough thrust to weight ratio to increase the amount of delta-v needed to get to orbit as compared to what you could do with a lighter vehicle. Expect to need something over 2400 m/s of delta-v to get to orbit with such a heavy vehicle, and then more than that to land safely from orbit.

Tylo's biomes are bunched together such that the four large craters come as two pairs that are near each other, and all other biomes are available near at least one of the large craters. As such, most of your hops going from one biome to another can be short. You can, of course, do a very long jump from one biome to another by splitting it into several shorter hops and refueling after each.

It is doable to have a reusable vehicle that jumps around on Tylo to pick up all of the science, then gets back to space. You'll need mining equipment to be able to refuel yourself after every stop, of course. Picking up the surface features with the same vehicle could be very difficult, however, as it is quite difficult to land precisely in Tylo's high gravity. If you rely on wheels to drive to surface features, adding massive amounts of weight for the wheels and batteries will make flying around much harder, or having few wheels will mean that you can't ascend even modest slopes with such a heavy vehicle. The Tylo light stones can be picked up by a kerbal, and you can easily find the other two surface features very near each other to pick them both up with a single rover that doesn't need to fly.

If you look only at thrust to weight ratio and specific impulse, then rhino engines are by far the best choice for a vehicle to hop around on Tylo. The problem is that they are huge, which is an issue for several reasons. First is discreteness: at 2000 kN per engine, just one rhino engine means you're going to need quite a large vehicle. Adding more than one makes your vehicle even larger. Second is landing difficulties. A rhino engine blows up if it hits the ground at above 7 m/s, which will probably happen on Tylo if you don't touch down exclusively on lander legs. The problem is that those lander legs are much, much shorter than the rhino engine. Third is if you want a Kerbal to get out and go anywhere, he's going to need ladders to return to his pod, as Tylo's gravity is much stronger than a jetpack thrust. These factors make designing a Tylo lander (or any other lander) around rhino engines awkward.

If you want to use engines that lander legs can reach past, then your best options are vectors, darts, and poodles. Darts would be the best of the three except for their lack of gimbal, which can be awkward when you're going to need a huge vehicle and trying to cut weight. Vectors are physically compact, but at 1000 kN per engine, do give you something of a discreteness issue in design. You can also use a mix of a single vector for its gimbal plus however many darts you want.

Because of the difficulty of jumping around on Tylo, it is reasonable to consider having smaller, single use vehicles, with one to aim for each biome. Or perhaps you want one vehicle to land in two or three nearby biomes before returning to orbit, which would allow you to get away with fewer landers. Staging allows you to have a much smaller vehicle get back to orbit with your science. There are reasonable choices to be made here, and Tylo is large enough that refueling and jumping around is much more difficult than on the smaller moons and planets.

It doesn't really take that much delta-v to reach orbit around Tylo if you do it properly. You'll first need to get into an encounter with Jool, which takes about 2000 delta-v from a low orbit of Kerbin. Once you're just inside of Jool's sphere of influence, do a relatively modest burn so that your projected orbit about Jool is roughly tangent to Tylo's and timed such that Tylo will be there at the same time that you are and going in the same direction. Tylo travels at a little over 2000 m/s relative to Jool, so if done properly, you can enter Tylo's sphere of influence while going over 3000 m/s relative to Jool, but only a little over 1000 m/s relative to Tylo. With a good approach angle, a burn of several hundred delta-v at periapsis can get you into a stable orbit that isn't unduly high. You'll still want to have about 3000 m/s of delta-v remaining to land on Tylo from a low orbit, however.

Eve

As the hardest place to land, Eve is one of the game's ultimate challenges. As compared to Kerbin, it has 4/3 the radius, 1.7 times the surface gravity, and 5 times the air pressure at sea level. It is readily possible to get to orbit in a single stage from anywhere else that you can land except for Eve, where it will necessarily take several stages, if you can do it at all. There are several ways that this makes Eve unique, some of which might not be obvious.

First, if you've ever turned on 4x physics warp while on the ground, you may have seen your vehicle spontaneously explode when it was previously stable, or at least careen around worryingly. The problem is that the game's physics computations aren't continuous, but done at discrete times, and if something is accelerating too fast, it can push parts too far into each other and then things explode. The implicit acceleration of Eve's surface gravity can do that even at 1x physics warp. You can partially correct for it by reducing the maximum physics time step in the main menu options (not available once in the game proper) from the default of 0.04 seconds to 0.03, but physics on Eve is still going to be wonky. And, of course, actually using physics warp when on or near Eve is just asking for your ship to spontaneously explode.

You might expect that helicopters would work well near Eve's surface due to its dense atmosphere. And while they should work well in theory, having a lot of small parts moving at high speeds near each other is a pretty good way to get Eve's wonky physics to cause things to explode. So while a helicopter might work how you hoped, it also might just explode the moment you touch the ground, if not sooner.

Second, Eve's high air pressure greatly restricts which engines will work near its surface. Most rocket engines normally have a specific impulse of around 300. At sea level on Eve, the highest specific impulse in the game is a dart engine at 230. Next highest is a vector or mammoth at 193. The only other engines in the game that can offer half the thrust that they do in a vacuum are the kodiak and mastodon, and even they barely offer half. As such, if you're trying to take off from Eve, there is no point in using any rocket engines other than a dart or vector while in its lower atmosphere. You can still use other engines once you get into Eve's upper atmosphere, with normal lower stage engines becoming sensible by an altitude of 15 km and all upper stage engines being fine to use by about 30 km. Remember that you still need a high thrust to weight ratio to get to orbit on Eve, so nerv engines are still not going to be useful, though small engines such as a twitch, cub, spark, or terrier could be useful for your final stages to get to orbit.

Third, parachutes work extremely well on Eve. On Duna and Laythe, there is some question as to how much you want to rely on parachutes as opposed to burning retrograde. On Eve, there is no question. You want to use parachutes. Furthermore, you want to use normal parachutes, not drogues. Drogue parachutes are normally used elsewhere to ensure that you slow down enough for normal parachutes to open before you hit the ground. Eve's atmosphere will take care of that for you on its own. Even at the highest peak on Eve, it has about 1.5 times the air pressure of Kerbin at sea level. So bring however many Mk2-R Radial-Mount Parachutes you think you need, but skip the drogue parachutes.

That said, you might want to open your parachutes later on Eve than you normally would. It can take a long time to fall through Eve's lower atmosphere, and parachutes make it take longer still. Furthermore, if you open parachutes too high when safe, falling further into Eve's thickening atmosphere can tear the parachutes off. If you wait until you are several km above the ground to open parachutes, you'll be going slowly enough to prevent that.

Fourth, burning up in Eve's atmosphere is a major concern. You can readily burn up in other atmospheres, though on Duna, hitting the ground before your parachutes open is a bigger concern than burning up. On Kerbin or Laythe, so long as you don't have any fragile parts with a temperature tolerance below 2000 K exposed, from a low orbit, you can burn retrograde just enough to get your periapsis into the mid-atmosphere, and then rely on aerobraking to put you on the ground without any real risk of burning up. If you try that on Eve, you'll go hurtling into the mid atmosphere at over 3000 m/s. If you're still even going 1500 m/s once you reach the thicker part of the atmosphere, that will cause parts with a 2000 K temperature threshold to burn up.

Realistically, to get from a low orbit around Eve to on the ground without heat shields, you're going to need about 2000 m/s of delta-v worth of retrograde burns. As you can readily get from a low orbit about Kerbin to a low orbit about Eve in only about 3000 m/s of delta-v, the retrograde burn approach is viable. While harder to design, if you can use heat shields to cover your entire lander vehicle without flipping over, that can save you about half of your launch weight, and thus a lot of funds in career mode.

Landing on Eve by using a retrograde burn to slow down without heat shields isn't one of the deep space burns where you can take a long time. You start at about 3200 m/s from orbit, and Eve's gravity will try to speed you up as you drop, so you need enough thrust to provide considerable acceleration, such as 15 m/s^2. In order to keep your rocket engines from blowing up as you descend, you need to get your velocity relative to the surface below about 1500 m/s before you reach 50 km of altitude. Eve's atmosphere becomes denser very quickly as you descend between 50 km and 40 km, so that's probably where you'll explode if you're going to do so. Eve's atmosphere actually has a hole of sorts, in that at 36 km of altitude, it has only about half of the density of an altitude of 42 km. If you want to land with something more fragile exposed, such as rover wheels, you'll need to bring the velocity down considerably further yet via longer and stronger retrograde burns.

Fifth, the goal of a rocket taking off from Eve is only to get to a stable orbit around Eve. Trying to have that rocket get back to Kerbin is a huge waste. It is far better to get your small payload into a low, stable orbit, then have another vehicle that didn't need to burn all of that fuel to take off from Eve's surface pick up your kerbals and data.

Sixth, it is critically important to drop all possible weight before taking off. On Laythe or Duna, you may want to repack parachutes and to reuse them. If you try that on Eve, you're not getting to orbit. You want to stage something to disconnect any parachutes that were used to land before taking off. Do the same for your lander legs, too. Any science equipment other than a place to store the results should also be dropped. As usual, struts connecting different stages should always go from the earlier stage to the later one so that the entire strut is discarded when you stage the earlier one. Even equipment to generate and store electricity should mostly be dropped, as if you run out of electricity while in a stable orbit around Eve, that is a success. The payload for your final stage should consist only of parts to store data and/or carry kerbals.

Eve has thirteen biomes. Mining the game's files shows that there should be fifteen biomes, but two of them do not exist. There is a lake that counts as foothills, which is presumed to be intended as Akatsuki Lake. There are also several craters that count as impact ejecta, which are assumed to be intended as the craters biome. There is a mod to change these to what people think are their intended biomes. In the unmodded game, however, the Craters and Akatsuki Lake biomes do not exist, which leaves thirteen.

Of the thirteen biomes, seven are largely intended as land biomes and four as water. The shallows biome is largely for the boundary between them, and the poles biome is about latitude and does not care about elevation. The four water biomes include three large, named bodies of water: Crater Lake, Western Sea, and Eastern Sea. All other bodies of water are Explodium Sea. The shallows biome is largely the boundary between Explodium Sea and land. There are five elevation-based land biomes: lowlands, midlands, highlands, foothills, and peaks. The impact ejecta biome is for the perimeter of various craters, and in some cases, the entire craters themselves. The Olympus biome is by far the hardest to find, and consists only of two particularly tall mountain peaks that are right next to each other.

Because the boundaries of biomes are imprecise, it is possible to land in any of the water biomes, and without having to sink to the bottom of an ocean. It is likewise possible to splash down at lowlands and impact ejecta. It is even possible to splash down at foothills in the lake that is probably intended to be Akatsuki Lake.

Unlike every other planet in the game where you can land, it isn't really practical to have a reusable vehicle that jumps from biome to biome on Eve. In order to recover the science from being landed or splashed down at a particular biome, you're going to either land in that biome from space or else land nearby and drive a rover there. If you want to recover data back on Kerbin, a rover has no hope of getting back to space, so you'll need to transfer that data to another vehicle that can.

If you want to recover all of the science data from Eve, that likely means that you need to land in some very precise locations. Getting the data for splashed at lowlands or landed (not splashed) in the various lakes requires landing in one of various small, narrow strips. Trying to get that in a single attempt by eyeballing it doesn't have much hope of working. What can work is to get on the right line, so that if you start your retrograde burn from space at the right time, you'll land exactly where you need to. Make a maneuver node of a decent guess of where you should start the retrograde burn, then save your game. Start your retrograde burn at the node and see if you went too far or not far enough. Then reload your saved game and try starting your retrograde burn several seconds before or after the node. Don't move the node, as you can't do that precisely enough.

Don't actually burn in the direction of the node. You want to burn retrograde relative to the surface all the way down. The node is just to mark a particular spot in space, and you can cancel the node as soon as you start your burn. This allows you to say, oops, I started my burn too late. Let's start 5 seconds earlier and try again. Nope, that was too soon. Let's try starting the burn 3 seconds before the node and try again. And keep going until you find just the right time to land where you need to. This trick works elsewhere in the game, too, but everywhere else besides Eve, it's easier to just get kind of close, then do another short burn to get to the right spot.

If you want take off from Eve and reach space, you're going to need a long, narrow rocket to cut through Eve's very thick lower atmosphere. Long, narrow rockets are precisely the sort that tend to fall over when you try to land. You can build out wider scaffolding to help you land, then stage it as you take off. That scaffolding can include everything from lander legs to science equipment to parachutes. Basically, anything that you want to have around in order to help you land but want gone when you take off goes on the outside scaffolding. Remember to put your parachutes well above your center of mass or else they'll flip you over.

Long, narrow rockets are also prone to falling over when they splash down in the water. Lander legs can't help you stay upright in the water. What can is if you put floatation devices in your scaffolding, right at the water level. The idea is that when an item is underwater, the downward force due to gravity is essentially the weight of the object minus the weight of the water that it has displaced. For rocket parts that have large volume but low mass, that means a strong upward force. The game doesn't have dedicated floatation devices, but service bays and large reaction wheels can fill this role nicely. Empty tanks of rocket fuel can do so, as well.

The idea is that if your rocket starts to tilt one way, then your floatation devices on that side get submerged and those on the other get pulled out of the water. That means that you have a strong upward force on the side that you're tilting toward, and a much weaker one on the opposite side. That gives a strong net torque to force you back upright. Most reasonable designs on Kerbin or Laythe will have partially empty fuel tanks do this for you automatically. On Eve, you want to be able to stay upright even after you've discarded all empty fuel tanks, as you want all fuel tanks on your vehicle to be completely full when you take off.

If you were landed on Eve, then as soon as you take off, you need to get pointed directly up immediately. If you don't, then you're about to flip over. This shouldn't be a concern if you had splashed down in the water, as that should keep you pointed directly up. As you ascend, you have to be careful not to go too fast, lest your rocket become unstable and flip over. A long, narrow rocket with many parts chained together and no struts is very vulnerable to wobbling back and forth so that the rocket at the bottom isn't pointed directly at the center of mass. But you don't want to go too slow, as that would mean burning a lot of fuel to not get very far. Keeping your thrust to weight ratio between about 1.3 and 1.4 seems to work well.

I don't recommend even starting your gravity turn until you reach around 40-45 km of altitude. Until then, trying to turn by several degrees away from prograde will threaten to flip you over. You could start your gravity turn sooner if going slower, but that would mean that you wasted a lot of fuel by staying in Eve's lower atmosphere much longer than necessary, and that is worse than starting your gravity turn later. Eve's atmosphere tapers off rapidly between 40 and 50 km of altitude, so that by 50 km, you can point any which direction without any fear of flipping over. By the time you do reach 50 km, you'd like to have enough upward velocity to get you out of Eve's atmosphere entirely, and just need to add enough horizontal velocity to stay out before you come tumbling down.

If done efficiently, a rocket that would have under 8000 m/s of delta-v in a vacuum can go from splashed down at Eve to a stable orbit. It's nice to have a little more than that so that you don't cut it too close and barely fail. If used inefficiently, you might need a lot more delta-v than that. If you almost escape but come up a few hundred m/s short, you may be able to salvage a manned mission by having your kerbal get out of his pod, take the data from wherever it is stored, and use his EVA jetpack to provide that last few hundred m/s of delta-v.

If you want to land a rover on Eve to get the surface features, there are some complications. One is that rover wheels explode at 1200 K rather than 2000 K, which means you'll need a stronger retrograde burn to get them down to the surface. Another is that Eve's strong gravity means you'll need a very high wheel to mass ratio to do much. My own Eve rover with just over 0.5 tons per TR-2L wheel is able to go straight up slopes of up to 22 degrees, which is ample mobility for a planet as flat as Eve. While Eve does have some slopes in excess of 30 degrees near its mountain peaks proper (a small subset of the peaks biome), most of the planet is close to level, with a slope under 10 degrees.

But the real complication is trying to hold still in order to measure the surface feature. Eve's strong gravity will try very hard to make you slide around, and it doesn't take much of a twitch for the game to decide to cancel a scan because the vehicle moved. You can try tinkering with the advanced tweakables to try to get them to hold your vehicle still. But ultimately, you're probably going to have to move around a lot to find just the right location where the game won't decide to cancel a scan on account of movement.

Jool

Jool is by far the largest planet, but its surface gravity isn't outlandish, as it is no more than Laythe or Tylo. As it is a gas giant, you cannot land there, and will die if you try to do so. Jool has no biomes and no landed or splashed situation, so you can recover all science available from it from four points for the four situations: high in space, low in space, high flight, and low flight. Without biomes, picking up the science data in space above Jool is trivial.

The problem on Jool is that it is so large that its gravity from a given distance is quite strong, which means that as you get close, you'll be going very fast. If you head straight to Jool from where you enter its sphere of influence, you'll probably be going about 10000 m/s when you enter the top of its atmosphere at an altitude of 200 km. Even a stable orbit can have a speed at periapsis of about 9500 m/s. A perfectly executed gravity assist at Laythe, the moon nearest to Jool, can only take about 1000 m/s off of the speed at which you enter Jool's atmosphere. Even a lengthy, retrograde burn in space to bring you into a low, circular orbit just outside of Jool's atmosphere will still leave you traveling at about 6750 m/s.

The problem is that entering an atmosphere at that kind of velocity is a quick way to explode. Recall that thermal heating from atmospheric entry is roughly proportional to the square of your speed relative to the surface. If you come in at 10000 m/s, normal parts will reach 2000 K and explode about 5 km into the top of the atmosphere, where it is still very thin. A kerbal going on EVA will explode less than 2 km in. That does make it possible to pick up the science from high flight while just barely grazing the atmosphere--and still having enough energy to leave Jool's sphere of influence and head back to Kerbin. So while picking up the science from in flight high above Jool isn't that hard, it is harder than anywhere else in the game.

The real challenge of Jool is in getting the science data from its lower atmosphere. That means you're going to have to go deep into Jool's atmosphere and survive. And that, of course, means massively slowing down. It will help some that Jool rotates very quickly, with a surface velocity relative to orbit of about 1047 m/s at its equator. That means that a low, stable orbit can be going under 5700 m/s relative to Jool's surface. That's still very fast, but it's a lot less daunting than 10000 m/s.

In order to slow down enough to actually be safe, you're going to need either a very large retrograde burn or else some very good heat shielding. To get back to 6750 m/s for a low orbit, it's going to take a rather large vehicle to have enough delta-v to get out, which can make using heat shields awkward. Being able to slow down by several thousand m/s quickly will add several thousand delta-v to your requirement to safely descend, which is also awkward. And that's why getting to Jool's lower atmosphere and back is hard.

Even if you do try to use heat shields and aerobraking to slow down, they don't really slow you down that much. Even at an altitude of 100 km, a full 20 km into Jool's lower atmosphere, its atmospheric density is only about 1/5 that of Kerbin at sea level. That means that even with heat shields, you're going to need a very large retrograde burn just to stop before you start going up again.

To make your ascent easier, it's critical to bring a minimal payload back out. There is no reason to bring more than one kerbal. If you do bring a kerbal that you want to get out, make sure it's a pilot so that you don't also need a probe core. You may even wish to bring an EAS-1 external command seat in order to reduce the mass of housing the kerbal whom you wish to extract. You cannot do a crew report from the external command seat, but you can bring a different crew module, do the crew report, transfer to the external command seat, and then drop the larger crew module to start your ascent. Obviously, any science equipment should also be dropped before you start to ascend.

Jool's upper atmosphere isn't very dense, like the other upper atmospheres in the game. As you aren't trying to land, but only to get the science from Jool's lower atmosphere, you need not descend very far into the lower atmosphere. The boundary is at an altitude of 120 km, and at that height, Jool's atmosphere only has about 1/4 of the pressure of Kerbin's at sea level. Parachutes also won't fully deploy until much lower, which makes them fairly useless.

As with Eve, when trying to escape Jool's lower atmosphere, the goal is only to get to a low, stable orbit about Jool. Don't try to bring enough thrust to actually get back to Kerbin. Rather, have another vehicle that can meet the one that escaped Jool, pick up the science and perhaps kerbal, and have that other vehicle take it back to Kerbin.

The Sun

You can't land on the Sun, and you can't even get particularly close to it without burning up. You can, however, recover the science from space high above it and near it. Getting to space high above the sun is quite easy: just get out of Kerbin's sphere of influence and you're there. Getting near the sun is harder, as you have to be within a million km. This isn't particularly hard to do: just zip out of Kerbin's sphere of influence in the opposite direction from what Kerbin is traveling at a high enough speed to get your periapsis just below the threshold. Wait until you're at periapsis and pick up the science. Wait until you're back at apoapsis and thrust to get back to Kerbin.

Contracts

If you play in career mode, you'll need to earn funds in order to build your rockets. That mostly means doing contracts to earn money. While there are many types of contracts, some are far more lucrative than others. I'd like to highlight the most lucrative types of contracts, as those are the ones you'll probably want to focus on.

Even so, there is the question of how long you actually want to do contracts, even in career mode. At the Administration Building, you can enable "aggressive negotiation" from the list of strategies, which will give you a discount on rockets that you build. If you build a very expensive rocket, then immediately recover it on the launch price, you get refunded the full, non-discounted price tag. That allows you to pocket the difference, that is, the size of your discount. Once you build up enough reputation and funds to get started on this, you can just do this repeatedly for effectively infinite funds.

Part testing

In the very early game, part testing is the most useful type of contract. The idea is that you haul a particular part to some particular situation, such as an altitude and speed in particular ranges. Then you stage to enable the part, which completes the contract. This can be lucrative when all you need to do is launch a small rocket to an altitude of 20 km, stage, and return to the space center.

It doesn't take that long before part testing contracts want you to take parts much further away. Once they ask you to go to Kerbin's moons, or worse, other planets, the contracts become far less interesting, and other types of contracts become relatively more lucrative.

Tourists

Early on, your main source of revenue is tourist contracts. Tourists will pay to go to various places, then return to Kerbin. Tourists don't have any kerbonaut skills, but you can efficiently pack them into Mk1 Crew Cabins or a Mk3 Passenger Module. You'll generally want to take several tourists on a single trip, often from different contracts, even. You don't have to finish all of a tourist's desired destinations in a single trip, and can have the tourist land on Kerbin, then take off in another vehicle. A tourist contract is completed when all tourists have gone to all desired locations and returned to Kerbin.

Tourists will only ask to be flown to places that you've previously gone. At the very start, that means only around Kerbin. Soon after that, once you reach Kerbin's moons, tourists will want to go there, too. Taking tourists to Kerbin's moons or into orbit about the Sun (just outside of Kerbin's sphere of influence) isn't difficult and can be quite lucrative. Once you've reached the sphere of influence of other planets, tourists will want to go there, too, and that takes much longer for little gain, so you'll probably want to stop doing tourist contracts. Especially once tourists start demanding to land on Eve and then return to Kerbin, you don't want to take a contract that requires that.

Rescue kerbals

Some contracts will say that a kerbal has been stranded and ask you to go rescue him and return him to Kerbin. The kerbal will generally be in just a command pod with no resources at all. Some contracts only ask that you return the kerbal back to Kerbin, while others want you to return his command pod as well. For the latter, you'll need an Advanced Grabbing Unit.

The value of a kerbal rescue contract is not just the funds that you receive, but also that you get to keep the kerbal. Once you've hired a lot of kerbals for your program, each additional one can cost several hundred thousand funds, or even millions of funds. Being able to get a kerbal as a contract reward can thus be quite valuable.

As with tourists, kerbals will only get lost in places that you've been. You may want to avoid entering the sphere of influence of other planets until you've accumulated however many kerbals you want. Having kerbals get stranded in faraway places doesn't kill off kerbal rescue missions completely the way that it does with tourist missions, however. A single kerbal is stranded in one particular place, while the several tourists on a contract might collectively ask to go to ten different places. That one place might by random chance happen to be nearby, while tourist contracts are far more likely to have at least one place be somewhere that makes the whole contract a waste of money.

Transmit science

Some contracts ask you to transmit science from a particular planet or moon or from space around it. These are generally quick and easy contracts to finish. You have various probes or stations or whatever have equipment on board that can do some experiment, and put those landed on and in orbit around all available planets and moons. When you get the contract, you switch to the probe, run an experiment, transmit the data, and complete the contract.

Mine ore

Some contracts ask you to mine ore from a particular body. In some cases, they ask you to then transport the ore to somewhere else. The amount of ore is generally under 3000 units. The contracts to mine ore are readily handled by landing a base on every available planet and moon, then switching to it to mine ore when you draw such a contract. Bases intended for this should generally have at least 3000 units of ore storage (likely as two Large Holding Tanks for simplicity.

If the contract asks you to transport the ore, the game doesn't actually check whether it is the same ore at the ultimate destination that you mined. For example, if a contract asks you to mine ore from Minmus and put it in orbit around Kerbin, it works to mine ore on Minmus, then switch to a station orbiting Kerbin with ore onboard. You can thus plan ahead by putting space stations everywhere with 3000 ore on board to complete such contracts.

Fake forces

There are some situations in physics where it can simplify matters to use an accelerating reference frame and treat the way in which the acceleration is happening as a force on everything else. There are several such situations that can be useful ways to think about particular situations in the game. That probably doesn't make very much sense in the abstract, so let's get on with the examples.

Tidal forces

You're probably aware that the Earth's tides are mostly caused by the Moon. Have you ever stopped to think about why there are slightly less than two high tides and two low tides per day, even though there is only one Moon?

Suppose that there are three bodies: A, B, and C. B and C are much closer to each other than either of them are to A. A is very large, such as a planet, so it exerts a considerable gravitational pull. We could compute the exact effect of gravity of A on B and C separately. But we could also think of A as exerting a tidal force on C relative to B, with the force consisting of the difference between the effects of gravity of A on B and C.

That might not make much sense in the abstract, so let's give an example. If A is the Moon, B is Earth, and C is water on the surface of Earth, then the tidal force caused by the Moon can push the water closer to Earth or pull it away from Earth. For water between Earth and the Moon, the Moon pulls harder on the water than it does on Earth, so it effectively pulls the water away from Earth. That's how you get one high tide. For water on the opposite side of Earth, the Moon pulls on Earth harder than it pulls on the water, so it effectively pulls the Earth away from the water. That's how you get a high tide on the side opposite the Moon. For water along the edge so that it is about as far from the Moon as the center of Earth is, the Moon pulls both the water and Earth about as hard. But it doesn't quite pull them in the same direction, and tends to pull them toward each other. That's how you get a low tide--and two of them, on opposite sides.

In situations where both A and B are celestial bodies, the game's spheres of influence system wipes out any tidal forces. However, if B and C are two vehicles that you wish to dock in space, it can be useful to think of the planet or moon that they are orbiting as being A and exerting a tidal force on them. If you design a rectangular coordinate system such that B is at the origin and the z-axis is directly away from the center of A, then the tidal force pulls C toward B along the x- and y-axes, and away from B on the z-axis. The former typically won't cause a collision, as it's really just curving their orbits and doesn't systematically move them closer to each other. But that tidal forces pull the two objects toward each other in two axes and away in the third can explain why it looks like it's moving your target off to the side in some weird direction.

The magnitude of the tidal force matters a lot, though, as acceleration of 0.1 m/s^2 relative to your target can make it hard to dock, but acceleration of 0.0001 m/s^2 can readily be ignored. The magnitude of a tidal force is proportional to (distance between B and C) / (distance between A and B)^3. You could replace the distance between A and B by the distance between A and C, as the distances are assumed to be similar. It only makes sense to think of this as a tidal force when B and C are much closer to each other than either of them are to A.

One key thing to notice is that the magnitude of tidal forces is proportional to the distance between your two objects. If you're trying to have one vehicle dock with another and they're very close to each other, tidal forces can be very small. But if they start out very far away, tidal forces can be large enough to make the usual docking approach of burning target retrograde and then burning protarget not work very well.

It's also very important to notice that the magnitude of a tidal force is inversely proportional to the cube of the distance from the object causing it. This is the distance to the center of the object, but still, that power of 3 factor makes a huge difference. Getting twice as far away from the object reduces the tidal forces by a factor of 8. That means that you don't have to get nearly as close before you can start burning target retrograde and then burning protarget and have it actually work. When in low orbit about a celestial body--any celestial body, really--tidal forces mean that you have to get pretty close. When in a much higher orbit, docking is far more forgiving. For example, if you're trying to dock in a low orbit around Minmus only 10 km above sea level, and you start out 20 km away from your target, the strong tidal forces will make it not work very well, and might even crash you into Minmus. If you're at 640 km above the surface of Minmus, then you're ten times as far away from the moon's center, making the tidal forces only 0.1% as strong as before. From there, you could just get within 100 km and start to target retrograde then protarget burns and it would work fine.

The upshot is that docking high in space is considerably easier than docking while in a very low orbit, as the tidal forces that throw you off are much weaker there. If you're having trouble docking, try doing it in a very high orbit at first. That doesn't mean that you can't dock in a low orbit. You absolutely can. It's just harder.

Centripetal forces

A centripetal force, sometimes mistakenly called a centrifugal force, is a force that keeps a rotating object moving on a circle. For example, if you tie a weight to one end of a rope, hold the other end yourself, and spin around in a circle, the weight will rotate in a circle around you. If you let go of the rope, the weight would fly away from you. The rope is always pulling the weight toward you, but the centripetal force due to spinning balances that to keep the weight at a fixed distance from you as it moves in a circle.

The acceleration due to a centripetal force can be computed as a = rw^2, where a is acceleration, r is the radius of the circle, and w is the angular velocity. One can also substitute v = rw, where v is your speed, to get the form that I think is more helpful: a = v^2/r. Thus, the acceleration due to a centripetal force is proportional to the square of your speed.

There are two situations in the game where I find it helpful to think of something as being a centripetal force. The first is a fairly obvious one: gravity when you're in a circular orbit. In a stable circular orbit, if g is the acceleration due to gravity, then we have g = v^2/r as above. The reason I find this useful is when considering what happens when you change v, such as to slow down so that you can land.

Suppose that you reduce your velocity by 10%. In order to stay on a circular orbit, the centripetal force to keep you stable would be (.9v)^2/r, or .81 times what it was before. Burning retrograde doesn't actually change the force of gravity, of course, at least until you actually get meaningfully close to the planet you're orbiting. But if a force of .81 times actual gravity would be enough to keep you in a stable, circular orbit, then you actually accelerate vertically at .19 times the acceleration due to gravity. More generally, if you change your speed from v to kv for some constant k, your downward vertical acceleration due to gravity will be (1-k^2)g. This also works to give your upward acceleration if k > 1. Your speed here when not on a circular orbit is only the horizontal component, not the vertical component. Even so, it can give you some intuition about how fast you should expect to descend as you try to land.

The other situation where centripetal forces are useful is much less obvious: staging radially attached objects. You've probably run into a situation where you staged radially attached fuel tanks, only for them to immediately crash back into your rocket and blow it up. I mentioned earlier that the main fix for that is to be accelerating directly prograde when you stage them. If in an atmosphere, it must be prograde relative to the surface, not relative to orbit.

But while that mostly fixes the problem, it doesn't completely fix it. For one thing, the force applied by the radial coupler might not be aimed directly at the center of mass of the component to stage. The ejection force thus causes a net torque on the debris, causing it to spin. One end rotates away from your rocket, but the other rotates into your rocket, causing the collision. This can also happen if you have insufficient struts so that the debris was rotating some (as part of wobbling back and forth) before it was staged.

Another problem is that when your rocket is moving fast, it forces air out of the way, creating a partial vacuum behind it. Staged parts are sucked into the vacuum as they fall relative to your rocket. That pulls the bottom of the debris toward the space below your rocket, which can cause the top of the debris to crash into your rocket itself. This is especially a problem on Eve, where you may be going at relatively high speeds through a dense portion of the atmosphere during your ascent.

Often, the real fix for this is better rocket design, especially if the problem is a lack of struts. But you may have a vehicle that has reached its destination, and is unable to complete its mission because it keeps blowing up when taking off from Eve or Laythe or whatever. In that case, you can sometimes fix the problem by rotating your rocket before staying the parts. Make the rocket rotate in the roll direction (Q or E for the default controls) so that there is some centripetal force trying to pull outer components away, but balanced by the rocket's structure holding the debris in place as the rocket rotates. When you stage, the rocket's structure holding the debris in place is removed, so that the centripetal force of rotation can pull it away from your remaining rocket. Sometimes that will give you enough of an extra cushion to avoid the collision and complete a mission that otherwise seemed doomed.

Coriolis forces

If you throw a ball straight up on a windless day, where will it land? The obvious answer is, right where you threw it from. And given the strength of your arm, that will probably be correct to within measurement error. But suppose that you could fire a projectile straight up at a much higher velocity, though still below escape velocity, from a moon that has no atmosphere. Where will it land?

One good objection that I hope you raise is, is that "straight up" relative to the surface or relative to orbit? If it's relative to orbit, then the answer is pretty obvious: it will land to the west of where you threw it from. You throw the ball up, the moon rotates eastward while the ball is off the ground, and then it lands to the west because the moon moved.

But what if it is relative to the surface? In that case, I think it is helpful to imagine throwing the ball up very, very high. Imagine that it takes several days to land. It does sort of orbit, going nearly halfway around the moon, which is the most possible for such an orbit. But if the moon does more than half of a rotation, then it probably isn't going to land exactly where it was thrown from. It will again land to the west of there.

One way to think of this westward drift is as being the product of Coriolis forces. Traveling in any direction relative to the surface implicitly causes a force relative to the surface, with the direction of the force rotated 90 degrees from the direction of travel. Traveling up implicitly causes a force to the west, while traveling down causes a force to the east. These cancel off by the time you land, so that you're again going directly vertical, but not before you traveled to the west for a while while in the air.

Coriolis forces apply to horizontal travel, as well. Traveling east causes an upward force, while traveling west causes a downward force. This makes it easier to take off and achieve orbit while traveling east. The other way of thinking of that effect is that while on the surface, you're already traveling east relative to orbit, so it takes less additional delta-v to reach a stable orbit by going east.

It is sometimes said that Coriolis forces cause water to swirl in a particular direction when you flush a toilet. That is wildly false. The Coriolis forces are present, but on such a small scale, are far too weak to matter. Coriolis forces need much larger scales to be meaningful, such as orbiting an entire planet. On Earth, they also cause hurricanes to spin in a particular direction.