Difference between revisions of "Tutorial:Making Planets"

From Kerbal Space Program Wiki
Jump to: navigation, search
m
Line 1: Line 1:
{{Outdated|
 
* It is not updated for modern versions of the game, and does not depict any good practices or techniques that Kopernicus modders should use when making actual mods. This tutorial should therefore not be used if you are intending to make planet mods, not even as a jumping off point.}}
 
 
 
== Creating Your Own Planets ==
 
== Creating Your Own Planets ==
This tutorial is made for people who are getting bored with landing and collecting science on the stock planets, but if you could land on your own planets, that could be very interesting!
+
This tutorial is designed for those with a relentless, creative spirit. Those seeking a way to vent said creativity will be delighted to learn that, with the Kopernicus plugin's existence, it is now possible to modify the planetary system in Kerbal Space Program, allowing for new planets to be added and existing planets to be modified or removed entirely.
  
 
=== Specifications ===
 
=== Specifications ===
 
*Length: 15-20 minutes
 
*Length: 15-20 minutes
*Difficulty: Easy - Somewhat Intermediate
+
*Difficulty: Advanced
*For Version: 1.0.4+
+
*For Version: 1.3.X (Planets will work in 1.4, but the map exporter won't, so we'll be using 1.3 for this tutorial)
  
 
=== Requirements ===
 
=== Requirements ===
*Ksp (Duh)
+
*[https://forum.kerbalspaceprogram.com/index.php?/topic/140580-142-kopernicus-release-1-march-30/ Kopernicus]
*[http://forum.kerbalspaceprogram.com/threads/114649 Kopernicus 0.3.3]
+
*[https://forum.kerbalspaceprogram.com/index.php?/topic/140581-13-kopernicus-kittopiatech-a-kopernicus-visual-editor-release-2-sep-27/ KittopiaTech]
*[http://forum.kerbalspaceprogram.com/threads/129186 KittopiaTech 0.2]
+
*A text editor. Notepad can do the job, but Notepad++ is highly recommended.
*A text editor (Notepad, Notepad++,Sublime Text, etc.)
+
*(No, you do not need textures or image editors of any kind. In fact, if you're going to be advising SpaceEngine, I'm glaring at you.)
*A place to get textures (This can be SpaceEngine)
+
* The only objects that require the use of image editors and such are gas planets and stars. Terrestrial planets do not require textures to function.
*A photo editor (Photoshop, GIMP, Paint.net, etc.)
+
 
*An online normal map creator, like the one [http://cpetry.github.io/NormalMap-Online/ here] (optional)
+
=== Config Files ===
 +
 
 +
The first step when making planets is knowing the basics of config files. Let's start by creating one! For Notepad users, simply open up Notepad, then head to File -> Save As. Navigate to a location that you will be creating your mod at. Recommended is to create a folder for your mod somewhere (your desktop, for example) and using that folder to store all of your planet pack's data. We'll go over organizing said data later, for now, let's focus on not cluttering the hard drive and storing all mod info in a similar location.
 +
 
 +
Once you have settled on a nice saving location, write the name of your planet and '''remove the .txt''' as we will not be saving in this format. Add .cfg behind it, and select ''All Files'' in the drop-down menu following ''Save as type''
 +
 
 +
For this tutorial, we will be making a planet called Tutora. So, in this case, we would write ''Tutora.cfg''. The file name is actually not that important, but it's recommended to name config files properly so that you know just from the name what it contains.
 +
 
 +
Now we should have a .cfg file. Let's get to editing it!
 +
 
 +
Firstly, there are two kinds of config entries that you must memorize. The first is called a 'Config Node'. These appear as follows:
 +
 
 +
Orbit
 +
{
 +
...
 +
}
 +
 
 +
As you can see, the name of the node is followed up by an opening bracket, which is in turn followed up by the node's contents, then lastly - and this is very, very important - the closing bracket. (Notepad++ automatically highlights opening and closing bracket pairs, which is why it is pretty much industry standard when making planets.)
 +
 
 +
The other kind of config entry is called a 'Config Value', and these appear as follows:
 +
 
 +
semiMajorAxis = 19000000
 +
 
 +
As you can see, a config value is always in the format of 'X = Y', where X is the name of the Config Value and Y is the data assigned to it. Y can be many different kinds of data, for example a line of text (a 'string', as it is called in programming languages), a whole number (also known as an integer), or a number with decimals (also known as a 'float' or a 'double', depending on the situation).
 +
 
 +
Making planets is largely the product of simply placing the correctly named nodes in the right locations, and supplying the right config values with the right data.
 +
 
 +
=== Module Manager Syntax ===
 +
 
 +
Contrary to what some might expect, we are not actually writing a piece of code for Kopernicus. Rather, Kopernicus internally has a config file, which we will be altering - and this is very important - ''indirectly''. We will be using the 'Module Manager' plugin to patch Kopernicus' config file instead. This way, users can add and remove planet packs at will without having to go into the config files and swapping things out manually.
 +
 
 +
Although writing configs largely comes down to Nodes and Values, there are several handy commands that you can leave in your code for ModuleManager to use.
 +
 
 +
Let's go over a few.
 +
 
 +
@Orbit
 +
{
 +
...
 +
}
 +
 
 +
The @ operator means 'edit'. In the above example, instead of declaring a node named 'Orbit', we are instead telling Module Manager to patch an already existing Orbit node. Note that this will not randomly edit an Orbit node - only one in the exact same location, in another file. (IE the parent nodes of the node marked for editing must match those of the target node in terms of name)
 +
 
 +
!Orbit {}
 +
 
 +
The ! operator differs in use. In the above example, we tell Module Manager to remove the Orbit node. We do not need to specify anything in the brackets, just add them to inform Module Manager that we are targeting a NODE, not a VALUE. Another case for the ! operator is conditioning:
 +
 
 +
@Kopernicus:NEEDS[!OPM]
 +
{
 +
..
 +
}
 +
 
 +
Above, you can see that we edit the 'Kopernicus' node. However, we have added the 'NEEDS' condition to it. The above code, when translated to English, basically means:
 +
 
 +
''Edit the config node Kopernicus with the below changes, BUT only do so if the tag named OPM is NOT present.''
 +
 
 +
Note that 'not' is written in capital letters. This is because I would like to draw your attention to that word. Rather, the fact that, if we were to remove the ! operator from the above code example, we would have to remove the 'NOT' word in the translation. Ergo:
 +
 
 +
:NEEDS[OPM] = only patch when the tag 'OPM' is present
 +
:NEEDS[!OPM] = only patch when the tag 'OPM' is NOT present
 +
 
 +
But what are these 'tags' that I have mentioned thrice thus far? Tags can be targeted by Module Manager conditions, and can be declared in many ways:
 +
- Folders directly inside the GameData folder of your KSP directory can be targeted as a tag.
 +
- Tags can be declared with the :FOR[X] condition, where X is the name of the tag
 +
 
 +
And that brings us to the next condition: FOR.
 +
 
 +
@Kopernicus:FOR[Bob]
 +
{
 +
...
 +
}
 +
 
 +
FOR on it's own does not do anything, it is merely a marker for other conditions, namely BEFORE, AFTER and NEEDS. Let's call the config file containing the above node 'File A'. In that case, making config edits with conditions will have the following effects:
  
== Rocky Planets ==
+
:BEFORE[Bob] = The patch is applied before the patch declared in File A (which is marked as 'FOR[Bob]', remember!) is applied.
=== Steps ===
+
:NEEDS[Bob] = The patch is only applied if File A (or another file declaring the tag Bob through the use of FOR) is present.
==== 1. Getting Textures ====
+
:NEEDS[!Bob] = The patch is only applied if the tag 'Bob' is not declared anywhere.
 +
:AFTER[Bob] = The patch is applied after the patch declared in File A (or any other file declaring the tag Bob through the use of FOR)
  
(I will use SpaceEngine in this example)
+
And lastly, a more advanced condition, especially handy when editing a specific node of which there are multiple.
In order to get textures, open up SpaceEngine, find the planet you want to use, and click on export planet in the editor menu.
 
[[File:SpaceEngine_Planet_Export.png|thumb|center|This is how to export a planet from Space Engine]]
 
Make sure you uncheck the clouds and surface settings, and check the color map. All you need is color map, normal map, and height map. If you don't have SpaceEngine and you have a color and height map, use the online normal map. Just drag and drop the color and height map, and it will create your normal map. Save the files from SpaceEngine as .dds files, but if you have a .png file, open it up in your texture editor, and save another copy as .dds. Make sure you save all files as '''''YourPlanetName'''''. You should now have three files - '''''YourPlanetName''''' '''_Color.dds''', '''''YourPlanetName''''' '''_Normal.dds''', and '''''YourPlanetName''''' '''_Height.dds'''.<br />
 
  
 +
!Atmo:HAS[#name[Duna]]{}
 +
(Taken from [https://github.com/Galileo88/StockVisualEnhancements/blob/master/GameData/StockVisualEnhancements/SVE_Scatterer/Planets/Duna/atmo.cfg here] with lots of thanks.)
  
==== 2. Creating The Config Files ====
+
As you can see, we are removing the config node named 'Atmo', but we have the HAS condition preventing the deletion of every single node named 'Atmo'. The HAS condition limits the effect of a patch to config nodes that meet the declared condition. In the above example, each Atmo node is checked if it contains a Config Value named 'name', with an assigned value of 'Duna'.
  
Open up your text editor and copy this code into it.<br />
+
=== Planetary Nodes ===
  
CODE:
+
Before we start making planets, let's go over the config structure.
@Kopernicus
 
{
 
    Body
 
    {
 
        name =  //This will be the name of your planet.
 
        flightGlobalsIndex = 500 //You can make this any number, just not too big.
 
        Template
 
        {
 
            name =  //This is the template for your planet. Put Tylo for rocky planets, Laythe for ocean planets, Jool for gas giants, or Sun for stars.
 
        }
 
        Properties
 
        {
 
            radius =  //The distance in meters from the surface to the planet's center.
 
            geeASL =  //The planet's gravity. (Kerbin = 1)
 
            mass =  //The planet's mass. Not that important.
 
            tidallyLocked = true/false //Determines if the planet is tidally locked.
 
            rotationPeriod =  //Duration in seconds for the planet to complete a single rotation.
 
            description =  //The description of the planet. (Shows up in planet's Info panel)
 
            ScienceValues //The values for conducting experiments at the planet.
 
            {
 
                landedDataValue =
 
                splashedDataValue =
 
                flyingLowDataValue =
 
                flyingHighDataValue =
 
                inSpaceLowDataValue =
 
                inSpaceHighDataValue =
 
                recoveryValue =
 
            }
 
        }
 
        Orbit
 
        {
 
            referenceBody =  //The celestial body the planet orbits.
 
            inclination =  //Value in degrees for how far above the orbital plane the planet's orbit goes. (Use >90-<270 for retrograde orbit)
 
            eccentricity =  //Value from 0-1 for how much an ellipse the planet's orbit is. (1 is a parabolic escape trajectory, 0 is circular, in between is elliptical, >1 is hyperbolic, infinite makes the planet fall straight into the Sun)
 
            semiMajorAxis =  //This is the distance in meters your planet is away from the reference body.
 
            longitudeOfAscendingNode =  //The rotation of the orbit from the Ascending Node
 
            argumentOfPeriapsis = 0 //The angle between the Ascending node and Periapsis, changing this essentially changes the orbits rotation about the axis perpendicular to its plane.
 
            epoch = 0 //The reference time elapsed for meanAnomalyAtEpoch since Universal Time = 0. This is typically 0, unless this is the orbit of a ship or forcibly relocated asteroid.
 
            meanAnomalyAtEpoch =  //Changes the starting position of the body in its defined orbit. It is the time elapsed since the last periapsis, measured in seconds (in intervals of the orbital period, which is calculated by 2*Pi*sqrt(semiMajorAxis^3/G/mass of referenceBody))
 
            color = R,G,B,1 //The RGBA color code of your planet's orbit in the orbit map and tracking station. Divide each value by 255. The 4th value is Alpha, or the opacity of the color. Keep it at 1.
 
        }
 
        ScaledVersion
 
        {
 
            Material
 
            {   
 
                texture =  //This will be Kopernicus/Config/''YourPlanetName''/''YourPlanetName''_Color. Do NOT put .dds.
 
                normals =  //This will be Kopernicus/Config/''YourPlanetName''/''YourPlanetName''_Normal. Do NOT put .dds.
 
          }
 
      }
 
    }
 
}
 
  
When you have filled this out, save it as ''YourPlanetName''.cfg. Go inside your '''Kopernicus''' folder, go into the '''Config''' folder, and you should see a config file that says '''System'''. Do not open that file under any circumstances. Inside the '''Config''' folder, make a new folder that says ''YourPlanetName''. Move ''YourPlanetName.cfg'', and your three texture files inside.<br />
+
The first thing that we want to do is edit the Kopernicus Config Node. So let's open up the config we made earlier. Remember that we will be making a planet called Tutora.
  
==== 3. Setting Up KittopiaTech ====
+
@Kopernicus:FOR[Tutora]
(NOTE: The link included in the description does not include a '''SaveLoad''' folder.)
+
{
(This is only if you have a rocky or ocean planet.)Go inside your '''KittopiaTech''' Folder, and then into the '''SaveLoad''' folder, and make a new file in your text editor. Copy this code into it.
+
}
CODE:
 
Planet''YourPlanetName''  //In ''YourPlanetName'', put the name of your planet.
 
{
 
    AdditionalData  //Leave all of this false
 
    {
 
        Stock = False
 
        AddAtmoFx = False
 
        AddOceanFx = False
 
        OceanLoadTextures = False
 
        UnlitOcean = False
 
        ModScaledAtmoShader = False
 
        AddRings = False
 
        AddParticles = False
 
        DisableOrbitRenderer = False
 
    }
 
    PQS
 
    {
 
        PQSMod_HeightColorMap  //Leave this false
 
        {
 
            modEnabled = False
 
        }
 
        PQSCity  //Leave this false
 
        {
 
            modEnabled = False
 
        }
 
        PQSMod_VertexHeightMap
 
        {
 
            heightMap = GameData/Kopernicus/Config/  //Make this the location of your height map. Make sure you put GameData at the beginning, and to leave .dds on there.
 
            heightMapDeformity = 2500  //Basically determines the height of your mountains
 
            heightMapOffset = 0  //If your planet has oceans, set this to a negative number
 
            scaleDeformityByRadius = False
 
        }
 
        PQSMod_VertexColorMap
 
        {
 
            modEnabled = true
 
            vertexColorMap = GameData/Kopernicus/Config/  //Same as above, but make this the location of your color map.
 
        }
 
        PQSMod_VertexSimplexHeight  //Dont change any of this, except for the deformity
 
        {
 
            seed = 95374       
 
            deformity = 300
 
            octaves = 8       
 
            persistence = 0.5 
 
            frequency = 12
 
        }
 
        PQSMod_VertexSimplexHeightAbsolute  //Same as above
 
        {
 
            seed = 637926           
 
            deformity = 100 
 
            octaves = 3             
 
            persistence = 0.5
 
            frequency = 0.8
 
        }
 
        PQSMod_VertexSimplexHeightMap  //Leave this false
 
        {
 
            modEnabled = False
 
        }
 
        PQSMod_VertexHeightNoiseVertHeight  //Leave this false
 
        {
 
            modEnabled = False
 
        }
 
    }
 
}
 
Save this config file as ''YourPlanetName''.cfg in your SaveLoad folder. Now, put the Kopernicus and KittopiaTech folders inside GameData in your KSP directory.
 
  
=== Final Note ===
+
The observant among you have noticed that we are declaring this config with the tag 'Tutora'. This means that we can specify a loading order for config files (should we need this later) by marking patches with AFTER, BEFORE, and NEEDS.
The only reason you need this last config file is so your planet can have a custom height. If you didnt have this, your planet would almost look like Tylo on a different scale. If you get a glitch where only one side of the planet is lit up, change the opacity of your normal map to 50%.
 
  
== Ocean Planets ==
+
Every celestial body has its data stored in a node called 'Body'. There can be multiple Body nodes per config, but only one planet per Body node.
=== Steps ===
 
1. Get your textures.<br />
 
  
2. DO THE SAME THING THAT YOU DID ABOVE!!!<br />
+
Let's add the Body node to the above start.
  
3. Under the '''template''' section of your Kopernicus config, change it from Tylo to Laythe.<br />
+
@Kopernicus:FOR[Tutora]
 +
{
 +
    Body
 +
    {
 +
        name = Tutora
 +
    }
 +
}
  
4. In the KittopiaTech config, under the '''PQS_VertexHeightMap''' section, change the '''heightMapOffset''' from 0 to a negative number, such as -1000.<br />
+
I have also added the 'name' Config Value real quick. The 'name' Config value declares the name that the celestial body will wear, both internally and in-game (unless otherwise specified).
  
5. In your height map, paint all of the areas where you want your water to be pitch black, so the RGB amount reads 0,0,0
+
Inside the Body node of Tutora, we can add a variety of Config Nodes. Let's go over a few.
  
=== Final Note ===
+
''Debug {}''
You still need both config files for an ocean planet. Be careful with the '''heightMapOffset''', if you make it too low, like -5000, it will flood your planet.
+
Debug stores data for debugging planets, for example whether or not we want Kopernicus to generate a cache file.
  
== Gas Giants ==
+
''Properties {}''
=== Steps ===
+
Properties stores most of our planet's physical properties (mass, radius, gravitational acceleration, rotation period, whether or not our planet is tidally locked, et cetera) as well as some miscellaneous items such as the in-game description, the science multipliers, and the timewarp altitude limiters.
  
==== 1. Get Your Textures ====
+
''Orbit {}''
This will be the same as above, except you only need a color texture.
+
Orbit stores the data related to the planet's placement within the Kerbal universe, or rather, the path that it will follow through said universe.
  
==== 2. Make Your Planet Folder ====
+
''Template {}''
Do the same thing as above where you make the folder that will hold your planet.
+
Template allows you to clone a stock planet. If you choose a template, anything you declare in your config will be applied as a patch to a ''copy'' of that template's config file. Note: you are ''not'' altering the stock planet itself, rather Kopernicus clones it and applies the data you specified to that clone. Using a template is highly recommended. In the Template node, you can also do some rather interesting things, such as removing PQSMods from the template planet (we'll go over what in the world PQSMods are later), removing the ocean of the clone, or removing the atmosphere of the cloned planet.
  
==== 3. Set up config ====
+
''Atmosphere {}''
Make a new text file and copy this into it.
+
Atmosphere stores all of the information regarding a planet's atmosphere. Not just the altitude limiter, but also physical and chemical properties such as the adiabatic index (used for calculating the speed of sound), the molar mass (used for calculating the density), the temperature-height profile, and many other things.
CODE:
 
@Kopernicus
 
{
 
    Body
 
    {
 
        name =
 
        flightGlobalsIndex = //Change this to any number, just not too big.   
 
        Template
 
        {
 
            name = Jool  //Jool is the main template for a gas giant.             
 
        }
 
        Properties
 
        {
 
            radius =  //Distance in meters from the surface to the core.                                 
 
            geeASL =      //Amount of gravity your planet has. Kerbin is 1.                               
 
            mass =  //The mass is not important.                     
 
            description =  //The description of your planet.
 
            ScienceValues //The amount of science you will get around your planet.                                   
 
            {
 
                landedDataValue = 100
 
                splashedDataValue = 0
 
                flyingLowDataValue = 0
 
                flyingHighDataValue = 0
 
                inSpaceLowDataValue = 40
 
                inSpaceHighDataValue = 30
 
                recoveryValue = 5
 
            }
 
        }
 
        Orbit
 
        {
 
            referenceBody = Sun  //Body where your planet will orbit. Do NOT change to Kerbol, it is the Sun in game. 
 
            inclination =  //Self-explanatory         
 
            eccentricity =  //Self-explanatory         
 
            semiMajorAxis =  //Distance from the parent body in meters.
 
            longitudeOfAscendingNode = 0 //Leave the next four as zero.
 
            argumentOfPeriapsis = 0
 
            meanAnomalyAtEpoch = 0
 
            epoch = 0
 
            color = RGB value of your orbit. Divide each number by 255, and put a fourth 1 so you can see it. Ex: 0, 0, 0, 1 is black.
 
        }
 
        ScaledVersion
 
        {
 
            Material
 
            {   
 
                texture = Kopernicus/Config/  //Make this the location of your ''YourPlanetName''_Color. Do NOT include .dds.
 
            }
 
        }
 
    }
 
}
 
Save this file as ''YourPlanetName''.cfg, and move it into your planet's folder, along with the texture. Move the Kopernicus folder into your GameData and you are done!
 
  
=== Final Note ===
+
''Ocean {}''
Making a gas giant is the one of the easiest planets you can make. You only need one texture file, and you do not need a separate KittopiaTech config.
+
The Ocean node stores all data regarding a planet's oceans. If a planet's configuration does not contain an Ocean node, it will not have oceans.
  
== Finishing Word ==
+
''ScaledVersion {}''
With this tutorial, anyone should be able to create their own planets, to land on and collect science from. With a little more expirience, it is possible to actually make your planets into a mod.
+
Because keeping an entire planet loaded is rather taxing, KSP cleverly unloads the planet should the camera go too far from the planet, and instead will load in a relatively low-poly representation. Through ScaledVersion we can edit this representation. Essentially, ScaledVersion is in charge of making our planet look good from afar (such as in the Map View)
  
=== Important Note ===
+
''PQS {}''
If anyone could tell me if it is possible to make other stars with Kopernicus, that would be greatly appreciated.
+
PQS stands for Procedural Quad Sphere, and is the kind of terrain KSP uses for its planetary surfaces. The PQS node contains all of the data regarding our planet's ''actual'' terrain. It is therefore, in essence, the counterpart to ScaledVersion. Note that non-terrestrial objects such as Jool and the Sun lack the PQS node and thus a Quad Sphere, which is why they have no solid surface.

Revision as of 14:58, 13 April 2018

Creating Your Own Planets

This tutorial is designed for those with a relentless, creative spirit. Those seeking a way to vent said creativity will be delighted to learn that, with the Kopernicus plugin's existence, it is now possible to modify the planetary system in Kerbal Space Program, allowing for new planets to be added and existing planets to be modified or removed entirely.

Specifications

  • Length: 15-20 minutes
  • Difficulty: Advanced
  • For Version: 1.3.X (Planets will work in 1.4, but the map exporter won't, so we'll be using 1.3 for this tutorial)

Requirements

  • Kopernicus
  • KittopiaTech
  • A text editor. Notepad can do the job, but Notepad++ is highly recommended.
  • (No, you do not need textures or image editors of any kind. In fact, if you're going to be advising SpaceEngine, I'm glaring at you.)
  • The only objects that require the use of image editors and such are gas planets and stars. Terrestrial planets do not require textures to function.

Config Files

The first step when making planets is knowing the basics of config files. Let's start by creating one! For Notepad users, simply open up Notepad, then head to File -> Save As. Navigate to a location that you will be creating your mod at. Recommended is to create a folder for your mod somewhere (your desktop, for example) and using that folder to store all of your planet pack's data. We'll go over organizing said data later, for now, let's focus on not cluttering the hard drive and storing all mod info in a similar location.

Once you have settled on a nice saving location, write the name of your planet and remove the .txt as we will not be saving in this format. Add .cfg behind it, and select All Files in the drop-down menu following Save as type

For this tutorial, we will be making a planet called Tutora. So, in this case, we would write Tutora.cfg. The file name is actually not that important, but it's recommended to name config files properly so that you know just from the name what it contains.

Now we should have a .cfg file. Let's get to editing it!

Firstly, there are two kinds of config entries that you must memorize. The first is called a 'Config Node'. These appear as follows:

Orbit { ... }

As you can see, the name of the node is followed up by an opening bracket, which is in turn followed up by the node's contents, then lastly - and this is very, very important - the closing bracket. (Notepad++ automatically highlights opening and closing bracket pairs, which is why it is pretty much industry standard when making planets.)

The other kind of config entry is called a 'Config Value', and these appear as follows:

semiMajorAxis = 19000000

As you can see, a config value is always in the format of 'X = Y', where X is the name of the Config Value and Y is the data assigned to it. Y can be many different kinds of data, for example a line of text (a 'string', as it is called in programming languages), a whole number (also known as an integer), or a number with decimals (also known as a 'float' or a 'double', depending on the situation).

Making planets is largely the product of simply placing the correctly named nodes in the right locations, and supplying the right config values with the right data.

Module Manager Syntax

Contrary to what some might expect, we are not actually writing a piece of code for Kopernicus. Rather, Kopernicus internally has a config file, which we will be altering - and this is very important - indirectly. We will be using the 'Module Manager' plugin to patch Kopernicus' config file instead. This way, users can add and remove planet packs at will without having to go into the config files and swapping things out manually.

Although writing configs largely comes down to Nodes and Values, there are several handy commands that you can leave in your code for ModuleManager to use.

Let's go over a few.

@Orbit { ... }

The @ operator means 'edit'. In the above example, instead of declaring a node named 'Orbit', we are instead telling Module Manager to patch an already existing Orbit node. Note that this will not randomly edit an Orbit node - only one in the exact same location, in another file. (IE the parent nodes of the node marked for editing must match those of the target node in terms of name)

!Orbit {}

The ! operator differs in use. In the above example, we tell Module Manager to remove the Orbit node. We do not need to specify anything in the brackets, just add them to inform Module Manager that we are targeting a NODE, not a VALUE. Another case for the ! operator is conditioning:

@Kopernicus:NEEDS[!OPM] { .. }

Above, you can see that we edit the 'Kopernicus' node. However, we have added the 'NEEDS' condition to it. The above code, when translated to English, basically means:

Edit the config node Kopernicus with the below changes, BUT only do so if the tag named OPM is NOT present.

Note that 'not' is written in capital letters. This is because I would like to draw your attention to that word. Rather, the fact that, if we were to remove the ! operator from the above code example, we would have to remove the 'NOT' word in the translation. Ergo:

NEEDS[OPM] = only patch when the tag 'OPM' is present
NEEDS[!OPM] = only patch when the tag 'OPM' is NOT present

But what are these 'tags' that I have mentioned thrice thus far? Tags can be targeted by Module Manager conditions, and can be declared in many ways: - Folders directly inside the GameData folder of your KSP directory can be targeted as a tag. - Tags can be declared with the :FOR[X] condition, where X is the name of the tag

And that brings us to the next condition: FOR.

@Kopernicus:FOR[Bob] { ... }

FOR on it's own does not do anything, it is merely a marker for other conditions, namely BEFORE, AFTER and NEEDS. Let's call the config file containing the above node 'File A'. In that case, making config edits with conditions will have the following effects:

BEFORE[Bob] = The patch is applied before the patch declared in File A (which is marked as 'FOR[Bob]', remember!) is applied.
NEEDS[Bob] = The patch is only applied if File A (or another file declaring the tag Bob through the use of FOR) is present.
NEEDS[!Bob] = The patch is only applied if the tag 'Bob' is not declared anywhere.
AFTER[Bob] = The patch is applied after the patch declared in File A (or any other file declaring the tag Bob through the use of FOR)

And lastly, a more advanced condition, especially handy when editing a specific node of which there are multiple.

!Atmo:HAS[#name[Duna]]{} (Taken from here with lots of thanks.)

As you can see, we are removing the config node named 'Atmo', but we have the HAS condition preventing the deletion of every single node named 'Atmo'. The HAS condition limits the effect of a patch to config nodes that meet the declared condition. In the above example, each Atmo node is checked if it contains a Config Value named 'name', with an assigned value of 'Duna'.

Planetary Nodes

Before we start making planets, let's go over the config structure.

The first thing that we want to do is edit the Kopernicus Config Node. So let's open up the config we made earlier. Remember that we will be making a planet called Tutora.

@Kopernicus:FOR[Tutora] { }

The observant among you have noticed that we are declaring this config with the tag 'Tutora'. This means that we can specify a loading order for config files (should we need this later) by marking patches with AFTER, BEFORE, and NEEDS.

Every celestial body has its data stored in a node called 'Body'. There can be multiple Body nodes per config, but only one planet per Body node.

Let's add the Body node to the above start.

@Kopernicus:FOR[Tutora] {

   Body
   {
       name = Tutora
   }

}

I have also added the 'name' Config Value real quick. The 'name' Config value declares the name that the celestial body will wear, both internally and in-game (unless otherwise specified).

Inside the Body node of Tutora, we can add a variety of Config Nodes. Let's go over a few.

Debug {} Debug stores data for debugging planets, for example whether or not we want Kopernicus to generate a cache file.

Properties {} Properties stores most of our planet's physical properties (mass, radius, gravitational acceleration, rotation period, whether or not our planet is tidally locked, et cetera) as well as some miscellaneous items such as the in-game description, the science multipliers, and the timewarp altitude limiters.

Orbit {} Orbit stores the data related to the planet's placement within the Kerbal universe, or rather, the path that it will follow through said universe.

Template {} Template allows you to clone a stock planet. If you choose a template, anything you declare in your config will be applied as a patch to a copy of that template's config file. Note: you are not altering the stock planet itself, rather Kopernicus clones it and applies the data you specified to that clone. Using a template is highly recommended. In the Template node, you can also do some rather interesting things, such as removing PQSMods from the template planet (we'll go over what in the world PQSMods are later), removing the ocean of the clone, or removing the atmosphere of the cloned planet.

Atmosphere {} Atmosphere stores all of the information regarding a planet's atmosphere. Not just the altitude limiter, but also physical and chemical properties such as the adiabatic index (used for calculating the speed of sound), the molar mass (used for calculating the density), the temperature-height profile, and many other things.

Ocean {} The Ocean node stores all data regarding a planet's oceans. If a planet's configuration does not contain an Ocean node, it will not have oceans.

ScaledVersion {} Because keeping an entire planet loaded is rather taxing, KSP cleverly unloads the planet should the camera go too far from the planet, and instead will load in a relatively low-poly representation. Through ScaledVersion we can edit this representation. Essentially, ScaledVersion is in charge of making our planet look good from afar (such as in the Map View)

PQS {} PQS stands for Procedural Quad Sphere, and is the kind of terrain KSP uses for its planetary surfaces. The PQS node contains all of the data regarding our planet's actual terrain. It is therefore, in essence, the counterpart to ScaledVersion. Note that non-terrestrial objects such as Jool and the Sun lack the PQS node and thus a Quad Sphere, which is why they have no solid surface.