Difference between revisions of "CFG File Documentation"

From Kerbal Space Program Wiki
Jump to: navigation, search
m (Editor Parameters:)
 
(172 intermediate revisions by 53 users not shown)
Line 1: Line 1:
At first glance, the configuration file for an addon is a pretty confusing and infuriating thing. This tutorial will walk through the individual parts of the configuration file and hopefully give you an idea what everything does. As we go along, we'll build up a dummy part file that will behave exactly like a real one, only lacking models, sounds, and textures.
+
Configuration files are text files used to specify, store and adjust information for various parts of the game in a human-readable manner. They most commonly use the .cfg file extension, but this is not always the case. The most commonly referenced cfg files are [[API:Part|part]] configurations. These are used to change settings for the part such as mass, size and cost, as well as adding, removing or adjusting [[API:PartModule|part modules]], for example increasing an engine's thrust or adding resource storage capacity.
  
== Basic Part Making Guidelines ==
+
== Config Format ==
 +
The config format used in Kerbal Space Program is NOT a Unity class, but specific to KSP.
  
Before you delve into the part file, it's important that you make sure you check through your model for anything that might break the game on loading, but isn't related due to a CFG error.  
+
KSP reads .cfg files into config nodes. Config nodes can contain values (serialized versions of all sorts of data types) or other config nodes. See the [https://kerbalspaceprogram.com/api/class_config_node.html C# class documentation] in the KSP API Documentation for more details.  
Before you start editing the part, make sure that:
 
  
* The file is a .dae file. (For me, a .obj file simply doesn't work in game, and others have been saying the same thing. For conveniences sake, stick to .dae)
+
=== Module Manager ===
* That every single mesh has a material, even the collision mesh.
+
The stock config is very simple - nodes and values, which are nothing more than tree nodes and strings. Parsing is handled by modules that use .cfg files. See KSPField in the API.
* That you've named the parts correctly. The collision mesh should always be called "node_collider", etc.
 
  
== Part file creation ==
+
The mod Module Manager adds powerful filtering and extension capabilities to the Config Node format. If you see an @ signs, []'s, or it looks like programming, the config is using Module Manager. It is well documented [https://forum.kerbalspaceprogram.com/index.php?/topic/50533-* in the forum thread] and [https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax on sarbian's Gitub].
  
Okay, now that's out the way we can start looking into Part files, and how they work. Although it looks pretty confusing at first glance, it's actually a pretty simple ordeal to create one. To start, we're going to actually need an empty file in the right location.
+
== Basic Part Making Guidelines ==
 
 
*Fire up notepad
 
*Save it as "part.cfg" in the directory of your addon
 
** Usually "../KerbalSpaceProgramDirectory/Parts/yourAddon"
 
 
 
There, you now have an empty file waiting for juicy bits of configuration to be stuck into it. So let's keep going.
 
 
 
=== Config file order ===
 
 
 
The part.cfg file has a pretty much specific order in which things are done. The order is:
 
 
 
<pre>
 
// Title
 
// Name of your part
 
//
 
 
 
// --- general parameters ---
 
 
 
// --- asset parameters ---
 
 
 
// --- node definitions ---
 
 
 
// --- FX definitions ---
 
 
 
// --- Sound FX definition ---
 
 
 
// --- editor parameters ---
 
 
 
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
 
 
 
// --- standard part parameters ---
 
 
 
// --- specific part parameters ---
 
</pre>
 
 
 
So you'll notice those slashes in front of each title - that means that those lines have been '''commented out''' and so will not be read by Kerbal Space Program when it's loading your addon. From the point of view of the program, those lines don't exist. As we go through the tutorial, we'll build up the CFG file from it's bare bones to an actual working configuration file.
 
  
=== Give your part a title ===
+
Every part consists of multiple files, including the configuration file, a model and a collision mesh.  Under the 0.25 standards, the model and collision mesh must both have a material assigned when creating them in your modeling software and prior to export for use.  I am not a modeler, so I will leave that guidance to someone more qualified.
  
If you look at the very, very top of most part files you'll notice a couple of lines that look like this:
+
When creating a new part, each of these files (including additional models and meshes, if needed) should all be contained in a single folder which describes or names the part.  Even though Squad themselves are horribly inconsistent when building parts, it is best to have the name of the folder, and the names of each of the meshes match the name of the part inside the cfg file (not the name that you see in the parts building! More on that later).
  
<pre>
+
If you making more than a few parts, you may want to create a folder for each type of part.  This is certainly an acceptable practice, and one that Squad uses themselves.  For example:  /Engines/ to place all of your engine designs inside.
// Kerbal Space Program - Configuration file
 
// My super awesome engine that can go at a kajillion miles per hour, lol
 
</pre>
 
  
Those are quite simply, unimportant lines to KSP. The program doesn't read them, and doesn't give a crap about them either way. However, they are useful when other friendly people want to <s>steal your work</s> learn from your part file.
+
If you are making a mod that does things other than just provide a stock-capable parts pack, you may want a more subfolders, one for parts, one for agencies, another for contracts, etc, etc.
  
The first line simply states that this is a part file for KSP, and the second line is simply the name you give your part to other people to identify it.
+
No matter how deep you nest your mods' folders, your mod itself should be contained within the /GameData folder with a name that uniquely identifies your mod.  It would be wise to name this folder the same as you are marketing your mod (ie:  GameData\Modular Kolonization System\ is advertised as Modular Kolonization System or GameData\MechJeb is advertised as MechJeb) (and yes, I know that I'm using examples which actively violate this principle!)
  
So lets start creating our dummy CFG file.  
+
So, I wrote a mod (let's call it ShadowSplat) that modifies some resources, adds a few agencies, and massively updates the parts pack including new engines, fuel tanks, science containers, and electrics. My folder structure might look like this:
  
 
<pre>
 
<pre>
// Kerbal Space Program - Part CFG file
+
KSP_win\GameData\ShadowSplat\
// Mark V Rocket Engine
+
KSP_win\GameData\ShadowSplat\Agencies
 +
KSP_win\GameData\ShadowSplat\Resources
 +
KSP_win\GameData\ShadowSplat\Parts
 +
KSP_win\GameData\ShadowSplat\Parts\Engine
 +
KSP_win\GameData\ShadowSplat\Parts\FuelTank
 +
KSP_win\GameData\ShadowSplat\Parts\Science
 +
KSP_win\GameData\ShadowSplat\Parts\Electrical
 
</pre>
 
</pre>
  
Onwards!
+
== PARTS Configuration Files ==
 
 
== General Parameters: ==
 
  
Now, let's look at the next section of the file - the general parameters.
+
As of at least {{Check version|0.24.2}}, the order of the configuration file matters very little.  As far as I can tell, you can throw just about anything you want in there in any order.  However, for compatability and error-checking reasons, it's best to follow the general structure that exists within stock parts. Many of the stock parts contain commenting-out lines to help you decode where things should go, but, here's a general breakdown, using a mythological part (let's call it "DoesItAll").  DoesItAll will exist in this foldier:
 
 
<pre>// --- general parameters ---</pre>
 
 
 
This section comes straight under your title, and provides a few general things that apply to all parts. Here's a list of what goes under General Parameters:
 
  
 
<pre>
 
<pre>
name = solidBooster
+
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll
module = SolidRocket
 
author = Il Carnefice
 
 
</pre>
 
</pre>
  
Pretty easy, huh? No? Still a bit muddled? Okay, explanation time.
+
and will consist of the files:
 
+
<pre>KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.cfg
;name
+
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mu
:This is just that, a name. It can be anything, but notice that it's ''NOT'' commented out. This is what KSP will refer to the part as internally. It's good form to keep it all one word. Don't worry, you won't see it called this in game, so it can honestly be anything. Must be unique and cannot contain the underscore.
+
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mbm
;module
 
:Now this is slightly more difficult. Each part can be one of several different types of parts, defined by what comes after module. What type the part is defines how it works - for example, a solid rocket booster behaves differently from a liquid rocket motor. See [[#Valid Part Modules|Valid Part Modules]] for values you can use here.
 
;author
 
:Put your name here, you're the author!
 
 
 
So let's get on with our dummy file.
 
 
 
<pre>
 
// Kerbal Space Program - Part CFG file
 
// Mark V Rocket Engine
 
 
 
// --- General Parameters ---
 
name = LiquidThrusterV
 
module = LiquidEngine
 
author = YourName
 
 
</pre>
 
</pre>
  
There we go, a liquid engine type part, by proud author YourName.
+
Note:  this is a general explanation. Additional information can be found be clicking the provided links:
 
 
==== Parts ====
 
  
So what part types can you have?
+
=== General Parameters ===
  
{| class="wikitable"
+
{|class="wikitable"
 
|-
 
|-
! Part Name
+
! Actual part !! Explanation
! Description
 
 
|-
 
|-
! [[SolidRocket]]
+
| PART || - specifies that this cfg relates to a part
| Use this module if you want to make something akin to a solid rocket booster - a continually burning rocket that does not have any thrust controls and cannot be turned off once lit.
 
 
|-
 
|-
! [[LiquidEngine]]
+
| { ||
| Use this if you want to make something more like an orbital maneuvering system - a rocket engine which has controllable thrust.
 
 
|-
 
|-
! [[FuelTank]]
+
| [[#Name|name]] = DoesItAll || set the hidden name of the part.  Spaces are not allowed.  Underscores and other special characters are either not allowed or not recommended.  This name is used behind the scenes for reference to and from other parts and procedural calls, but is also revealed during crash/damage dialog boxes (F3).  It is good programming practice to use a name that at least partially defines the part and/or creator.  fuelTankSmallFlat (which is already in use) is not a good name to use here, even though it does describe the part effectively, it does not differentiate between an fuelTankSmallFlat - The T-100 fuel tank and the Rockomax X200-8 Fuel Tank, which could also be considered a fuelTankSmallFlat.  
| Simply put, use this if you want to make your part contain fuel to feed to other parts.
 
 
|-
 
|-
! [[CommandPod]]
+
| [[#module|module]] = Part || This convention is no longer used.  Earlier versions of KSP only permitted individual parts to serve as single modules and this was therefore appropriately placed back then.  Newer versions allow parts to have/serve as multiple modules and the conventions for defining those modules have been relocated and redefined as its own subgroup.  Can still be found in legacy parts that have not been updated, including the "Tail Fin" by C7 Aerospace Division.  5 parts in total are known to still use this convention.
| Feel like sticking three guys in your part and using it to control the rocket? Use this part.
+
* FuelLine has the additional property of maxLength, presumably to restrict the length of fuel lines.  This method is used on the Stock Fuel Line
 +
* StrutConnector has the additional properties of linearStrength, angularStrength and maxLength.  This method is used on the stock Strut Connector
 +
* Winglet has the additional properties of dragCoeff and deflectionLiftCoeff.  just like the ModuleControlSurface.  This method is used on the stock parts Tail Fin, wingletAV-T1, sweptWing and is expected to be deprecated at the next revision of those parts.
 +
|-
 +
| [[#author|author]] || Simply a place to take credit for your creation / update.  This line is not referenced in-game.  It is recommended that you utilize the same author credit for all parts that you or your team create under one title.  For example, assign all MKS mods to author MKS Team and all OKS mods to author OKS team, even though you are all the same team.
 +
|}
 +
 
 +
=== Model Parameters ===
 +
 
 +
At this point, you can use the deprecated style of [[#mesh|mesh]] on a line by itself, or open a new sub called MODEL. The preferred method is to use MODEL:
 +
 
 +
{|class="wikitable"
 
|-
 
|-
! [[SASModule]]
+
! Actual part !! Explanation
| This type of part stops the rocket from rotating and flipping and dropping off course.
+
|-
 +
| MODEL { || opens the MODEL sub
 +
|-
 +
| model || The name of the mesh. Write its name therein and keep the mesh file in the same directory as the part file.
 
|-
 
|-
! [[SASModule2]]
+
| scale || The scale of the model - depending on the units in your 3D modelling program. If you used one unit = one meter, then use a scale of 1. If it's 1 unit = 0.1 meters, then use a scale of 0.1. Using a 0.1 scale factor and then scaling to fit the other parts is easier than fiddling around with scale factors. This factor will only affect the units involved in node placement and will not affect the actual size of the part.
|???
 
 
|-
 
|-
! [[Strut]]
+
| texture || Specifies let location of the texture file - e.g. texture = texturefilename , folder/../texturefilename (/folder would be GameData/folder)
| A connective module, which allows you to connect different rocket parts together. Has no special abilities.
+
|}
|-
+
 
! [[Decoupler]]
+
If you do not use [[#MODEL|MODEL]], you must use mesh to define the parts collision mesh, like so:
| This connects rocket parts together but allows you to jettison itself and the parts it's connected to.
+
 
|-
+
{|class="wikitable"
! [[RadialDecoupler]]
 
| This connects parts together much like a Decoupler, but it behaves somewhat differently (as in ejection forces) since it assumes this part will connect laterally to the ship.
 
|-
 
! [[Parachutes]]
 
| This module can deploy a parachute to slow you down.
 
|-
 
! [[ControlSurface]]
 
| Movable wing-like surface. Can act as a rudder, aileron, elevator, canard or other aerodynamic control surface - function depends on placement on a ship.
 
|-
 
! [[WarpEngine]]
 
| A warp engine. Not functional as of 0.15.2.  
 
|-
 
! [[Winglet]]
 
| A lift producing part. Not movable.
 
|-
 
! [[Stabilizer]]
 
| Similar to ControlSurface (recommend to not use)
 
|-
 
! [[StrutConnector]]
 
|???
 
|-
 
! [[RCSFuelTank]]
 
| A RCS tank.
 
|-
 
! [[RCSModule]]
 
| A RCS thruster.
 
|-
 
! [[AtmosphericEngine]]
 
| An engine for use in the atmosphere, with air flow parameters.
 
|-
 
! [[AdvSASModule]]
 
| An SAS-type module that alters user input allowing for control of RCS, pod torque, gimballing engines and control surfaces.
 
|-
 
! [[DecouplerGUI]]
 
| A normal decoupler that can be disconnected using the right-click GUI.
 
|-
 
! [[DockingPort]]
 
| A unfinished docking port?
 
|-
 
! [[FuelLine]]
 
| Allows for transfer of fuel.
 
 
|-
 
|-
! [[FuelTankGUI]]
+
! Actual part !! Explanation
| A fuel tank with a right-click GUI to disable flow.
 
|-
 
! [[LandingLeg]]
 
| A moving landing leg, using .cfg parameters to move.
 
|-
 
! [[HLandingLeg]]
 
| A moving landing leg, using animations to move.
 
|-
 
! [[HParachutes]]
 
| A animated parachute module?
 
|-
 
! [[LandingGear]]
 
| Wheeled, animated landing gear for spaceplanes.
 
|-
 
! [[SatELight]]
 
| A flash-light module.
 
|-
 
! [[LiquidFuelEngine]]
 
| A liquid fuel engine that uses Thrust and Isp, rather than Thrust and fuel units.
 
 
|-
 
|-
 +
| mesh || Mesh defines the mesh and texture package used to create the in-game appearance of your part.  Acceptable meshes include .mu files.
 +
|-
 
|}
 
|}
  
== Part Modules ==
+
=== Asset Parameters ===
  
Please read: [http://kerbalspaceprogram.com/forum/index.php?topic=11734.0 "0.15 code update - PartModule, KSPField, KSPEvent, ConfigNode and PartResource"]
+
{|class="wikitable"
 
 
{| class="wikitable"
 
|-
 
! Module Name
 
! Description
 
|-
 
! [[ModuleAerodynamicLift]]
 
| Lift producing module?
 
|-
 
! [[ModuleAnimateHeat]]
 
|???
 
|-
 
! [[ModuleAnimatorLandingGear]]
 
| Animated landing gear module?
 
 
|-
 
|-
! [[ModuleCommand]]
+
! Actual part !! Explanation
| Command module?
 
 
|-
 
|-
! [[ModuleEngineRocketLiquid]]
+
| [[#mesh|mesh]] = DoesItAll.mu || Mesh defines the mesh and texture package used to create the in-game appearance of your part.  Acceptable meshes include .mu files
| Liquid rocket engine module?
+
|-
 +
| [[#scale|scale]] || scale defines the size of your part.  I am uncertain as to what will happen when you change this value
 
|-
 
|-
! [[ModuleResource]]
+
| [[#specPower|specPower]] || Specific Power?  fuelLine
| Generic resource module?
+
|-
 +
| [[#rimFalloff|rimFalloff]] || 3  fuelLine
 
|-
 
|-
! [[ModuleResourceIntake]]
+
| [[#alphaCutoff|alphaCutoff]] || Number: 0.0  fuelLine
| Generic resource "intake" module, to add to or take away from "ModuleResource"?
 
 
|-
 
|-
! [[ModuleTest]]
+
| [[#rescaleFactor|rescaleFactor]] ||
|???
+
An optional parameter that is not usually included in most parts, but the option is available for resizing a part for personal use. In order to retain correct node placements, the scale parameter must also be proportionally changed to match the new rescaleFactor. The default value for rescaleFactor is 1.25 but can be changed to any value.
 
|-
 
|-
 +
| [[#iconCenter|iconCenter]] || 0,3,0 Array of integers? (advSasModuleLarge, fuelLine)
 
|}
 
|}
  
 +
=== Node Definitions ===
 +
So, node definitions are a little weird.  You don't have to use any, and you *can use a whole bunch.  Defines where parts attach to other parts.  Tricouplers have four: three bottom and one at the top, while most parts simply have two, and a few parts have only one. 
  
== Asset Parameters ==
+
Node stack defines where the part vertically stacks with other parts, and node attach defines where on a part's surface other parts attach - in other words, horizontal attachment.
  
This section defines the assets of our module - it provides us with links to our model and to our texture file, as well as giving us some extra settings to play around with.
+
The attachment values relate to an object's origin, and their values correspond to a model's units and scaling factors. A node_stack_bottom with x, y, and z values of (2.5, 5.0, 3.0) will have an attachment node 2.5 units to the right, 5.0 units up, and 3.0 units forward. The next three values refer to the orientation that a particular node will accept other attachments, on a scale of -1.0 to 1.0. These represent the vector that a part will orient itself on when attaching to the node. For example, a fuel tank with a node_stack_bottom will have angx, angy, and angz values of (0.0, -1.0, 0.0). This represents a vector downward relative to the part model, in the negative y direction. A value of (0.0, -1.0, 1.0) would represent a diagonal vector downward and forward, while a value of (1.0, 1.0, 1.0) would represent a vector to the right, up, and forward.
  
<pre>
+
Generally, most parts will have angx, angy, and angz values of either (0.0, -1.0, 0.0) for a node_stack_bottom and (0.0, 1.0, 0.0) for a node_stack_top.
// --- asset parameters ---
 
mesh = modelfile.dae
 
scale = 0.1
 
texture = texturemap.png
 
specPower = 0.5
 
rimFalloff = 3
 
alphaCutoff = 0
 
</pre>
 
  
Lets go through them.  
+
The last value indicates the visual size of an attachment node. Values may be either 0 (small half-meter node), 1 (normal), or 2 (large). This parameter is optional and will default to 1 if nothing is specified.
  
;mesh
+
Keep in mind, naming conventions (_stack_bottom, _stack_top) for nodes only apply to node_stack; they are only helpful in identifying a node's position.
:Easy, the name of the mesh you want to use for your model. Just write it's name in there, but keep the mesh file in the same directory as the part file.
 
  
;scale
+
Known node definitions are listed below:
:The scale of your model, depending on how you used the units in your 3D modelling program. If you used one unit = one meter, use a scale of 1. If it's 1 unit = 0.1 meters, use a scale of 0.1, that simple. I tend to stick to using a 0.1 scale factor and then scale my model to fit with the rest of the parts, it's easier than fiddling around with scale factors.
 
  
;texture
+
* node_stack_top
:The name of your texture file, which would be found inside the ''KSPDirectory/Parts/yourAddon/textures'' folder. Textures should be either 256x256, 512x512 or 1024x1024
+
* node_stack_bottom
 +
* node_stack_top2
 +
* node_stack_bottom2
 +
* node_stack_connect01
 +
* node_stack_connect02
 +
* node_stack_connect03
 +
* node_attach
 +
* node_stack_bottom01
 +
* node_stack_bottom02
 +
* node_stack_bottom03
 +
* node_stack_bottom04
  
;specPower
+
Each one follows this example, and specifies where other parts can connect to this part:
:The specular reflectivity of your part. It's best to leave it as it is.
 
  
;rimFalloff
+
{|class="wikitable"
:This defines the strength of the highlight effect in game. Higher values lead to a more pronounced effect near the edges.
+
|-
 
+
! Actual Part !! Explanation
;alphaCutoff
+
|-
:This number defines the threshold for transparency on the part's texture. If your texture has an alpha channel (transparency), you can adjust this number to make sure your part is transparent or opaque where it should be. A value of 0 means nothing in the texture is considered to be transparent. A value of 1 means a completely transparent part.
+
| [[#node_attach|node_attach]] = 0.00, 0.147, 0.00, 0.0, 1.0, 0.0, 1 || specifies the location of the nodes of this part (the green circles).
 
+
|}
There, that's everything under asset parameters covered. Let's continue building our dummy part file.
 
 
 
<pre>
 
// Kerbal Space Program - Part CFG file
 
// Mark V Rocket Engine
 
 
 
// --- General Parameters ---
 
name = LiquidThrusterV
 
module = LiquidEngine
 
author = YourName
 
 
 
// --- Asset Parameters ---
 
mesh = myMesh.dae
 
scale = 0.1
 
texture = awesometexture.png
 
specPower = 0.5
 
rimFalloff = 3
 
alphaCutoff = 0
 
</pre>
 
 
 
Onwards!
 
 
 
== Node Definitions ==
 
 
 
Another fairly easy section, this defines where we attach our part to other parts. You can have as many as you want, for example, tricouplers have four, three bottom and one top, while most parts simply have two, and a few parts have only one.
 
  
 
<pre>
 
<pre>
Line 309: Line 164:
 
</pre>
 
</pre>
  
There's three example nodes. There are three different kinds, but only two are useful to us at the moment. We have node_stack and node_attach. Node stack is for defining where the part stacks vertically together with other parts, and node attach is used for defining where on the surface of your part other parts attach - so horizontal attachment.
+
=== FX definitions ===
 +
FX definitions specify visual effects associated with this part, including engine exhausts, explosions, and coloration. Each one is a unique effect, and the only parameters they take is the location/offset that the effect occurs at
 +
The 'active' switch on the end is used to define ''when'' this effect will be visible. See the [[FX Groups]] listing to know which effect groups are available, and when they are used.
 +
It's also possible to assign an effect to more than just one FX Group. If for instance, you want a smoke effect to be visible both when the part activates and also when it deactivates itself, you can do this:
 +
 
 +
fx_gasBurst_white = x, y, z, angx, angy, angz, activate, deactivate
  
A good idea is to make sure angx, angy, angz is set to 0, 1, 0 respectively to make the attachment point be directed upwards, but it's your choice.
+
This is particularly useful if you're defining a lot of effects, like the gas discharges on an RCS module.
  
Notice the identifier after node_stack - there's _top and _bottom. All these do is separate the nodes and make it easy for you to know which is which. You could call them node_stack_chicken and node_stack_bananabread if you wanted, as long as you know where those points correspond to.
 
  
 
<pre>
 
<pre>
// Kerbal Space Program - Part CFG file
 
// Mark V Rocket Engine
 
 
// --- General Parameters ---
 
name = LiquidThrusterV
 
module = LiquidEngine
 
author = YourName
 
 
// --- Asset Parameters ---
 
mesh = myMesh.dae
 
scale = 0.1
 
texture = awesometexture.png
 
specPower = 0.5
 
rimFalloff = 3
 
alphaCutoff = 0
 
 
// --- Node Definitions ---
 
node_stack_bottom = 0.0, -3.5, 0.0, 0.0, 1.0, 0.0, 1.0
 
</pre>
 
 
== FX definitions: ==
 
 
More definitions! But this time, you're positioning the flame coming out the back of the rocket.
 
 
 
  fx_exhaustFlame_yellow = x, y, z, angx, angy, angz, active
 
  fx_exhaustFlame_yellow = x, y, z, angx, angy, angz, active
 
  fx_exhaustLight_yellow = x, y, z, angx, angy, angz, active
 
  fx_exhaustLight_yellow = x, y, z, angx, angy, angz, active
 
  fx_smokeTrail_medium = x, y, z, angx, angy, angz, active
 
  fx_smokeTrail_medium = x, y, z, angx, angy, angz, active
 +
</pre>
  
Okay, looks pretty similar to node_definitions, right?
+
Known FX calls are listed below:
  
You'll notice, just like node definitions, there are separate parts to each effect. You have fx_exhaustFlame, fx_exhaustLight, and fx_smokeTrail.
+
* fx_exhaustFlame_blue_small
 +
* fx_exhaustFlame_yellow
 +
* fx_exhaustFlame_yellow_tiny
 +
* fx_exhaustFlame_blue
 +
* fx_exhaustFlame_white_tiny
 +
* fx_exhaustLight_yellow
 +
* fx_exhaustLight_blue
 +
* fx_smokeTrail_medium
 +
* fx_smokeTrail_light
 +
* fx_gasBurst_white
 +
* fx_exhaustSparks_flameout
 +
* fx_exhaustSparks_flameout_2
 +
* fx_exhaustSparks_yellow
  
There are exactly what they sound like, the flame, the light, and the smoke trail.
+
Module Parameters for PREFAB_PARTICLE and MODEL_MULTI_PARTICLE:
  
There are variations on flame color, blue is also an option. To get a blue flame, you would use fx_exhaustFlame_blue. You would do the same for the exhaustLight.  
+
{|class="wikitable"
 
+
|-
The 'active' switch on the end is used to define ''when'' this effect will be visible. See the [[FX Groups]] listing to know which effect groups are available, and when they are used.
+
! Variable !! Value !! Definition
It's also possible to assign an effect to more than just one FX Group. If for instance, you want a smoke effect to be visible both whe the part activates and also when it deactivates itself, you can do this:
+
|-
 
+
| prefabName || fx_exhaustFlame_blue || The name of the effect you want to use (See list above).
fx_gasBurst_white = x, y ,z, angx, angy, angz, activate, deactivate
+
|-
 
+
| transformName || smokePoint || The name of the point defined in the Unity editor where the effect will appear from.
This is particularly useful if you're defining a lot of effects, like the gas discharges on an RCS module.
+
|-
 
+
| size || Throttle Range (0.0), Scale (0.0) || '''(Deprecated, doesn't work!)''' Scales the size of the particle effect set in the Unity editor. This parameter is usually the same number as the size in meters for the part (1.25, 2.5, 3.75, etc.). You need one line with a declaration for every point on the throttle range you are editing (See example below).
Feel like you're getting the hang of this now? Let's keep building the dummy part file, and add in a blue flame and light, but leave out the smoke trail.
+
|-
 +
| energy || Throttle Range (0.0), Scale (0.0) || Scales the energy of the particle effect set in the Unity editor. Energy is the time it takes for the effect to disappear. For smoke trails, you want a high value, but for water vapor you want a small value. You need one line with a declaration for every point on the throttle range you are editing (See example below).
 +
|-
 +
| emission  || Throttle Range (0.0), Scale (0.0) || Lets you edit the emission range and scale of the effect. It handles amount of particles in a set amount of time. You need one line with a declaration for every point on the throttle range you are editing (See example below).
 +
|-
 +
| speed || Throttle Range (0.0), Scale (0.0) || Scales the velocity of the particle effect set in the Unity editor. You need one line with a declaration for every point on the throttle range you are editing (See example below).
 +
|-
 +
| localOffset || X, Y, Z || Used in PREFAB_PARTICLE.  Lets you change the offset of the effect in 3D space. To move the particle effect closer to or further from the nozzle, edit the Z axis.
 +
|-
 +
| localPosition || X, Y, Z || Used in MODEL_MULTI_PARTICLE. Lets you change the offset of the effect in 3D space. To move the particle effect closer to or further from the nozzle, edit the Z axis.
 +
|-
 +
| localScale || X, Y, Z || Used in MODEL_MULTI_PARTICLE. This was implemented in KSP 1.4.5 and replaces the size parameter. Lets you change the size of the particle so that the same particle can be custom fit to engines of various sizes. However, values other than [1, 1, 1] only work properly when the engine has (for part makers: only one of the named emitter transform; for casual players: only one nozzle). It works correctly on RCS thrusters that have up to 5 such emitters. This parameter also cannot be used on any of the particles provided by default in the game or by most part mods. New particles must be made such that the same transform that holds the PartTools script also holds the KSP Particle Emitter script.
 +
|-
 +
|}
  
 +
Example taken from the config file for the [[S3 KS-25 "Vector" Liquid Fuel Engine]]:
 
<pre>
 
<pre>
// Kerbal Space Program - Part CFG file
+
PREFAB_PARTICLE
// Mark V Rocket Engine
+
{
 
+
prefabName = fx_smokeTrail_light
// --- General Parameters ---
+
transformName = smokePoint
name = LiquidThrusterV
+
emission = 0.0 0.0
module = LiquidEngine
+
emission = 0.05 0.0
author = YourName
+
emission = 0.075 0.25
 
+
emission = 1.0 1.25
// --- Asset Parameters ---
+
speed = 0.0 0.25
mesh = myMesh.dae
+
speed = 1.0 1.0
scale = 0.1
+
localOffset = 0, 0, 0
texture = awesometexture.png
+
}
specPower = 0.5
 
rimFalloff = 3
 
alphaCutoff = 0
 
 
 
// --- Node Definitions ---
 
node_stack_bottom = 0.0, -3.5, 0.0, 0.0, 1.0, 0.0, 1.0
 
 
 
// --- FX Definitions ---
 
fx_exhaustFlame_blue = 0.0, -10.0, 0.0, 0.0, 1.0, 0.0, active
 
fx_exhaustLight_blue = 0.0, -10.0, 0.0, 0.0, 0.0, 1.0, active
 
 
 
 
</pre>
 
</pre>
  
== Sound FX definition ==
+
=== Sound FX definitions ===
 +
Just like Visual effects, sound effects specify an effect to be used by the part.  Sound effects are coded using a two-sided equation, the left side specifies the sound or sound file to be used, whereas the right side specifies when to use that particular sound.  Known Sound Effects definitions are:
  
 
This is pretty easy to use in a basic way, which will suit our needs just fine.
 
This is pretty easy to use in a basic way, which will suit our needs just fine.
Line 399: Line 251:
 
Sounds are added to FX Groups, in much the same way smoke and flame effects are. Of course, sounds do not need to be positioned in space, nor do they have rotations, so all you need is to indicate in which FX Group the sound will be executed. As with effects, you can assign multiple groups to a sound.
 
Sounds are added to FX Groups, in much the same way smoke and flame effects are. Of course, sounds do not need to be positioned in space, nor do they have rotations, so all you need is to indicate in which FX Group the sound will be executed. As with effects, you can assign multiple groups to a sound.
  
There are 3 ways to add a sound to a part. KSP has an internal sound library, which contains a few sound effects. By defining a sound as in the example above, KSP will search for that sound in it's internal library.
 
KSP also has a Sounds folder on it's main directory. This folder contains sounds that are available to every part in the Parts folder. To use a sound from the Sounds folder, you must include the file extension in the sound name (e.g., sound_vent_medium.wav = activate)
 
The 3rd way is to include your own sound effects to your Part folder (e.g., KSPDirectory/Parts/MyPartFolder/Sounds), and define your sound effect in the same manner as above.
 
  
REMEMBER: If you add a custom sound, the file name must start with '''sound_''' (e.g., sound_myNewSoundEffect.wav).
+
Since 0.20 GameData structure there are 2 ways to add a sound to a part:
  
Sounds added to a Sounds folder inside the Part folder may not be accessed by other parts. Think of those as 'private' sounds.
+
* KSP has an internal sound library, which contains a few sound effects. By defining a sound as in the example above, KSP will search for that sound in its internal library.
 +
* The second way is to add new sound files which is ONLY possible if adding the sound file to the GameData/modName/parts/partName/part/sounds/ folder. Note that all the sounds are therefore "private", only accessed by that part. For now, the legacy folder or a shared mod folder method doesn't work, devs are probably going to fix this problem in the future.
  
Adding sound FX to our dummy part file:
 
  
<pre>
+
REMEMBER: If you add a custom sound, the file name must start with '''sound_''' (e.g., sound_myNewSoundEffect.wav).
// Kerbal Space Program - Part CFG file
 
// Mark V Rocket Engine
 
  
// --- General Parameters ---
+
To use a sound from the KSP internal library or the part/sounds folder, you must not include the extension in the sound name (e.g., sound_vent_medium = activate), otherwise the sound will not work.
name = LiquidThrusterV
 
module = LiquidEngine
 
author = YourName
 
  
// --- Asset Parameters ---
+
Supported files are 48000&nbsp;Hz .wav files and .ogg
mesh = myMesh.dae
 
scale = 0.1
 
texture = awesometexture.png
 
specPower = 0.5
 
rimFalloff = 3
 
alphaCutoff = 0
 
  
// --- Node Definitions ---
+
These are the paired sound types and part statuses.
node_stack_bottom = 0.0, -3.5, 0.0, 0.0, 1.0, 0.0, 1.0
+
{|class="wikitable"
 
+
|-
*'''// --- FX Definitions ---
+
! Sound !! Engine Status
fx_exhaustFlame_blue = 0.0, -10.0, 0.0, 0.0, 1.0, 0.0, active
+
|-
fx_exhaustLight_blue = 0.0, -10.0, 0.0, 0.0, 0.0, 1.0, active
+
| sound_jet_low || decouple
 
+
|-
// --- Sound FX definition ---
+
| sound_jet_deep || engage
sound_vent_medium = activate
+
|-
sound_rocket_hard = active
+
| sound_vent_soft || running
sound_vent_soft = deactivate
+
|-
</pre>
+
| sound_vent_large || power
 
+
|-
== Editor Parameters: ==
+
| sound_vent_medium || disengage
 
 
Aha! We're back to parameters! These set of parameters let us decide how our part is displayed in the rocket editor. This section has the following:
 
 
 
// --- editor parameters ---
 
cost = 450
 
category = 0
 
subcategory = 0
 
title =
 
manufacturer =
 
description =
 
 
 
;cost
 
:This hasn't really been implemented yet, but when it is it sets the cost for spaceship parts. You can set this to anything for now, it's entirely up to you.
 
 
 
;category
 
:There are six categories:
 
 
 
{| class="wikitable"
 
 
|-
 
|-
! Name
+
| sound_rocket_hard || flameout
! ID
 
! Description
 
 
|-
 
|-
! Propulsion
+
| sound_rocket_mini || activate
| 0
 
| Put your engine here!
 
 
|-
 
|-
! Command and Control
+
| sound_decoupler_fire || deploy
| 1
 
| Command pods and SAS modules here
 
 
|-
 
|-
! Structural and Aerodynamic
+
| sound_explosion_low ||
| 2
 
| Struts, wings, and supporting things
 
 
|-
 
|-
! Utility and Scientific
+
| sound_parachute_open ||
| 3
 
| Parachutes, Escape towers, heat shields
 
 
|-
 
|-
! Decals
+
| sound_parachute_single ||
| 4
 
| No use yet.
 
 
|-
 
|-
! Crew
+
|}  
| 5
 
| No use yet.
 
|}
 
  
;subcategory
+
=== Editor Parameters ===
:No use yet. Set it to 0
+
{|class="wikitable"
 +
|-
 +
! Actual Part !! Definition
 +
|-
 +
| CrewCapacity || The number of Kerbals that can be seated in this part.  Mk1 Command Pod seats 1.  Jebediah is so awesome, he only takes up .7 seats.  Chuck Norris takes as many seats as he wants.  Use 0 to specify a probe.
 +
|-
 +
| TechRequired ||
 +
This is the technology tree node that must be activated in order to have access to this part.  Any single word can go here, but if you use a word that is not in the tech tree definition, you may never be able to access your part. Currently, stock KSP comes with the following [[ Technology_tree]] nodes:
  
;title
+
* start
:What do you want your part to be called in the rocket editor?
+
* basicRocketry
 +
* engineering101
 +
* generalRocketry
 +
* stability
 +
* survivability
 +
* advRocketry
 +
* generalConstruction
 +
* flightControl
 +
* scienceTech
 +
* heavyRocketry
 +
* fuelSystems
 +
* advConstruction
 +
* aerodynamicSystems
 +
* advFlightControl
 +
* electrics
 +
* spaceExploration
 +
* landing
 +
* heavierRocketry
 +
* specializedConstruction
 +
* actuators
 +
* supersonicFlight
 +
* specializedControl
 +
* precisionEngineering
 +
* advElectrics
 +
* advExploration
 +
* advLanding
 +
* nuclearPropulsion
 +
* advMetalworks
 +
* composites
 +
* advAerodynamics
 +
* highAltitudeFlight
 +
* largeControl
 +
* unmannedTech
 +
* ionPropulsion
 +
* largeElectrics
 +
* electronics
 +
* fieldScience
 +
* veryHeavyRocketry
 +
* metaMaterials
 +
* heavyAerodynamics
 +
* hypersonicFlight
 +
* advUnmanned
 +
* specializedElectrics
 +
* advScienceTech
 +
* advancedMotors
 +
The following Tech Tree nodes are present in stock, but not used unless called for by a mod.
 +
* nanolathing
 +
* experimentalMotors
 +
The following Tech makes a part unresearchable and unbuildable but does it not remove from existing ships
 +
* Unresearcheable
 +
|-
 +
| entryCost || entryCost represents the amount of [[Funds]] required to unlock this particular part.  As such, it could be considered an 'investment' cost in the development.  First you have to have the brains to make the thing, then someone has to develop it (that's this cost), then you can get it into production (that's cost, coming later).  You can set this to any value you like.  Bear in mind that this value has no meaning in Sandbox or Science Modes.  It is only used in Career Mode.
 +
|-
 +
| cost || cost represents the cost in [[Funds]] to attach a single instance of this part to your craft.  It represents the "wet cost", assuming all resources are at their full amount.  '''This is different from mass, which is the dry mass.''' Cost has no use in Sandbox or Science modes, it is only used in Career mode
 +
|-
 +
| category || Mods are organized alphabetically according to their sub-directory in parts, and then according to this value.  This is why, when you add a mod that is contained in folder "000_NewMod", it's parts appear first and when you add a mod that is contained in "ZZZ_NewMod", it's parts appear last.  Currently there are nine useable categories:
  
;manufacturer
+
* Command
:Who built your part?
+
* Propulsion (deprecated, but still useable)  
 
+
* FuelTank
;description
+
* Engine
:Describe your part here. (Do not use linebreaks. KSP breaks lines automatically in the part's tooltip. A linebreak will cause your description to appear truncated)
+
* Aero
 
+
* Electrical
And that's that. Updating the dummy cfg file now:
+
* Structural
 
+
* Utility
<pre>
+
* Wheel
// Kerbal Space Program - Part CFG file
+
|-  
// Mark V Rocket Engine
+
| subcategory || subcategory is not currently in use as of [0.90]. It is expected that this control will later be linked to [category] to provide a further subdivision of searchable parts in-game, possibly to cut down on clutter when the parts list gets exceptionally high. With certain mods installed, the Propulsion category already spans several pages. [subcategory] can help control this by provided variants such as [liquidEngine], [LOXfueltank], [SRB], etc
 
+
|-
// --- General Parameters ---
+
| title || title is the in-game name for your part and features such iconic names as 'Command Pod Mk1'.  The title of your part can be as long or short as you want, and there are no known limitations on what can be used in the title.  This is how your part will be known in-game, on in-game contextual menus and referred to on message boards and forums (hopefully) so take that into consideration.
name = LiquidThrusterV
+
|-
module = LiquidEngine
+
| manufacturer || manufacturer is flavor text (possibly useful in future iterations as a filter for parts) that defines who built or created the part for use (or pulled out of the junk-pile and sold at 10000% mark-up for you to use). Just as with the title of your part, there are no known restrictions on the flavor text, including length. This is KSP, though, so try to be humorous
author = YourName
+
|-
 
+
| description || description is the flavor text that describes your parts purpose, motivation, direction, life aspirations, goals, favor colors, and (hopefully) what it can (is supposed to) do. As with other flavor text, there are no known limitations on what can go here, including length. In fact, this flavor text is treated special in-game by being given a text box that automatically scrolls based on the length of the description used. If your part does something unusual, it's probably a good idea to (at least partially) document it here, so people know how to use your part in-game.  Many are the parts that have failed their popularity exams because of bad descriptions.  
// --- Asset Parameters ---
+
|}
mesh = myMesh.dae
 
scale = 0.1
 
texture = awesometexture.png
 
specPower = 0.5
 
rimFalloff = 3
 
alphaCutoff = 0
 
 
 
// --- Node Definitions ---
 
node_stack_bottom = 0.0, -3.5, 0.0, 0.0, 1.0, 0.0, 1.0
 
 
 
*'''// --- FX Definitions ---
 
fx_exhaustFlame_blue = 0.0, -10.0, 0.0, 0.0, 1.0, 0.0, active
 
fx_exhaustLight_blue = 0.0, -10.0, 0.0, 0.0, 0.0, 1.0, active
 
 
 
// --- Sound FX definition ---
 
sound_vent_medium = activate
 
sound_rocket_hard = active
 
sound_vent_soft = deactivate
 
 
 
// --- editor parameters ---
 
cost = 120
 
category = 0
 
subcategory = 0
 
title = Mark V Rocket Engine
 
manufacturer = Awesomely Terrible Spaceship Engines Inc.
 
description = This part will now get you to space with 60% less limb loss than the mark IV engine.
 
</pre>
 
 
 
== Attachment rules: ==
 
  
This defines how your part attaches to other parts.  
+
=== Attachment rules ===
 +
attachRules defines how this part attaches to or allows attachments from other parts.  Though documented in some part files, the documentation is minimalist and difficult to understand, so here's a little clean-up and expansion.  
  
 
*// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
 
*// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
 
*attachRules = 1,1,1,1,1
 
*attachRules = 1,1,1,1,1
  
The rules correspond to the numbers below - one is allow, 0 is prevent. The tags are:
+
The rules correspond to the numbers below - 1 is allow, 0 is prevent. The tags are:
  
 
'''stack''' - Can your part be stacked on others?
 
'''stack''' - Can your part be stacked on others?
Line 566: Line 405:
  
  
Easy enough, right? Adding to dummy file and continuing.
 
  
*'''// Kerbal Space Program - Part CFG file'''
 
*'''// Mark V Rocket Engine'''
 
  
*'''// --- General Parameters ---'''
+
=== Standard Part Parameters ===
*'''name = LiquidThrusterV'''
+
This defines how your part performs in the air and its limits. Note that not all of these parameters need to be defined. If they're left out of the cfg file, KSP will use a default value for them.  Standard part parameters indicate how the part interacts with the environment in flight mode.  From mounting on the launch platform or the runway through take-off and atmospheric interactions to landing and blowing up, this is where physics enters the game
*'''module = LiquidEngine'''
 
*'''author = YourName'''
 
  
*'''// --- Asset Parameters ---'''
+
{|class="wikitable"
*'''mesh = myMesh.dae'''
+
|-
*'''scale = 0.1'''  
+
! Actual Part !! Definition
*'''texture = awesometexture.png'''
+
|-
*'''specPower = 0.5'''
+
| mass = 1 || mass measured in Kerbal tons, describes the 'weight' of your part and is used in calculations involving roll, pitch, yaw, and thrust.  The higher the mass, the more energy will be needed to change any of those four parameters.  It is also used in making center-of-mass, center-of-lift and center-of-drag calculations, some of which are critical for aerodynamic flight.  This is a numerical value, and you can use any positive value.  Bear in mind that extremely high positive values for [mass] may make the part unusable in-game or require additional special parts to make usable.  This is generally considered poor design.  It represents the "dry mass" when all resources are empty.  '''This is different from cost, which is the wet cost.'''
*'''rimFalloff = 3'''  
+
|-
*'''alphaCutoff = 0'''
+
| dragModelType || [dragModelType] describes how your part interacts with drag forces. At present, the known [dragModelType]s include:
 +
*default
 +
|-
 +
| maximum_drag || (could use clarification) The maximum drag coefficient of the part (usually under between 0.2 and 0.3 and < 1). Generally drag when part's direction of travel is along its y-axis.
 +
|-
 +
| minimum_drag || (could use clarification) The minimum drag coefficient of the part (usually under between 0.2 and 0.3 and < 1 and lower than maximum_drag). This value is unused if dragModelType is set to default. Generally drag when the part's direction of travel is perpendicular to its y-axis.
 +
|-
 +
| angularDrag || (could use clarification) how much angular drag is there/resistance to turning? (Also usually under 1.)
 +
|-
 +
| crashTolerance || crashTolerance describes the maximum velocity (in m/s) at which your part can interact with another part without suffering damage (read: blowing up).  The higher you set this value, the faster an impact your part can survive.  12 is fairly high, and is the de facto standard for most pods.  14 is useful for landing legs, and 50 is used on some wheels, which are basically indestructible.
 +
|-
 +
| BreakingForce ||
 +
optional [breakingForce] specifies an amount of Force exerted between this part and another part that it is attached to.  When exceeded, the two parts will separate (usually catastrophically).  Higher values indicate stronger connections.
 +
|-
 +
| BreakingTorque || optional.  Like [breakingForce], [breakingTorque] defines an amount of Force between two parts, but rather than direct force towards or against, [breakingTorque] refers to rotational forces between the two objects.  It assigns a value that, again, when exceeded, will cause the two parts to separate, with the expected results
 +
|-
 +
| maxTemp || Stock KSP uses the [maxTemp] value to determine at what temperature parts will blow up due to overheating. As of Version 1.1, heat sources include Kerbin's sun, re-entry and aerodynamic heating, and engine exhaust. KSP's uses Kelvin as its temperature scale. Once this value is exceeded, your part will spontaneously explode. Managing heat with engines is a critical function of launching higher-powered engines, and design considerations mean that you shouldn't place parts with low [maxTemp] values directly in the path of engine exhaust. ~1800 is a good value for most engine assemblies.
 +
|-
 +
| ActivatesEvenIfDisconnected || true or false, assumed to specify whether the part will operate when not connected to a vessel (remote control?)  Must test.  Currently, only know part is the Sepratron I
 +
|-
 +
| stagingIcon || Sets the icon in the staging system
 +
* DECOUPLER_HOR  (Radial Decoupler Icon)
 +
* LIQUID_ENGINE  (Liquid Engines, or engines that have controllable thrust)
 +
* SOLID_BOOSTER  (Solid Rocket Boosters, or engines without controllable thrust)
 +
* RCS_MODULE    (Small 4-Way RCS Block Icon)
 +
* FUEL_TANK      (Red Fuel Tank Icon)
 +
* COMMAND_POD    (Generic Command Pod Icon)
 +
* DECOUPLER_VERT (Vertical Decoupler)
 +
* (?)
 +
*
 +
|-
 +
| stageOffset || Can be 0, 1, etc. defines whether this part will create a new stage before itself.  This only applies for the automatically generated staging sequence. -1 is used in parachutes...signals that activation of this object does not cause a staging effect?
 +
|-
 +
| childStageOffset || Can be 0, 1, etc. defines whether this part will create a new stage after itself.  This only applies for the automatically generated staging sequence.
 +
|-
 +
| explosionPotential || unknown purpose.  Possibly for future use for random failures.  Known values are numerical.
 +
* 0.1
 +
* 0 (BSLsnakprobe)
 +
|-
 +
| fuelCrossFeed || Will the part crossfeed fuel between parts attached to it?  allows or restricts fuel moving through this part.  Boolean argument:  True or False
 +
|-
 +
| NoCrossFeedNodeKey = bottom || if set to bottom will keep fuel from flowing FROM bottom nodes (avoiding some stack imbalances). Used with parts with multiple bottom nodes, such as the [[TVR-1180C Mk1 Stack Tri-Coupler]].  keeps resources from flowing FROM the named nodes (prevents stack imbalances and such) Use with fuelCrossFeed true to to allow resources to flow into these parts, but not back out.  Known parameters:  bottom
 +
|-
 +
| linearStrength || The amount of stress the given part can sustain without breaking, in a straight back-and-forth direction.  Used for fuel lines and strut connectors.
 +
|-
 +
| angularStrength || The amount of stress the given part can sustain without breaking, laterally.  Used for fuel lines and strut connectors
 +
|-
 +
| maxLength || The maximum possible length of this stretchy part, expressed in meters.  Used for fuel lines and strut connectors, as they have repeating meshes
 +
|-
 +
| vesselType || unknown.  May automatically set the Ship Type variable when including parts with a defined [vesselType].  Known [vesselTypes] include:
 +
* Ship
 +
* Probe
 +
* Lander
 +
* Rover
 +
* SpaceObject (refers only to PotatoRoids)
 +
|-
 +
| PhysicsSignificance || optional.  unknown purpose.  assumed to default to zero.  Appears to be a numerical value.  Many parts are 'physicsless' Known parts:
 +
* radialFlatSolarPanel
 +
* ladderRadial
 +
* z-400Battery
 +
* z-100Battery
 +
Known Values: 1
 +
|-
 +
|}
  
*'''// --- Node Definitions ---'''
+
=== MODULES ===
*'''node_stack_bottom = 0.0, -3.5, 0.0, 0.0, 1.0, 0.0, 1.0'''
 
  
*'''// --- FX Definitions ---
+
Each Configuration file is composed of several sections. Some of these sections are standardized across all parts, others are specific to specific part types. To build or modify a successful part, it is necessary to have an understanding of what each section does, and within those sections what each line of configuration actually does, and what the options are for those lines. This Definitions file will attempt to address each of those questions in turn and is current as of [0.25.0]
*'''fx_exhaustFlame_blue = 0.0, -10.0, 0.0, 0.0, 1.0, 0.0, active'''
 
*'''fx_exhaustLight_blue = 0.0, -10.0, 0.0, 0.0, 0.0, 1.0, active'''
 
  
*'''// --- Sound FX definition ---'''
 
*'''sound_vent_medium = activate'''
 
*'''sound_rocket_hard = active'''
 
*'''sound_vent_soft = deactivate'''
 
  
*'''// --- editor parameters ---'''
+
Notes:  It appears that, with a few exceptions, all definitions can occur in any order in the PART file. Free arrangement is valid for MODEL {}, INTERNAL {}, [[ Module | MODULE ]] {},
*'''cost = 120'''
 
*'''category = 0'''
 
*'''subcategory = 0'''
 
*'''title = Mark V Rocket Engine'''
 
*'''manufacturer = Awesomely Terrible Spaceship Engines Inc.'''
 
*'''description = This part will now get you to space with 60% less limb loss than the mark IV engine.'''
 
  
*'''// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision'''
 
*'''attachRules = 1,1,1,1,0'''
 
  
== Standard Part Parameters: ==
+
<span id="MODULES"></span>
  
This defines how your part performs in the air and it's limits. Note that not all of these parameters need to be defined. If they're left out of the cfg file, KSP will use a default value for them.
 
  
*mass =
+
[[ Module| MODULE]]s define what specific parts can do.  They are generally calls to C-coded or hard-coded functions that define what functionality these parts have in-game. 
*dragModelType = default
 
*maximum_drag =
 
*minimum_drag =
 
*angularDrag =
 
*crashTolerance =
 
*breakingForce =
 
*breakingTorque =
 
*maxTemp =
 
*heatConductivity =
 
*heatDissipation =
 
*stageBefore =
 
*stageAfter =
 
  
'''mass''' - How much does your part weigh? (Or, for parts that also specify a dryMass parameter, how much does it weigh when full?)
+
'''name'''  
 +
names define the module in use and are a general indication of what the module subtype does.  Specific variables are associated with each [[ Module| MODULE]].[name].  For example, the Clamp-O-Tron Docking Port Sr. has the [[ Module| MODULE]].name ModuleDockingNode and its' associates variables are [referenceAttachNode] and [nodeType].  Some [[ Module| MODULE]]s share variables with other [[ Module| MODULE]]s, which can make deciphering their purpose difficult.
  
'''dragModelType''' - Leave this as default.
+
known [[ Module| MODULE]]s, their associated variables, and the meanings of those variables will be explained below.
  
'''maximum_drag''' - What's the maximum amount of drag on your part? (Usually under 1.)
+
{|class="wikitable"
 +
|-
 +
! [[ Module | MODULE ]] Name !! [[ Module | MODULE ]] Function !! From Modification
 +
|-
 +
| [[ Module#ModuleCargoBay| ModuleCargoBay]] || Cargo bays || Stock
 +
|-
 +
| [[ Module#ModuleParachute | ModuleParachute ]] || Parachute Operations || Stock
 +
|-
 +
| [[ Module#ModuleSAS | ModuleSAS ]] || Control System || Stock
 +
|-
 +
| [[ Module#KerbalSeat | KerbalSeat ]] || Internal Seating? || Stock
 +
|-
 +
| [[ Module#ModuleLandingGear | ModuleLandingGear]] || One type of Wheel || Stock
 +
|-
 +
| [[ Module#ModuleSteering | ModuleSteering ]] || For Wheel Operations || Stock
 +
|-
 +
| [[ Module#FXModuleConstraingPosition | FXModuleConstraingPosition ]] || Unsure || Stock
 +
|-
 +
| [[ Module#ModuleLandingLeg | ModuleLandingLeg ]] || For Landing Legs || Stock
 +
|-
 +
| [[ Module#RetractableLadder | RetractableLadder ]] || For Collapsible Ladders || Stock
 +
|-
 +
| [[ Module#ModuleReactionWheel | ModuleReactionWheel ]] || Controls Force of Reaction wheels || Stock
 +
|-
 +
| [[ Module#ModuleScienceContainer | ModuleScienceContainer ]] || Place to store Science || Stock
 +
|-
 +
| [[ Module#FlagDecal | FlagDecal ]] || Flag Decorations on Parts || Stock
 +
|-
 +
| [[ Module#ModuleScienceLab | ModuleScienceLab ]] || For Science generators || Stock
 +
|-
 +
| [[ Module#ModuleJettison | ModuleJettison ]] || Fairing removal || Stock
 +
|-
 +
| [[ Module#ModuleAlternator | ModuleAlternator ]] || For producing resources based on thrust || Stock
 +
|-
 +
| [[ Module#ModuleCommand | ModuleCommand ]] || For Control || Stock
 +
|-
 +
| [[ Module#ModuleEnviroSensor | ModuleEnviroSensor ]] || Unmanned Science || Stock
 +
|-
 +
| [[ Module#ModuleControlSurface | ModuleControlSurface ]] || Control Surfaces, aelirons || Stock
 +
|-
 +
| [[ Module#ModuleAnimateHeat | ModuleAnimateHeat ]] || Animation to be played based on heat || Stock
 +
|-
 +
| [[ Module#Module Engines | Module Engines ]] || Engines and Thrust (somewhat deprecated) || Stock
 +
|-
 +
| [[ Module#FXModuleAnimateThrottle | FXModuleAnimateThrottle ]] || Animation to be played based on throttle level || Stock
 +
|-
 +
| [[ Module#ModuleEnginesFX | ModuleEnginesFX ]] || Engines and Thrust (use this in place of Module Engines) || Stock
 +
|-
 +
| [[ Module#ModuleGimbal | ModuleGimbal ]] || Engine Directionality || Stock
 +
|-
 +
| [[ Module#ModuleTestSubject | ModuleTestSubject ]] || Contract System || Stock
 +
|-
 +
| [[ Module#LaunchClamp | LaunchClamp ]] || Launch Clamps || Stock
 +
|-
 +
| [[ Module#ModuleDockingNode | ModuleDockingNode ]] || Docking Ports || Stock
 +
|-
 +
| [[ Module#ModuleRCS | ModuleRCS ]] || Reaction Control Systems || Stock
 +
|-
 +
| [[ Module#ModuleResourceHarvester | ModuleResourceHarvester ]] || Harvests resources from the environment || Stock
 +
|-
 +
| [[ Module#ModuleResourceIntake | ModuleResourceIntake ]] || Intakes that produce resources || Stock
 +
|-
 +
| [[ Module#ModuleScienceExperiment | ModuleScienceExperiment ]] || Controlling Experiments || Stock
 +
|-
 +
| [[ Module#ModuleGrappleNode | ModuleGrappleNode ]] || For [[Advanced Grabbing Unit|the Klaw]] || Stock
 +
|-
 +
| [[ Module#ModuleLight | ModuleLight ]] || For external lighting || Stock
 +
|-
 +
| [[ Module#ModuleAnimateGeneric | ModuleAnimateGeneric ]] || Generic Animation Calls || Stock
 +
|-
 +
| [[ Module#ModuleDataTransmitter | ModuleDataTransmitter ]] || For transmitting antennas || Stock
 +
|-
 +
| [[ Module#FXModuleLockAtConstraint | FXModuleLockAtConstraint ]] || Uncertain || Stock
 +
|-
 +
| [[ Module#ModuleAsteroid | ModuleAsteroid ]] || Unsure || Stock
 +
|-
 +
| [[ Module#ModuleDeployableSolarPanel | ModuleDeployableSolarPanel ]] || For unfoldable solar panels || Stock
 +
|-
 +
| [[ Module#ModuleWheel | ModuleWheel ]] || For wheels, powered or unpowered || Stock
 +
|-
 +
| [[ Module#FXModuleLookAtConstraint | FXModuleLookAtConstraint ]] || Unknown || Stock
 +
|-
 +
| [[ Module#FXModuleConstrainPosition | FXModuleConstrainPosition ]] || Unknown || Stock
 +
|-
 +
| [[ Module#ModuleAnchoredDecoupler | ModuleAnchoredDecoupler ]] || Decouplers1 || Stock
 +
|-
 +
| [[ Module#ModuleDecouple | ModuleDecouple ]] || Decoupling Operations || Stock
 +
|-
 +
| [[ Module#KASModuleContainer | KASModuleContainer ]] || Containers || KAS / Kerbal Assembly System
 +
|-
 +
| [[ Module#KASModuleGrab |KASModuleGrab ]] || || KAS / Kerbal Assembly System
 +
|-
 +
| [[ Module#KASModuleStrut |KASModuleStrut ]] || || KAS / Kerbal Assembly System
 +
|-
 +
| [[ Module#SCANset |SCANset ]] || || SCANsat
 +
|-
 +
| [[ Module#TweakScale |TweakScale ]] || Changing the size of parts || TweakScale
 +
|-
 +
| [[ Module#MechJebCore |MechJebCore  ]] || Automated ship controls and advanced information systems || MechJeb
 +
|-
 +
| [[ Module#ModuleConnectedLivingSpace |ModuleConnectedLivingSpace ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#KolonyConverter |KolonyConverter ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#MKSModule |MKSModule ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ExWorkshop |ExWorkshop ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#KarboniteAtmoExtractor |KarboniteAtmoExtractor ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#KarboniteDrill |KarboniteDrill ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#KarboniteGenerator |KarboniteGenerator ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#KarboniteParticleExtractor |KarboniteParticleExtractor  ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#KarboniteConverter |KarboniteConverter ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#USI_Converter |USI_Converter  ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#USIAnimation |USIAnimation ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#USI_BaseAnchor |USI_BaseAnchor  ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#USI_InertialDampener |USI_InertialDampener  ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ProxyLogistics |ProxyLogistics ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#FSanimateGeneric |FSanimateGeneric ]] || || Firespitter
 +
|-
 +
| [[ Module#FStextureSwitch2 |FStextureSwitch2 ]] || || Firespitter
 +
|-
 +
| [[ Module#FSfuelSwitch |FSfuelSwitch ]] || || Firespitter
 +
|-
 +
| [[ Module#MKSLcentral |MKSLcentral ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ORSModuleAirScoop |ORSModuleAirScoop ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ORSModuleAirIntake |ORSModuleAirIntake ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ORSResourceScanner |ORSResourceScanner ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ORSModuleRailsExtraction |ORSModuleRailsExtraction ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ORSModuleParticleCollector |ORSModuleParticleCollector ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ORSAnimatedScanner |ORSAnimatedScanner ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ORSAnimatedExtractor |ORSAnimatedExtractor ]] || || MKS/OKS / Modular Kolonization System
 +
|-
 +
| [[ Module#ModuleSPU |ModuleSPU ]] || || Remote Tech
 +
|-
 +
| [[ Module#ModuleRTAntennaPassive |ModuleRTAntennaPassive ]] || || Remote Tech
 +
|-
 +
| [[ Module#FSplanePropellerSpinner |FSplanePropellerSpinner ]] || || Firespitter
 +
|-
 +
| [[ Module#FSengineSounds |FSengineSounds ]] || || FSengineSounds
 +
|-
 +
|}
  
'''minimum_drag''' - The minimum amount of drag your part will encounter. (Usually under 1 and lower than maximum_drag) (this value is unused if dragModelType is set to default)
+
=== INTERNAL ===
 +
Internal specifies the internal files used to construct views from the IVA or internal vehicular activity, and are referenced out to the \Spaces\ directory of the relevant part mod. (Squad's internals are in \GameData\Squad\Spaces).  INTERNALs have their own .cfg files with their own calls and methods that will not be discussed here. Squad provides 9 INTERNALs as part of Stock KSP:
  
'''angularDrag''' - how much angular drag is there? (Also usually under 1.)
+
* crewCabinInternals
 +
* cupolaInternal
 +
* GenericSpace1
 +
* GenericSpace3
 +
* landerCabinInternals
 +
* landerCabinSmallInternal
 +
* mk1CockpitInternal
 +
* mk1PodCockpit
 +
* PodCockpit
  
'''crashTolerance''' - How good is your part at surviving crashes? The higher the number the more durable. Numbers are approximately maximum impact speed in m/s.
+
=== RESOURCE ===
 +
In parts files, [RESOURCE] refers to a resource that is stored by a part.  Each stored resource must be separately defined by a [RESOURCE] call.  Any resource may be stored, including those not defined. The examples in the table below comes from a [[Z-100 Rechargable Battery Pack|battery]] config.
 +
{|class="wikitable"
 +
|-
 +
! variable !! example !! explanation
 +
|-
 +
| name || ElectricCharge || Name of the resource being stored.
 +
|-
 +
| amount || 100 || Amount of the resource included when dragged out of the parts list.
 +
|-
 +
| maxAmount || 100 || Maximum amount of the resource that can be stored
 +
|-
 +
| isTweakable || false || Allows/prevents modification of resource levels in editor.
 +
|-
 +
| hideFlow || true || Allows/prevents display of motion of resource transfer. Not sure why this would be important.
 +
|}
  
'''breakingForce''' - How much will the attachment between this part and the part it's connected to resist to linear forces?
+
=== EFFECTS ===
 +
{|class="wikitable"
 +
|-
 +
!variable ||explanation
 +
|-
 +
|| clip || specifies the location of an audio clip to play during the specified thrust effect.
 +
|-
 +
|| volume ||
 +
??  2-part array, used twice, once to specify a minimum volume, once to specify a maximum volume, relative to the game's volume settings
 +
|-
 +
|| pitch ||
 +
?? 2-part array, used twice, once to specify a minimum volume, once to specify a maximum volume, relative to the game's volume settings
 +
|-
 +
|| loop ||
 +
boolean, true or false, specifies whether to play the sound once, or to keep playing the sound as long as the specified effect is in operation
 +
|}
  
'''breakingTorque''' - How much will the attachment resist rotational forces?
+
== Resource Configuration Files ==
 +
Resources are massively modifiable, but Stock KSP only comes with a few, and these are contained in squad/resources/ResourcesGeneric.cfg.  Be extremely careful when modifying ResourcesGeneric.cfg, as it could have unintended side effects for your rockets.  Resource definitions follow these conventions:
  
'''maxTemp''' - The maximum temperature your part can experience before exploding.
+
{|class="wikitable"
 +
|-
 +
! variable !! example !! explanation
 +
|-
 +
| name ||
 +
{|class="wikitable"
 +
! Resource !! Mod
 +
|-
 +
| LiquidFuel || Stock
 +
|-
 +
| Oxidizer || Stock
 +
|-
 +
| SolidFuel || Stock
 +
|-
 +
| MonoPropellant || Stock
 +
|-
 +
| XenonGas || Stock
 +
|-
 +
| ElectricCharge || Stock
 +
|-
 +
| IntakeAir || Stock
 +
|-
 +
| EVA Propellant || Stock
 +
|-
 +
| MechanicalParts || MKS/OKS
 +
|-
 +
| Recyclables || MKS/OKS
 +
|-
 +
| ElectronicParts || MKS/OKS
 +
|-
 +
| PlasticParts || MKS/OKS
 +
|-
 +
| ModularParts || MKS/OKS
 +
|-
 +
| ReplacementParts || MKS/OKS
 +
|-
 +
| RepairKits || MKS/OKS
 +
|-
 +
| PatchKits || MKS/OKS
 +
|-
 +
| Computers || MKS/OKS
 +
|-
 +
| Robotics || MKS/OKS
 +
|-
 +
| ExoticMinerals || MKS/OKS
 +
|-
 +
| RareMetals || MKS/OKS
 +
|-
 +
| Chemicals || MKS/OKS
 +
|-
 +
| Polymers || MKS/OKS
 +
|-
 +
| SpecMachinery || MKS/OKS
 +
|-
 +
| AdvMachinery || MKS/OKS
 +
|-
 +
| BasicMachinery || MKS/OKS
 +
|-
 +
| PunchCards || MKS/OKS
 +
|-
 +
| Compost || MKS/OKS
 +
|-
 +
| MEP-Manufacturing || MKS/OKS
 +
|-
 +
| MEP-Laboratory || MKS/OKS
 +
|-
 +
| MEP-Refining || MKS/OKS
 +
|-
 +
| MEP-Mining || MKS/OKS
 +
|-
 +
| MEP-Environmental || MKS/OKS
 +
|-
 +
| MEP-Computing || MKS/OKS
 +
|-
 +
|}
 +
|| This is the name of the resource.  Like the name of your part, it is restricted to one word with no spaces or underscores.  This is how the resource is referred to in-game.
 +
|-
 +
| Display Name || Liquid Fuel || Display name for UI elements, can have spaces.
 +
|-
 +
| Abbreviation || LF || For KerbNet resource switcher button. Two characters at best, like in the Periodic Table. Only important for things that are drilled up.
 +
|-
 +
| density || 0.005 || [density] is a numerical value between 0 and 1 used in calculations involving mass, storage capacity and units.  Lower values mean lower densities, meaning you can get more units in a smaller space.
 +
|-
 +
| unitCost || 0.8 || [unitCost] defines the amount of Kerbits of value for each unit of the specified resource.  Any number will do.  Positive values indicate that you pay for the resource.  Negative values have not been tested (yet), but it is assumed that negative values mean others will pay you to get rid of this resource.  (Nuclear waste disposal, anyone?) 
 +
|-
 +
| hsp || 2010 || Specific Heat, how much energy in joules per kelvin needed to raise the temperature of 1kg of resource by 1 deg Kelvin. High numbers make it great as a thermal control substance.
 +
|-
 +
| flowMode ||
 +
* STACK_PRIORITY_SEARCH
 +
* NO_FLOW
 +
* STAGE_PRIORITY_FLOW
 +
* ALL_VESSEL
 +
|| [flowMode] defines how the resource moves throughout your vessel whenever the resource is requested by a particular part. There are 4 known methods of flow mode:
 +
|-
 +
| transfer ||
 +
* PUMP
 +
* NONE
 +
|| [transfer] is an optional method which specifies how and whether or not a resource may be manually transferred from one location on a vessel to another.  There are two known methods of [transfer]:
 +
|-
 +
| isTweakable ||
 +
* true
 +
* false
 +
|| [isTweakable] is an optional, boolean method which specifies whether or not a resource may be assigned during construction.  Defaults to true.  The only accepted arguments are true and false.
 +
|-
 +
| isVisible ||
 +
* true
 +
* false
 +
|| boolean, Is the gauge for this even ever visible (resource panel in flight and in VAB)? Overrides isTweakable. Almost every resource has this true.
 +
|-
 +
| volume ||
 +
1
 +
|| Standard value is 1. How many litres of space a unit of this occupies. Affects tankage in volume sensitive storage systems like KIS and B9 Part Switch.
 +
|}
  
'''heatConductivity''' - How good is your part at conducting heat? Defaults to 0.08, CFG values are used in 0.13.3, but not in 0.15.2.
+
== Science Definitions Configuration Files ==
 +
{|class="wikitable"
 +
|-
 +
! variable !! example !! explanation
 +
|-
 +
| id || crewReport || internal name of the experiment in question
 +
|-
 +
| title || Crew Report || Flavor text of the experiment
 +
|-
 +
| baseValue || 5 || Base science value of the experiment
 +
|-
 +
| scienceCap || 5 || Max? value of the experiment, before multipliers
 +
|-
 +
| dataScale || 1 || Multiplier used in calculations
 +
|-
 +
| requireAtmosphere ||
 +
* True
 +
* False
 +
|| specifies whether this experiment must be conducted inside an atmosphere
 +
|-
 +
| situationMask || 63 || uses the sum of the situation bits to determine where the experiment can be conducted:
 +
* SrfLanded = 1,
 +
* SrfSplashed = 2,
 +
* FlyingLow = 4,
 +
* FlyingHigh = 8,
 +
* InSpaceLow = 16,
 +
* InSpaceHigh = 32
 +
|-
 +
| biomeMask || 7 || uses the same pattern as situationMask to determine whether experiment will give different result for different biomes. i.e. 7 = 1 + 2 + 4 so flying high will have only a single result per body but flying low (and landed or splashed) will give one result per biome
 +
|-
 +
| requiredExperimentLevel || 0.5 || specifies the level of research facility required before the experiment can be conducted
 +
|-
 +
| RESULTS ||
 +
{|class="wikitable"
 +
|-
 +
! name !! example !! definition
 +
|-
 +
| Too many to list!
 +
* default
 +
* MohoSrf
 +
|| You ran an Atmosphere Analysis, recording various measurements like temperature, pressure and atmosphere composition || Flavor text for the science popup window and science archives that describes what happened when the experiment was conducted.
 +
|-
 +
|}
 +
|| an array of data that provides flavor text for each scenario that the experiment is conducted in. Left side is a combination of the planet name and the situation bit.  No spaces. Right side is the flavor text provided to the GUI.
 +
|}
  
'''heatDissipation''' - How good is your part at dissipating heat from the ship? Defaults to 0.08, CFG values are used in 0.13.3, but not in 0.15.2.
+
== Contracts Definitions Configuration Files ==
 +
{|class="wikitable"
 +
Contains a single call to STORY_DEF, which then allows for subsets
 +
|-
 +
! variable !! example !! explanation
 +
|-
  
'''stageBefore''' and '''stageAfter''' - Can be True or False. defines whether this part will create a new stage before or after itself, or both (as do decouplers). This only applies for the automatically generated staging sequence.
+
|}
  
There you go, another section down.
+
== Contracts Configuration Files ==
  
Dummy CFG:
+
== Agent Configuration Files ==
 +
Agent configuration files specify specific Agents that may have an impact on the performance (read science, money, and prestige) awarded to your Kerbals for completion of specific tasks.  Also specifies agency relations to one another.  Many of these configurations are not implemented as of [0.90]
  
*'''// Kerbal Space Program - Part CFG file'''
+
<pre style="white-space: pre-wrap">
*'''// Mark V Rocket Engine'''
+
// Agency mentalities
 +
// * Commercial  [Increased financial stakes, both for success and failure]
 +
// * Competitive  [competes with companies which we have a negative standing towards, auto-added if any standings set][not impl]
 +
// * Conglomerate  []
 +
// * Startup  []
 +
// * Cooperative  [not impl]
 +
// * Ecomental  [not impl]
 +
// * Economic  []
 +
// * Hasty    [-deadlines -expiry +rep]
 +
// * Patient  []
 +
// * Industrial  [not impl]
 +
// * Perfectionist  [not impl]
 +
// * Pioneer  [Makes agency more likely to offer a contract to something that's never been done before]
 +
// * Record    [Flags agency as a record-keeping organization, focuses on contracts about breaking existing records and doing new things]
 +
// * Scientific  [Agency is more likely to offer science data gathering contracts][not impl]
 +
// * Stern    [Higher Reputation Stakes for both success and failure]
 +
// * EasyGoing  [Lower Reputation Stakes for both success and failure]
 +
// * Kerbalminded  [not impl][Sets up conditions against losing Kerbals]
 +
// * Moral          [not impl]
 +
// syntax guidelines
 +
//
 +
// standings = agent name string, float
 +
// mentality = MentalityClass [float]
 +
</pre>
  
*'''// --- General Parameters ---'''
 
*'''name = LiquidThrusterV'''
 
*'''module = LiquidEngine'''
 
*'''author = YourName'''
 
  
*'''// --- Asset Parameters ---'''
+
{|class="wikitable"
*'''mesh = myMesh.dae'''
+
! !! !! !!
*'''scale = 0.1'''
+
|-
*'''texture = awesometexture.png'''
+
|}
*'''specPower = 0.5'''
 
*'''rimFalloff = 3'''
 
*'''alphaCutoff = 0'''
 
  
*'''// --- Node Definitions ---'''
+
== Kerbal Configuration Files ==
*'''node_stack_bottom = 0.0, -3.5, 0.0, 0.0, 1.0, 0.0, 1.0'''
+
Defines what your Kerbals can do. Contained in the Traits.cfg file.
  
*'''// --- FX Definitions ---
+
{|class="wikitable"
*'''fx_exhaustFlame_blue = 0.0, -10.0, 0.0, 0.0, 1.0, 0.0, active'''
+
|-
*'''fx_exhaustLight_blue = 0.0, -10.0, 0.0, 0.0, 0.0, 1.0, active'''
+
! variable !! example !! definition !! in code
 +
|-
 +
| name ||
 +
* Pilot
 +
* Engineer
 +
* Scientist
 +
|| describes the Kerbal's job || <pre>name = Pilot</pre>
 +
|-
 +
| title || Any text || Flavor text of the job ||
 +
<pre> title = Engineer </pre>
 +
|-
 +
| desc || Any text || Flavor text of job description || <pre>desc = Pilots provide assistance in flying the vessel.</pre>
 +
|-
 +
| EFFECT { || Array of skills
 +
|| describes benefits to vessel for having a Kerbal with this job aboard
 +
||
 +
<pre> EFFECT
 +
{
 +
  name = VesselScienceReturn
 +
  modifiers = 1.05, 1.1, 1.15, 1.2, 1.25
 +
}
 +
EFFECT
 +
{
 +
  name = PartScienceReturn
 +
  modifiers = 1.05, 1.1, 1.15, 1.2, 1.25
 +
}
 +
</pre>
 +
|}
  
*'''// --- Sound FX definition ---'''
+
== Prop Configuration Files ==
*'''sound_vent_medium = activate'''
 
*'''sound_rocket_hard = active'''
 
*'''sound_vent_soft = deactivate'''
 
  
*'''// ---Editor parameters ---'''
+
Contained in several different files, usually labeled prop.cfg, in the /Props/ directory. Describes aspects of parts used on IVAs, included buttons, switches, dials, and screens.
*'''cost = 120'''
 
*'''category = 0'''
 
*'''subcategory = 0'''
 
*'''title = Mark V Rocket Engine'''
 
*'''manufacturer = Awesomely Terrible Spaceship Engines Inc.'''
 
*'''description = This part will now get you to space with 60% less limb loss than the mark IV engine.'''
 
  
*'''// --- Standard part parameters ---'''
+
<pre>
*'''mass = 1.5
+
PROP
*'''dragModelType = default
+
{
*'''maximum_drag = 0.4
+
  name = directionalKnob
*'''minimum_drag = 0.2
+
  MODULE
*'''angularDrag = 0.2
+
  {
*'''crashTolerance = 5
+
    name = internalGeneric
*'''maxTemp = 2500
+
  }
 +
}
 +
proxy = 0, 0, 0,  0.0225, 0.0075, 0.0225,  0, 1, 0
  
== Specific Part Parameters: ==
+
</pre>
 +
<pre>
 +
PROP
 +
{
 +
  name = RadarAltimeter
 +
  MODULE
 +
  {
 +
    name = InternalRadarAltitude
 +
    indicatorName = indicator
 +
    increments
 +
    {
 +
      inc = 0, 0
 +
      inc = 34, 100
 +
      inc = 70, 200
 +
      inc = 110, 300
 +
      inc = 145, 400
 +
      inc = 180, 500
 +
      inc = 215, 1000
 +
      inc = 232, 2000
 +
      inc = 250, 3000
 +
    }
 +
  }
 +
}
 +
proxy = 0, 0, 0,  0.06, 0.01, 0.06,  1.0, 0.5, 0
 +
</pre>
 +
<pre>
 +
PROP
 +
{
 +
  name = NavBall
 +
  MODULE
 +
  {
 +
    name = InternalNavBall
 +
    navBallName = NavSphere
 +
    iconUp = 0, 1, 0
 +
    progradeVectorName = progradeVector
 +
    retrogradeVectorName = retrogradeVector
 +
    progradeWaypointName = progradeWaypoint
 +
    retrogradeWaypointName = retrogradeWaypoint
 +
normalVectorName = NormalVector
 +
antiNormalVectorName = antiNormalVector
 +
radialInVectorName = RadialInVector
 +
radialOutVectorName = RadialOutVector
 +
maneuverArrowName = ManeuverArrow
 +
anchorName = Anchor
 +
  }
 +
}
 +
proxy = 0, 0, 0,  0.075, 0.01, 0.09,  1.0, 0.5, 0
 +
</pre>
 +
<pre>
 +
PROP
 +
{
 +
  name = switch
 +
  MODULE
 +
  {
 +
    name = internalGeneric
 +
  }
 +
}
 +
proxy = 0, 0, 0,  0.0225, 0.0075, 0.0225,  0, 1, 0
 +
</pre>
  
We're almost finished, a complete part is almost at our hands and you should know almost everything you need to create a part.cfg file. However, remember back when we were setting types? Well each type has an individual set of specific part parameters that change depending on what type of part it is.
+
== Internals Configuration Files ==
  
You cannot mix and match parameters from different module types - it doesn't work.
+
== Strategies Configuration Files ==
 +
Contained in Strategies.cfg, used to describe the variable strategies available.  Each strategy opens with STRATEGY {
  
These specific parameters are actually public variables defined in the Part classes themselves. The standard parameters are declared in the Part base class, and the specific ones in each Part extension (i.e., Modules)
+
{|class="wikitable"
 +
! variable !! samples !! description !! in code
 +
|-
 +
| name ||
 +
* AppreciationCampaignCfg
 +
* FundraisingCampaignCfg
 +
* OpenSourceTechProgramCfg
 +
* UnpaidResearchProgramCfg
 +
* OutsourcedResearchCfg
 +
* PatentsLicensingCfg
 +
* AgressiveNegotiations
 +
* RecoveryTransponders
 +
|| Internal Description of Campaign Name.  No spaces or special characters || <pre>name = AppreciationCampaignCfg</pre>
 +
|-
 +
| title || Recovery Transponder Fitting || Flavor text for the campaign name || <pre>title = Appreciation Campaign</pre>
 +
|-
 +
| desc || Recovering parts landed far away from the Space Center can be very costly, but I reckon we can reduce those costs by installing better transponders on the parts we launch. These units are not cheap, but they should make it much easier to find parts, improving the recovery value even if they're half-way around Kerbin. What do you say? || Flavor text for the description of the campaign || <pre>desc = We could definitely improve our
 +
image by putting some effort into reminding Kerbals
 +
everywhere of just how great the Space Program is.
 +
Advertisement space isn't free, however.</pre>
 +
|-
 +
| department ||
 +
* Operations
 +
* Finances
 +
* Science
 +
* Public Relations
 +
|| Specifies the Department that the strategy belongs to.  Can only be a department that already exists (as of [0.90] || <pre>department = Public Relations</pre>
 +
|-
 +
| icon || || specifies the icon image to be used in conjunction with the campaign. In the campaign selection. || <pre>icon = Squad/Strategies/Icons/AppreciationCampaign</pre>
 +
|-
 +
| groupTag ||
 +
* Basic,A
 +
* Basic,B
 +
* Basic,C
 +
* Misc,D
 +
* Misc,Recovery
  
For example, if your part type (module) was SolidRocket, your specific part parameters would be composed of:
+
|| Uncertain, clearly has something to do with grouping || <pre>groupTag = Basic,A</pre>
 +
|-
 +
| minLeastDuration || positive Integers || the minimum shortest amount of time (in days) that the campaign may have (campaigns must run at least this long) || <pre>minLeastDuration = 60</pre>
 +
|-
 +
| maxLeastDuration || positive Integers || the maximum shortest amount of time (in days) that the campaign may have.  Using the sliders, campaigns may be adjusted to require at least this long to run || <pre>maxLeastDuration = 100</pre>
 +
|-
 +
| minLongestDuration || positive Integers || the minimum longest duration (in days) of the campaign.  Using the sliders, campaigns may be adjusted to only run this long || <pre>minLongestDuration = 1200</pre>
 +
|-
 +
| maxLongestDuration || positive Integers || the maximum longest duration (in days) of the campaign (campaigns cannot run longer than this) || <pre>maxLongestDuration = 1600</pre>
 +
|-
 +
| requiredReputationMin || Integers || Minimum reputation required to purchase this campaign || <pre>requiredReputationMin = -500</pre>
 +
|-
 +
| requiredReputationMax || Integers || The most reputation you can be required to have in order to run this campaign || <pre>requiredReputationMax = 750</pre>
 +
|-
 +
| initialCostFundsMin || Integers || Minimum funds required to purchase this campaign || <pre>initialCostFundsMin = 8000.0</pre>
 +
|-
 +
| initialCostFundsMax || Integers || The largest amount of Kerbits that can be required to purchase this campaign || <pre>initialCostFundsMax = 160000.0</pre>
 +
|-
 +
| initialCostReputation || Integers || Minimum cost in reputation to run this campaign || <pre>initialCostReputation = 0.0</pre>
 +
|-
 +
| initialCostScience || Integers || Minimum cost is science points to run this campaign || <pre>initialCostScience = 0.0</pre>
 +
|-
 +
| hasFactorSlider ||
 +
* True
 +
* False
 +
|| Can the campaign be adjusted by increasing inputs and getting greater outputs out of the campaign? || <pre>hasFactorSlider = True</pre>
 +
|-
 +
| factorSliderDefault || Float || multiplication factor for each step along the slider bar|| <pre>factorSliderDefault = 0.05</pre>
 +
|-
 +
| factorSliderSteps || Numbers || number of steps/stages in the slider bar || <pre>factorSliderSteps = 20</pre>
 +
|-
 +
| EFFECT { || see table below || describes what the particular campaign actually does || see table below
 +
|}
  
*thrust = 130
+
=== EFFECTS ===
*dryMass = 0.36
+
There are currently three different EFFECT types available for use in Strategies:  CurrencyOperation, ValueModifier, and CurrencyConverter. Each one has different variables and are detailed below.
*heatProduction = 550
 
*fuelConsumption = 4
 
*internalFuel = 100
 
*fullExplosionPotential = 0.8
 
*emptyExplosionPotential = 0.1
 
*thrustCenter = 0, -0.5, 0
 
*thrustVector = 0, 1, 0
 
  
Time to go through and see what special parameters each module can have.
+
{|class="wikitable"
 +
CurrencyOperation
 +
! variable !! samples !! description !! in code
 +
|-
 +
| name ||
 +
* CurrencyOperation
 +
|| internal reference name || <pre>name = CurrencyConverter</pre>
 +
|-
 +
| currency ||
 +
* Funds
 +
|| input and output for campaign operations || <pre>currency = Funds</pre>
 +
|-
 +
| operation ||
 +
* Multiply
 +
* Add
 +
|| operation to perform on currency || <pre>operation = Multiply</pre>
 +
|-
 +
| effectDescription || "to Launch Costs" || Flavor text for the operation to be performed || <pre>effectDescription = to Launch Costs</pre>
 +
|-
 +
| minValue || Float || factor to use in operations || <pre>minValue = 1.1</pre>
 +
|-
 +
| maxValue || Float || factor to use in operations || <pre>maxValue = 1.06</pre>
 +
|-
 +
| AffectReasons ||
 +
* VesselRollout
 +
* RnDPartPurchase
 +
|| conditions that trigger the operation || <pre>AffectReasons = VesselRollout</pre>
 +
|}
  
=== Liquid Engine ===
+
{|class="wikitable"
 +
ValueModifier
 +
|-
 +
! variable !! samples !! description !! in code
 +
|-
 +
| name ||
 +
* ValueModifier
 +
|| internal reference name || <pre>name = CurrencyConverter</pre>
 +
|-
 +
| valueID || VesselRecoveryFactor || Value to be modified || <pre>valueId = VesselRecoveryFactor</pre>
 +
|-
 +
| minValue || Float || factor to use in operations || <pre>minValue = 1.1</pre>
 +
|-
 +
| maxValue || Float || factor to use in operations || <pre>maxValue = 1.06</pre>
 +
|}
  
A liquid engine has the following special parameters:
+
{|class="wikitable"
 +
CurrencyConverter
 +
|-
 +
! variable !! samples !! description !! in code
 +
|-
 +
| name ||
 +
* CurrencyConverter
 +
|| internal reference name || <pre>name = CurrencyConverter</pre>
 +
|-
 +
| input ||
 +
* Funds
 +
* Reputation
 +
* Science
  
*maxThrust =  
+
|| specifies the input for the campaign || <pre>input = Funds</pre>
*minThrust =
+
|-
*heatProduction =
+
| output ||
*fuelConsumption =
+
* Reputation
 +
* Funds
 +
* Science
  
Looks pretty easy, and everything is pretty much what you'd expect. By now, you should be able to work out what they all mean, but just in case:
+
|| specifies the outputs for the campaign || <pre>output = Reputation</pre>
 +
|-
 +
| minShare || Float || specifies the minimum || <pre>minShare = 0.0</pre>
 +
|-
 +
| maxShare || Float || specifies the maximum || <pre>maxShare = 1.0</pre>
 +
|-
 +
| minRate || Float || specifies the minimum rate of conversion, based on slider values || <pre>minRate = 0.041667</pre>
 +
|-
 +
| maxRate || Float || specifies the maximum rate of conversion, based on slider values || <pre>maxRate = 0.0520</pre>
 +
|-
 +
| AffectReasons ||
 +
* ContractReward
 +
* ScienceTransmission
 +
* ContractAdvance
 +
* VesselRecovery
 +
* VesselRollout
 +
* RnDPartPurchase
  
'''maxThrust''' - The maximum thrust of the liquid engine.
+
|| criteria for conversions || <pre>AffectReasons = ContractReward, ContractAdvance</pre>
 +
|-
 +
| effectDescription ||
 +
* gains
 +
* Income
 +
|| describes the type of return || <pre>effectDescription = Income</pre>
 +
|}
  
'''minThrust''' - The minimum thrust. Usually 0, unless you want a rocket that can't fully be turned off.
+
== Department Configuration Files ==
 +
Used in the Strategies system, these specify the Departments available that provide different strategies for use.
  
'''heatProduction''' - How much heat your rocket puts out.
+
{|class="wikitable"
 
+
|-
'''fuelConsumption''' - How much fuel your rocket uses.
+
! variable !! samples !! description !! in code
 
+
|-
=== Solid Rocket Booster ===
+
| name ||
 
+
* Finances
*thrust =
+
* Science
*dryMass =
+
* Public Relations
*heatProduction =
+
* Operations
*fuelConsumption =
+
|| The department name || <pre>name = Public Relations</pre>
*internalFuel =  
+
|-
 
+
| desc || Flavor Text || describes the department || <pre>
*fullExplosionPotential =
+
desc = Linus is Wernher Von Kerman's Intern.  
*emptyExplosionPotential =  
+
Because Wernher himself is too important to be  
 
+
bothered with these boring strategy meetings.  
*thrustCenter = x, y, z
+
He sends his intern in his stead.</pre>
*thrustVector = angx, angy, angz
+
|-
 
+
| color || array of 3 numbers between 0 and 255 || specifies the color of the department || <pre>color = 149 254 135</pre>
A lot of those values look pretty similar to the liquid engine parameters, right?
+
|-
 
+
| avatar ||
'''thrust''' - The thrust of the solid rocket booster. Note how there is no minimum thrust because it can not be turned off once lit.
+
* Strategy_MechanicGuy
 
+
* Strategy_PRGuy
'''dryMass''' - How much the SRB weighs when empty.
+
* Strategy_ScienceGuy
 
+
* Strategy_Mortimer
'''heatProduction''' - Exactly the same as the liquid rocket, how much heat your rocket puts up.
+
|| Internal name of the Department Head || <pre>avatar = Strategy_PRGuy</pre>
 
+
|-
'''fuelConsumption''' - How much fuel the rocket uses per second.
+
| headName ||
 
+
* Mortimer Kerman
'''internalFuel''' - How much fuel does the SRB hold inside it?
+
* Linus Kerman
 
+
* Walt Kerman
'''fullExplosionPotential''' - The potential for explosion when the rocket is full of fuel
+
* Gus Kerman
 
+
|| Flavor Text for the Department Head || <pre>headName = Walt Kerman</pre>
'''emptyExplosionPotential''' - And the potential when it's empty.
+
|-
 
+
| headImage ||
'''thrustCenter''' - Where the thrust comes from.
+
* MORTIMER_KERMAN
 
+
* SCIGUY_KERMAN
'''thrustVector''' - And which direction it goes.
+
* PRGUY_KERMAN
 
+
* PRGUY_KERMAN
=== Fuel Tank ===
+
|| animation file name for the Head shot of the Department Head featured in the strategy selection screen|| <pre>headImage = PRGUY_KERMAN</pre>
 
+
|}
Fuel tanks are a bit different, seeing as they have no thrust parameters.
 
 
 
*fuel =
 
*dryMass =
 
*fullExplosionPotential =
 
*emptyExplosionPotential =
 
 
 
If you've read above, you should know exactly what those parameters do, and so I won't explain them to you again.
 
 
 
=== SAS Module ===
 
 
 
*maxTorque =
 
 
 
'''maxTorque''' - The maximum amount of torque the module can apply to halt the ship's rotation.
 
 
 
'''Ki, Kd and Kp''' - These parameters allow for tuning of the internal workings of the SAS module. If you're not experienced in working with PID controllers, just leave them as they are.
 
 
 
=== Winglets ===
 
 
 
*dragCoeff =
 
*deflectionLiftCoeff =
 
 
 
'''dragCoeff''' - The drag co-efficiency of the wings.
 
 
 
'''deflectionLiftCoeff''' - How much lift the wings generate.
 
 
 
=== Control Surfaces ===
 
 
 
*dragCoeff =
 
*deflectionLiftCoeff =
 
*ctrlSurfaceRange =
 
*ctrlSurfaceArea =
 
 
 
'''ctrlSurfaceRange''' - How far off centre the control surface (rudder / aileron etc) can move under control
 
 
 
'''ctrlSurfaceArea''' - The effective surface area of the control surface - the bigger the surface, the bigger the surface area must be set to
 
 
 
=== Decouplers ===
 
 
 
*ejectionForce =
 
 
 
'''ejectionForce''' - How hard it separates on stage ejection.
 
 
 
''Note, decouplers also add two lines to Standard Part Parameters, "stageAfter = True" and "stageBefore = True"
 
 
 
=== Parachutes ===
 
 
 
*useAGL =
 
*autoDeployDelay =
 
*minAirPressureToOpen =
 
*deployAltitude =
 
*closedDrag =
 
*semiDeployedDrag =
 
*fullyDeployedDrag =
 
 
 
'''useAGL''' - Whether or not the parachute opens at the set altitude above ground level, instead of above sea level.
 
 
 
'''autoDeployDelay''' - Time before parachutes attached to jettisoned parts are activated.
 
 
 
'''minAirPressureToOpen''' - The minimum air pressure required before the chute will activate.
 
 
 
'''deployAltitude''' - At what altitude the parachute deploys fully once activated.
 
 
 
'''closedDrag''' - The drag when the parachute is closed.
 
 
 
'''semiDeployedDrag''' - The drag when it's semi-deployed
 
 
 
'''fullyDeployedDrag''' - And finally, the drag when it's entirely deployed.
 
 
 
== Conclusion: ==
 
 
 
There you go then. By now, you should know the ins and outs of the part.cfg file, and how to create one, edit one, play around with one, etc. All sorts of cool stuff like that. The final dummy part.cfg file will be after this, with the special part parameters added in.
 
 
 
Anyway, that's that, now you know, now go make some cool addons like FTL drives and newton-defying inertial dampeners.
 
 
 
== Dummy part.cfg file completed ==
 
 
 
'''// Kerbal Space Program - Part CFG file'''
 
'''// Mark V Rocket Engine'''
 
 
 
'''// --- General Parameters ---'''
 
 
 
name = LiquidThrusterV
 
 
 
module = LiquidEngine
 
 
 
author = YourName
 
 
 
'''// --- Asset Parameters ---'''
 
 
 
mesh = myMesh.dae
 
 
 
scale = 0.1
 
 
 
texture = awesometexture.png'''
 
 
 
specPower = 0.5
 
 
 
rimFalloff = 3
 
 
 
alphaCutoff = 0
 
 
 
'''// --- Node Definitions ---'''
 
 
 
node_stack_bottom = 0.0, -3.5, 0.0, 0.0, 1.0, 0.0, 1.0
 
 
 
'''// --- FX Definitions ---
 
 
 
fx_exhaustFlame_blue = 0.0, -10.0, 0.0, 0.0, 1.0, 0.0, active
 
 
 
fx_exhaustLight_blue = 0.0, -10.0, 0.0, 0.0, 0.0, 1.0, active
 
 
 
'''// --- Sound FX definition ---'''
 
 
 
sound_vent_medium = activate
 
 
 
sound_rocket_hard = active
 
 
 
sound_vent_soft = deactivate
 
 
 
'''// ---Editor parameters ---'''
 
 
 
cost = 120
 
 
 
category = 0
 
 
 
subcategory = 0
 
 
 
title = Mark V Rocket Engine
 
 
 
manufacturer = Awesomely Terrible Spaceship Engines Inc.
 
 
 
description = This part will now get you to space with 60% less limb loss than the mark IV engine.
 
 
 
'''// --- Standard part parameters ---'''
 
 
 
mass = 1.5
 
 
 
dragModelType = default
 
 
 
maximum_drag = 0.4
 
 
 
minimum_drag = 0.2
 
 
 
angularDrag = 0.2
 
 
 
crashTolerance = 5
 
 
 
maxTemp = 2500
 
 
 
'''// --- Special Part Parameters ---'''
 
 
 
maxThrust = 150
 
 
 
minThrust = 0
 
 
 
heatProduction = 360
 
 
 
fuelConsumption = 7
 
  
[[Category:Tutorials]][[Category:Documentation]]
+
[[Category:Tutorials]]
 +
[[Category:Documentation]]
 +
[[Category:Modding]]

Latest revision as of 06:31, 2 January 2022

Configuration files are text files used to specify, store and adjust information for various parts of the game in a human-readable manner. They most commonly use the .cfg file extension, but this is not always the case. The most commonly referenced cfg files are part configurations. These are used to change settings for the part such as mass, size and cost, as well as adding, removing or adjusting part modules, for example increasing an engine's thrust or adding resource storage capacity.

Config Format

The config format used in Kerbal Space Program is NOT a Unity class, but specific to KSP.

KSP reads .cfg files into config nodes. Config nodes can contain values (serialized versions of all sorts of data types) or other config nodes. See the C# class documentation in the KSP API Documentation for more details.

Module Manager

The stock config is very simple - nodes and values, which are nothing more than tree nodes and strings. Parsing is handled by modules that use .cfg files. See KSPField in the API.

The mod Module Manager adds powerful filtering and extension capabilities to the Config Node format. If you see an @ signs, []'s, or it looks like programming, the config is using Module Manager. It is well documented in the forum thread and on sarbian's Gitub.

Basic Part Making Guidelines

Every part consists of multiple files, including the configuration file, a model and a collision mesh. Under the 0.25 standards, the model and collision mesh must both have a material assigned when creating them in your modeling software and prior to export for use. I am not a modeler, so I will leave that guidance to someone more qualified.

When creating a new part, each of these files (including additional models and meshes, if needed) should all be contained in a single folder which describes or names the part. Even though Squad themselves are horribly inconsistent when building parts, it is best to have the name of the folder, and the names of each of the meshes match the name of the part inside the cfg file (not the name that you see in the parts building! More on that later).

If you making more than a few parts, you may want to create a folder for each type of part. This is certainly an acceptable practice, and one that Squad uses themselves. For example: /Engines/ to place all of your engine designs inside.

If you are making a mod that does things other than just provide a stock-capable parts pack, you may want a more subfolders, one for parts, one for agencies, another for contracts, etc, etc.

No matter how deep you nest your mods' folders, your mod itself should be contained within the /GameData folder with a name that uniquely identifies your mod. It would be wise to name this folder the same as you are marketing your mod (ie: GameData\Modular Kolonization System\ is advertised as Modular Kolonization System or GameData\MechJeb is advertised as MechJeb) (and yes, I know that I'm using examples which actively violate this principle!)

So, I wrote a mod (let's call it ShadowSplat) that modifies some resources, adds a few agencies, and massively updates the parts pack including new engines, fuel tanks, science containers, and electrics. My folder structure might look like this:

KSP_win\GameData\ShadowSplat\
KSP_win\GameData\ShadowSplat\Agencies
KSP_win\GameData\ShadowSplat\Resources
KSP_win\GameData\ShadowSplat\Parts
KSP_win\GameData\ShadowSplat\Parts\Engine
KSP_win\GameData\ShadowSplat\Parts\FuelTank
KSP_win\GameData\ShadowSplat\Parts\Science
KSP_win\GameData\ShadowSplat\Parts\Electrical

PARTS Configuration Files

As of at least 0.24.2[outdated], the order of the configuration file matters very little. As far as I can tell, you can throw just about anything you want in there in any order. However, for compatability and error-checking reasons, it's best to follow the general structure that exists within stock parts. Many of the stock parts contain commenting-out lines to help you decode where things should go, but, here's a general breakdown, using a mythological part (let's call it "DoesItAll"). DoesItAll will exist in this foldier:

KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll

and will consist of the files:

KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.cfg
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mu
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mbm

Note: this is a general explanation. Additional information can be found be clicking the provided links:

General Parameters

Actual part Explanation
PART - specifies that this cfg relates to a part
{
name = DoesItAll set the hidden name of the part. Spaces are not allowed. Underscores and other special characters are either not allowed or not recommended. This name is used behind the scenes for reference to and from other parts and procedural calls, but is also revealed during crash/damage dialog boxes (F3). It is good programming practice to use a name that at least partially defines the part and/or creator. fuelTankSmallFlat (which is already in use) is not a good name to use here, even though it does describe the part effectively, it does not differentiate between an fuelTankSmallFlat - The T-100 fuel tank and the Rockomax X200-8 Fuel Tank, which could also be considered a fuelTankSmallFlat.
module = Part This convention is no longer used. Earlier versions of KSP only permitted individual parts to serve as single modules and this was therefore appropriately placed back then. Newer versions allow parts to have/serve as multiple modules and the conventions for defining those modules have been relocated and redefined as its own subgroup. Can still be found in legacy parts that have not been updated, including the "Tail Fin" by C7 Aerospace Division. 5 parts in total are known to still use this convention.
  • FuelLine has the additional property of maxLength, presumably to restrict the length of fuel lines. This method is used on the Stock Fuel Line
  • StrutConnector has the additional properties of linearStrength, angularStrength and maxLength. This method is used on the stock Strut Connector
  • Winglet has the additional properties of dragCoeff and deflectionLiftCoeff. just like the ModuleControlSurface. This method is used on the stock parts Tail Fin, wingletAV-T1, sweptWing and is expected to be deprecated at the next revision of those parts.
author Simply a place to take credit for your creation / update. This line is not referenced in-game. It is recommended that you utilize the same author credit for all parts that you or your team create under one title. For example, assign all MKS mods to author MKS Team and all OKS mods to author OKS team, even though you are all the same team.

Model Parameters

At this point, you can use the deprecated style of mesh on a line by itself, or open a new sub called MODEL. The preferred method is to use MODEL:

Actual part Explanation
MODEL { opens the MODEL sub
model The name of the mesh. Write its name therein and keep the mesh file in the same directory as the part file.
scale The scale of the model - depending on the units in your 3D modelling program. If you used one unit = one meter, then use a scale of 1. If it's 1 unit = 0.1 meters, then use a scale of 0.1. Using a 0.1 scale factor and then scaling to fit the other parts is easier than fiddling around with scale factors. This factor will only affect the units involved in node placement and will not affect the actual size of the part.
texture Specifies let location of the texture file - e.g. texture = texturefilename , folder/../texturefilename (/folder would be GameData/folder)

If you do not use MODEL, you must use mesh to define the parts collision mesh, like so:

Actual part Explanation
mesh Mesh defines the mesh and texture package used to create the in-game appearance of your part. Acceptable meshes include .mu files.

Asset Parameters

Actual part Explanation
mesh = DoesItAll.mu Mesh defines the mesh and texture package used to create the in-game appearance of your part. Acceptable meshes include .mu files
scale scale defines the size of your part. I am uncertain as to what will happen when you change this value
specPower Specific Power? fuelLine
rimFalloff 3 fuelLine
alphaCutoff Number: 0.0 fuelLine
rescaleFactor

An optional parameter that is not usually included in most parts, but the option is available for resizing a part for personal use. In order to retain correct node placements, the scale parameter must also be proportionally changed to match the new rescaleFactor. The default value for rescaleFactor is 1.25 but can be changed to any value.

iconCenter 0,3,0 Array of integers? (advSasModuleLarge, fuelLine)

Node Definitions

So, node definitions are a little weird. You don't have to use any, and you *can use a whole bunch. Defines where parts attach to other parts. Tricouplers have four: three bottom and one at the top, while most parts simply have two, and a few parts have only one.

Node stack defines where the part vertically stacks with other parts, and node attach defines where on a part's surface other parts attach - in other words, horizontal attachment.

The attachment values relate to an object's origin, and their values correspond to a model's units and scaling factors. A node_stack_bottom with x, y, and z values of (2.5, 5.0, 3.0) will have an attachment node 2.5 units to the right, 5.0 units up, and 3.0 units forward. The next three values refer to the orientation that a particular node will accept other attachments, on a scale of -1.0 to 1.0. These represent the vector that a part will orient itself on when attaching to the node. For example, a fuel tank with a node_stack_bottom will have angx, angy, and angz values of (0.0, -1.0, 0.0). This represents a vector downward relative to the part model, in the negative y direction. A value of (0.0, -1.0, 1.0) would represent a diagonal vector downward and forward, while a value of (1.0, 1.0, 1.0) would represent a vector to the right, up, and forward.

Generally, most parts will have angx, angy, and angz values of either (0.0, -1.0, 0.0) for a node_stack_bottom and (0.0, 1.0, 0.0) for a node_stack_top.

The last value indicates the visual size of an attachment node. Values may be either 0 (small half-meter node), 1 (normal), or 2 (large). This parameter is optional and will default to 1 if nothing is specified.

Keep in mind, naming conventions (_stack_bottom, _stack_top) for nodes only apply to node_stack; they are only helpful in identifying a node's position.

Known node definitions are listed below:

  • node_stack_top
  • node_stack_bottom
  • node_stack_top2
  • node_stack_bottom2
  • node_stack_connect01
  • node_stack_connect02
  • node_stack_connect03
  • node_attach
  • node_stack_bottom01
  • node_stack_bottom02
  • node_stack_bottom03
  • node_stack_bottom04

Each one follows this example, and specifies where other parts can connect to this part:

Actual Part Explanation
node_attach = 0.00, 0.147, 0.00, 0.0, 1.0, 0.0, 1 specifies the location of the nodes of this part (the green circles).
node_stack_bottom = x, y, z, angx, angy, angz, size
node_stack_top = x, y, z, angx, angy, angz, size
node_attach = x, y, z, angx, angy, angz, size

FX definitions

FX definitions specify visual effects associated with this part, including engine exhausts, explosions, and coloration. Each one is a unique effect, and the only parameters they take is the location/offset that the effect occurs at. The 'active' switch on the end is used to define when this effect will be visible. See the FX Groups listing to know which effect groups are available, and when they are used. It's also possible to assign an effect to more than just one FX Group. If for instance, you want a smoke effect to be visible both when the part activates and also when it deactivates itself, you can do this:

fx_gasBurst_white = x, y, z, angx, angy, angz, activate, deactivate

This is particularly useful if you're defining a lot of effects, like the gas discharges on an RCS module.


 fx_exhaustFlame_yellow = x, y, z, angx, angy, angz, active
 fx_exhaustLight_yellow = x, y, z, angx, angy, angz, active
 fx_smokeTrail_medium = x, y, z, angx, angy, angz, active

Known FX calls are listed below:

  • fx_exhaustFlame_blue_small
  • fx_exhaustFlame_yellow
  • fx_exhaustFlame_yellow_tiny
  • fx_exhaustFlame_blue
  • fx_exhaustFlame_white_tiny
  • fx_exhaustLight_yellow
  • fx_exhaustLight_blue
  • fx_smokeTrail_medium
  • fx_smokeTrail_light
  • fx_gasBurst_white
  • fx_exhaustSparks_flameout
  • fx_exhaustSparks_flameout_2
  • fx_exhaustSparks_yellow

Module Parameters for PREFAB_PARTICLE and MODEL_MULTI_PARTICLE:

Variable Value Definition
prefabName fx_exhaustFlame_blue The name of the effect you want to use (See list above).
transformName smokePoint The name of the point defined in the Unity editor where the effect will appear from.
size Throttle Range (0.0), Scale (0.0) (Deprecated, doesn't work!) Scales the size of the particle effect set in the Unity editor. This parameter is usually the same number as the size in meters for the part (1.25, 2.5, 3.75, etc.). You need one line with a declaration for every point on the throttle range you are editing (See example below).
energy Throttle Range (0.0), Scale (0.0) Scales the energy of the particle effect set in the Unity editor. Energy is the time it takes for the effect to disappear. For smoke trails, you want a high value, but for water vapor you want a small value. You need one line with a declaration for every point on the throttle range you are editing (See example below).
emission Throttle Range (0.0), Scale (0.0) Lets you edit the emission range and scale of the effect. It handles amount of particles in a set amount of time. You need one line with a declaration for every point on the throttle range you are editing (See example below).
speed Throttle Range (0.0), Scale (0.0) Scales the velocity of the particle effect set in the Unity editor. You need one line with a declaration for every point on the throttle range you are editing (See example below).
localOffset X, Y, Z Used in PREFAB_PARTICLE. Lets you change the offset of the effect in 3D space. To move the particle effect closer to or further from the nozzle, edit the Z axis.
localPosition X, Y, Z Used in MODEL_MULTI_PARTICLE. Lets you change the offset of the effect in 3D space. To move the particle effect closer to or further from the nozzle, edit the Z axis.
localScale X, Y, Z Used in MODEL_MULTI_PARTICLE. This was implemented in KSP 1.4.5 and replaces the size parameter. Lets you change the size of the particle so that the same particle can be custom fit to engines of various sizes. However, values other than [1, 1, 1] only work properly when the engine has (for part makers: only one of the named emitter transform; for casual players: only one nozzle). It works correctly on RCS thrusters that have up to 5 such emitters. This parameter also cannot be used on any of the particles provided by default in the game or by most part mods. New particles must be made such that the same transform that holds the PartTools script also holds the KSP Particle Emitter script.

Example taken from the config file for the S3 KS-25 "Vector" Liquid Fuel Engine:

PREFAB_PARTICLE
{
	prefabName = fx_smokeTrail_light
	transformName = smokePoint
	emission = 0.0 0.0
	emission = 0.05 0.0
	emission = 0.075 0.25
	emission = 1.0 1.25
	speed = 0.0 0.25
	speed = 1.0 1.0
	localOffset = 0, 0, 0
}

Sound FX definitions

Just like Visual effects, sound effects specify an effect to be used by the part. Sound effects are coded using a two-sided equation, the left side specifies the sound or sound file to be used, whereas the right side specifies when to use that particular sound. Known Sound Effects definitions are:

This is pretty easy to use in a basic way, which will suit our needs just fine.

Under this section, comes:

sound_vent_medium = activate
sound_rocket_hard = active
sound_vent_soft = deactivate

Sounds are added to FX Groups, in much the same way smoke and flame effects are. Of course, sounds do not need to be positioned in space, nor do they have rotations, so all you need is to indicate in which FX Group the sound will be executed. As with effects, you can assign multiple groups to a sound.


Since 0.20 GameData structure there are 2 ways to add a sound to a part:

  • KSP has an internal sound library, which contains a few sound effects. By defining a sound as in the example above, KSP will search for that sound in its internal library.
  • The second way is to add new sound files which is ONLY possible if adding the sound file to the GameData/modName/parts/partName/part/sounds/ folder. Note that all the sounds are therefore "private", only accessed by that part. For now, the legacy folder or a shared mod folder method doesn't work, devs are probably going to fix this problem in the future.


REMEMBER: If you add a custom sound, the file name must start with sound_ (e.g., sound_myNewSoundEffect.wav).

To use a sound from the KSP internal library or the part/sounds folder, you must not include the extension in the sound name (e.g., sound_vent_medium = activate), otherwise the sound will not work.

Supported files are 48000 Hz .wav files and .ogg

These are the paired sound types and part statuses.

Sound Engine Status
sound_jet_low decouple
sound_jet_deep engage
sound_vent_soft running
sound_vent_large power
sound_vent_medium disengage
sound_rocket_hard flameout
sound_rocket_mini activate
sound_decoupler_fire deploy
sound_explosion_low
sound_parachute_open
sound_parachute_single

Editor Parameters

Actual Part Definition
CrewCapacity The number of Kerbals that can be seated in this part. Mk1 Command Pod seats 1. Jebediah is so awesome, he only takes up .7 seats. Chuck Norris takes as many seats as he wants. Use 0 to specify a probe.
TechRequired

This is the technology tree node that must be activated in order to have access to this part. Any single word can go here, but if you use a word that is not in the tech tree definition, you may never be able to access your part. Currently, stock KSP comes with the following Technology_tree nodes:

  • start
  • basicRocketry
  • engineering101
  • generalRocketry
  • stability
  • survivability
  • advRocketry
  • generalConstruction
  • flightControl
  • scienceTech
  • heavyRocketry
  • fuelSystems
  • advConstruction
  • aerodynamicSystems
  • advFlightControl
  • electrics
  • spaceExploration
  • landing
  • heavierRocketry
  • specializedConstruction
  • actuators
  • supersonicFlight
  • specializedControl
  • precisionEngineering
  • advElectrics
  • advExploration
  • advLanding
  • nuclearPropulsion
  • advMetalworks
  • composites
  • advAerodynamics
  • highAltitudeFlight
  • largeControl
  • unmannedTech
  • ionPropulsion
  • largeElectrics
  • electronics
  • fieldScience
  • veryHeavyRocketry
  • metaMaterials
  • heavyAerodynamics
  • hypersonicFlight
  • advUnmanned
  • specializedElectrics
  • advScienceTech
  • advancedMotors

The following Tech Tree nodes are present in stock, but not used unless called for by a mod.

  • nanolathing
  • experimentalMotors

The following Tech makes a part unresearchable and unbuildable but does it not remove from existing ships

  • Unresearcheable
entryCost entryCost represents the amount of Funds required to unlock this particular part. As such, it could be considered an 'investment' cost in the development. First you have to have the brains to make the thing, then someone has to develop it (that's this cost), then you can get it into production (that's cost, coming later). You can set this to any value you like. Bear in mind that this value has no meaning in Sandbox or Science Modes. It is only used in Career Mode.
cost cost represents the cost in Funds to attach a single instance of this part to your craft. It represents the "wet cost", assuming all resources are at their full amount. This is different from mass, which is the dry mass. Cost has no use in Sandbox or Science modes, it is only used in Career mode
category Mods are organized alphabetically according to their sub-directory in parts, and then according to this value. This is why, when you add a mod that is contained in folder "000_NewMod", it's parts appear first and when you add a mod that is contained in "ZZZ_NewMod", it's parts appear last. Currently there are nine useable categories:
  • Command
  • Propulsion (deprecated, but still useable)
  • FuelTank
  • Engine
  • Aero
  • Electrical
  • Structural
  • Utility
  • Wheel
subcategory subcategory is not currently in use as of [0.90]. It is expected that this control will later be linked to [category] to provide a further subdivision of searchable parts in-game, possibly to cut down on clutter when the parts list gets exceptionally high. With certain mods installed, the Propulsion category already spans several pages. [subcategory] can help control this by provided variants such as [liquidEngine], [LOXfueltank], [SRB], etc
title title is the in-game name for your part and features such iconic names as 'Command Pod Mk1'. The title of your part can be as long or short as you want, and there are no known limitations on what can be used in the title. This is how your part will be known in-game, on in-game contextual menus and referred to on message boards and forums (hopefully) so take that into consideration.
manufacturer manufacturer is flavor text (possibly useful in future iterations as a filter for parts) that defines who built or created the part for use (or pulled out of the junk-pile and sold at 10000% mark-up for you to use). Just as with the title of your part, there are no known restrictions on the flavor text, including length. This is KSP, though, so try to be humorous
description description is the flavor text that describes your parts purpose, motivation, direction, life aspirations, goals, favor colors, and (hopefully) what it can (is supposed to) do. As with other flavor text, there are no known limitations on what can go here, including length. In fact, this flavor text is treated special in-game by being given a text box that automatically scrolls based on the length of the description used. If your part does something unusual, it's probably a good idea to (at least partially) document it here, so people know how to use your part in-game. Many are the parts that have failed their popularity exams because of bad descriptions.

Attachment rules

attachRules defines how this part attaches to or allows attachments from other parts. Though documented in some part files, the documentation is minimalist and difficult to understand, so here's a little clean-up and expansion.

  • // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
  • attachRules = 1,1,1,1,1

The rules correspond to the numbers below - 1 is allow, 0 is prevent. The tags are:

stack - Can your part be stacked on others?

SrfAttach - Can your part be placed onto a surface?

allowStack - Will you allow other parts to be stacked on your part?

allowSrfAttach Can other parts be placed on the surface of yours?

allowCollision - A special one: Can your part be placed if part of it is intersecting another part?


Note that you can also force parts attached to this part to attach in a specific symmetry.

  • // symmetry rules: 0=1x, 1=2x, 2=3x, 3=4x and so on...
  • stackSymmetry = 3



Standard Part Parameters

This defines how your part performs in the air and its limits. Note that not all of these parameters need to be defined. If they're left out of the cfg file, KSP will use a default value for them. Standard part parameters indicate how the part interacts with the environment in flight mode. From mounting on the launch platform or the runway through take-off and atmospheric interactions to landing and blowing up, this is where physics enters the game

Actual Part Definition
mass = 1 mass measured in Kerbal tons, describes the 'weight' of your part and is used in calculations involving roll, pitch, yaw, and thrust. The higher the mass, the more energy will be needed to change any of those four parameters. It is also used in making center-of-mass, center-of-lift and center-of-drag calculations, some of which are critical for aerodynamic flight. This is a numerical value, and you can use any positive value. Bear in mind that extremely high positive values for [mass] may make the part unusable in-game or require additional special parts to make usable. This is generally considered poor design. It represents the "dry mass" when all resources are empty. This is different from cost, which is the wet cost.
dragModelType [dragModelType] describes how your part interacts with drag forces. At present, the known [dragModelType]s include:
  • default
maximum_drag (could use clarification) The maximum drag coefficient of the part (usually under between 0.2 and 0.3 and < 1). Generally drag when part's direction of travel is along its y-axis.
minimum_drag (could use clarification) The minimum drag coefficient of the part (usually under between 0.2 and 0.3 and < 1 and lower than maximum_drag). This value is unused if dragModelType is set to default. Generally drag when the part's direction of travel is perpendicular to its y-axis.
angularDrag (could use clarification) how much angular drag is there/resistance to turning? (Also usually under 1.)
crashTolerance crashTolerance describes the maximum velocity (in m/s) at which your part can interact with another part without suffering damage (read: blowing up). The higher you set this value, the faster an impact your part can survive. 12 is fairly high, and is the de facto standard for most pods. 14 is useful for landing legs, and 50 is used on some wheels, which are basically indestructible.
BreakingForce

optional [breakingForce] specifies an amount of Force exerted between this part and another part that it is attached to. When exceeded, the two parts will separate (usually catastrophically). Higher values indicate stronger connections.

BreakingTorque optional. Like [breakingForce], [breakingTorque] defines an amount of Force between two parts, but rather than direct force towards or against, [breakingTorque] refers to rotational forces between the two objects. It assigns a value that, again, when exceeded, will cause the two parts to separate, with the expected results
maxTemp Stock KSP uses the [maxTemp] value to determine at what temperature parts will blow up due to overheating. As of Version 1.1, heat sources include Kerbin's sun, re-entry and aerodynamic heating, and engine exhaust. KSP's uses Kelvin as its temperature scale. Once this value is exceeded, your part will spontaneously explode. Managing heat with engines is a critical function of launching higher-powered engines, and design considerations mean that you shouldn't place parts with low [maxTemp] values directly in the path of engine exhaust. ~1800 is a good value for most engine assemblies.
ActivatesEvenIfDisconnected true or false, assumed to specify whether the part will operate when not connected to a vessel (remote control?) Must test. Currently, only know part is the Sepratron I
stagingIcon Sets the icon in the staging system
  • DECOUPLER_HOR (Radial Decoupler Icon)
  • LIQUID_ENGINE (Liquid Engines, or engines that have controllable thrust)
  • SOLID_BOOSTER (Solid Rocket Boosters, or engines without controllable thrust)
  • RCS_MODULE (Small 4-Way RCS Block Icon)
  • FUEL_TANK (Red Fuel Tank Icon)
  • COMMAND_POD (Generic Command Pod Icon)
  • DECOUPLER_VERT (Vertical Decoupler)
  • (?)
stageOffset Can be 0, 1, etc. defines whether this part will create a new stage before itself. This only applies for the automatically generated staging sequence. -1 is used in parachutes...signals that activation of this object does not cause a staging effect?
childStageOffset Can be 0, 1, etc. defines whether this part will create a new stage after itself. This only applies for the automatically generated staging sequence.
explosionPotential unknown purpose. Possibly for future use for random failures. Known values are numerical.
  • 0.1
  • 0 (BSLsnakprobe)
fuelCrossFeed Will the part crossfeed fuel between parts attached to it? allows or restricts fuel moving through this part. Boolean argument: True or False
NoCrossFeedNodeKey = bottom if set to bottom will keep fuel from flowing FROM bottom nodes (avoiding some stack imbalances). Used with parts with multiple bottom nodes, such as the TVR-1180C Mk1 Stack Tri-Coupler. keeps resources from flowing FROM the named nodes (prevents stack imbalances and such) Use with fuelCrossFeed true to to allow resources to flow into these parts, but not back out. Known parameters: bottom
linearStrength The amount of stress the given part can sustain without breaking, in a straight back-and-forth direction. Used for fuel lines and strut connectors.
angularStrength The amount of stress the given part can sustain without breaking, laterally. Used for fuel lines and strut connectors
maxLength The maximum possible length of this stretchy part, expressed in meters. Used for fuel lines and strut connectors, as they have repeating meshes
vesselType unknown. May automatically set the Ship Type variable when including parts with a defined [vesselType]. Known [vesselTypes] include:
  • Ship
  • Probe
  • Lander
  • Rover
  • SpaceObject (refers only to PotatoRoids)
PhysicsSignificance optional. unknown purpose. assumed to default to zero. Appears to be a numerical value. Many parts are 'physicsless' Known parts:
  • radialFlatSolarPanel
  • ladderRadial
  • z-400Battery
  • z-100Battery

Known Values: 1

MODULES

Each Configuration file is composed of several sections. Some of these sections are standardized across all parts, others are specific to specific part types. To build or modify a successful part, it is necessary to have an understanding of what each section does, and within those sections what each line of configuration actually does, and what the options are for those lines. This Definitions file will attempt to address each of those questions in turn and is current as of [0.25.0]


Notes: It appears that, with a few exceptions, all definitions can occur in any order in the PART file. Free arrangement is valid for MODEL {}, INTERNAL {}, MODULE {},



MODULEs define what specific parts can do. They are generally calls to C-coded or hard-coded functions that define what functionality these parts have in-game.

name names define the module in use and are a general indication of what the module subtype does. Specific variables are associated with each MODULE.[name]. For example, the Clamp-O-Tron Docking Port Sr. has the MODULE.name ModuleDockingNode and its' associates variables are [referenceAttachNode] and [nodeType]. Some MODULEs share variables with other MODULEs, which can make deciphering their purpose difficult.

known MODULEs, their associated variables, and the meanings of those variables will be explained below.

MODULE Name MODULE Function From Modification
ModuleCargoBay Cargo bays Stock
ModuleParachute Parachute Operations Stock
ModuleSAS Control System Stock
KerbalSeat Internal Seating? Stock
ModuleLandingGear One type of Wheel Stock
ModuleSteering For Wheel Operations Stock
FXModuleConstraingPosition Unsure Stock
ModuleLandingLeg For Landing Legs Stock
RetractableLadder For Collapsible Ladders Stock
ModuleReactionWheel Controls Force of Reaction wheels Stock
ModuleScienceContainer Place to store Science Stock
FlagDecal Flag Decorations on Parts Stock
ModuleScienceLab For Science generators Stock
ModuleJettison Fairing removal Stock
ModuleAlternator For producing resources based on thrust Stock
ModuleCommand For Control Stock
ModuleEnviroSensor Unmanned Science Stock
ModuleControlSurface Control Surfaces, aelirons Stock
ModuleAnimateHeat Animation to be played based on heat Stock
Module Engines Engines and Thrust (somewhat deprecated) Stock
FXModuleAnimateThrottle Animation to be played based on throttle level Stock
ModuleEnginesFX Engines and Thrust (use this in place of Module Engines) Stock
ModuleGimbal Engine Directionality Stock
ModuleTestSubject Contract System Stock
LaunchClamp Launch Clamps Stock
ModuleDockingNode Docking Ports Stock
ModuleRCS Reaction Control Systems Stock
ModuleResourceHarvester Harvests resources from the environment Stock
ModuleResourceIntake Intakes that produce resources Stock
ModuleScienceExperiment Controlling Experiments Stock
ModuleGrappleNode For the Klaw Stock
ModuleLight For external lighting Stock
ModuleAnimateGeneric Generic Animation Calls Stock
ModuleDataTransmitter For transmitting antennas Stock
FXModuleLockAtConstraint Uncertain Stock
ModuleAsteroid Unsure Stock
ModuleDeployableSolarPanel For unfoldable solar panels Stock
ModuleWheel For wheels, powered or unpowered Stock
FXModuleLookAtConstraint Unknown Stock
FXModuleConstrainPosition Unknown Stock
ModuleAnchoredDecoupler Decouplers1 Stock
ModuleDecouple Decoupling Operations Stock
KASModuleContainer Containers KAS / Kerbal Assembly System
KASModuleGrab KAS / Kerbal Assembly System
KASModuleStrut KAS / Kerbal Assembly System
SCANset SCANsat
TweakScale Changing the size of parts TweakScale
MechJebCore Automated ship controls and advanced information systems MechJeb
ModuleConnectedLivingSpace MKS/OKS / Modular Kolonization System
KolonyConverter MKS/OKS / Modular Kolonization System
MKSModule MKS/OKS / Modular Kolonization System
ExWorkshop MKS/OKS / Modular Kolonization System
KarboniteAtmoExtractor MKS/OKS / Modular Kolonization System
KarboniteDrill MKS/OKS / Modular Kolonization System
KarboniteGenerator MKS/OKS / Modular Kolonization System
KarboniteParticleExtractor MKS/OKS / Modular Kolonization System
KarboniteConverter MKS/OKS / Modular Kolonization System
USI_Converter MKS/OKS / Modular Kolonization System
USIAnimation MKS/OKS / Modular Kolonization System
USI_BaseAnchor MKS/OKS / Modular Kolonization System
USI_InertialDampener MKS/OKS / Modular Kolonization System
ProxyLogistics MKS/OKS / Modular Kolonization System
FSanimateGeneric Firespitter
FStextureSwitch2 Firespitter
FSfuelSwitch Firespitter
MKSLcentral MKS/OKS / Modular Kolonization System
ORSModuleAirScoop MKS/OKS / Modular Kolonization System
ORSModuleAirIntake MKS/OKS / Modular Kolonization System
ORSResourceScanner MKS/OKS / Modular Kolonization System
ORSModuleRailsExtraction MKS/OKS / Modular Kolonization System
ORSModuleParticleCollector MKS/OKS / Modular Kolonization System
ORSAnimatedScanner MKS/OKS / Modular Kolonization System
ORSAnimatedExtractor MKS/OKS / Modular Kolonization System
ModuleSPU Remote Tech
ModuleRTAntennaPassive Remote Tech
FSplanePropellerSpinner Firespitter
FSengineSounds FSengineSounds

INTERNAL

Internal specifies the internal files used to construct views from the IVA or internal vehicular activity, and are referenced out to the \Spaces\ directory of the relevant part mod. (Squad's internals are in \GameData\Squad\Spaces). INTERNALs have their own .cfg files with their own calls and methods that will not be discussed here. Squad provides 9 INTERNALs as part of Stock KSP:

  • crewCabinInternals
  • cupolaInternal
  • GenericSpace1
  • GenericSpace3
  • landerCabinInternals
  • landerCabinSmallInternal
  • mk1CockpitInternal
  • mk1PodCockpit
  • PodCockpit

RESOURCE

In parts files, [RESOURCE] refers to a resource that is stored by a part. Each stored resource must be separately defined by a [RESOURCE] call. Any resource may be stored, including those not defined. The examples in the table below comes from a battery config.

variable example explanation
name ElectricCharge Name of the resource being stored.
amount 100 Amount of the resource included when dragged out of the parts list.
maxAmount 100 Maximum amount of the resource that can be stored
isTweakable false Allows/prevents modification of resource levels in editor.
hideFlow true Allows/prevents display of motion of resource transfer. Not sure why this would be important.

EFFECTS

variable explanation
clip specifies the location of an audio clip to play during the specified thrust effect.
volume

?? 2-part array, used twice, once to specify a minimum volume, once to specify a maximum volume, relative to the game's volume settings

pitch

?? 2-part array, used twice, once to specify a minimum volume, once to specify a maximum volume, relative to the game's volume settings

loop

boolean, true or false, specifies whether to play the sound once, or to keep playing the sound as long as the specified effect is in operation

Resource Configuration Files

Resources are massively modifiable, but Stock KSP only comes with a few, and these are contained in squad/resources/ResourcesGeneric.cfg. Be extremely careful when modifying ResourcesGeneric.cfg, as it could have unintended side effects for your rockets. Resource definitions follow these conventions:

variable example explanation
name
Resource Mod
LiquidFuel Stock
Oxidizer Stock
SolidFuel Stock
MonoPropellant Stock
XenonGas Stock
ElectricCharge Stock
IntakeAir Stock
EVA Propellant Stock
MechanicalParts MKS/OKS
Recyclables MKS/OKS
ElectronicParts MKS/OKS
PlasticParts MKS/OKS
ModularParts MKS/OKS
ReplacementParts MKS/OKS
RepairKits MKS/OKS
PatchKits MKS/OKS
Computers MKS/OKS
Robotics MKS/OKS
ExoticMinerals MKS/OKS
RareMetals MKS/OKS
Chemicals MKS/OKS
Polymers MKS/OKS
SpecMachinery MKS/OKS
AdvMachinery MKS/OKS
BasicMachinery MKS/OKS
PunchCards MKS/OKS
Compost MKS/OKS
MEP-Manufacturing MKS/OKS
MEP-Laboratory MKS/OKS
MEP-Refining MKS/OKS
MEP-Mining MKS/OKS
MEP-Environmental MKS/OKS
MEP-Computing MKS/OKS
This is the name of the resource. Like the name of your part, it is restricted to one word with no spaces or underscores. This is how the resource is referred to in-game.
Display Name Liquid Fuel Display name for UI elements, can have spaces.
Abbreviation LF For KerbNet resource switcher button. Two characters at best, like in the Periodic Table. Only important for things that are drilled up.
density 0.005 [density] is a numerical value between 0 and 1 used in calculations involving mass, storage capacity and units. Lower values mean lower densities, meaning you can get more units in a smaller space.
unitCost 0.8 [unitCost] defines the amount of Kerbits of value for each unit of the specified resource. Any number will do. Positive values indicate that you pay for the resource. Negative values have not been tested (yet), but it is assumed that negative values mean others will pay you to get rid of this resource. (Nuclear waste disposal, anyone?)
hsp 2010 Specific Heat, how much energy in joules per kelvin needed to raise the temperature of 1kg of resource by 1 deg Kelvin. High numbers make it great as a thermal control substance.
flowMode
  • STACK_PRIORITY_SEARCH
  • NO_FLOW
  • STAGE_PRIORITY_FLOW
  • ALL_VESSEL
[flowMode] defines how the resource moves throughout your vessel whenever the resource is requested by a particular part. There are 4 known methods of flow mode:
transfer
  • PUMP
  • NONE
[transfer] is an optional method which specifies how and whether or not a resource may be manually transferred from one location on a vessel to another. There are two known methods of [transfer]:
isTweakable
  • true
  • false
[isTweakable] is an optional, boolean method which specifies whether or not a resource may be assigned during construction. Defaults to true. The only accepted arguments are true and false.
isVisible
  • true
  • false
boolean, Is the gauge for this even ever visible (resource panel in flight and in VAB)? Overrides isTweakable. Almost every resource has this true.
volume

1

Standard value is 1. How many litres of space a unit of this occupies. Affects tankage in volume sensitive storage systems like KIS and B9 Part Switch.

Science Definitions Configuration Files

variable example explanation
id crewReport internal name of the experiment in question
title Crew Report Flavor text of the experiment
baseValue 5 Base science value of the experiment
scienceCap 5 Max? value of the experiment, before multipliers
dataScale 1 Multiplier used in calculations
requireAtmosphere
  • True
  • False
specifies whether this experiment must be conducted inside an atmosphere
situationMask 63 uses the sum of the situation bits to determine where the experiment can be conducted:
  • SrfLanded = 1,
  • SrfSplashed = 2,
  • FlyingLow = 4,
  • FlyingHigh = 8,
  • InSpaceLow = 16,
  • InSpaceHigh = 32
biomeMask 7 uses the same pattern as situationMask to determine whether experiment will give different result for different biomes. i.e. 7 = 1 + 2 + 4 so flying high will have only a single result per body but flying low (and landed or splashed) will give one result per biome
requiredExperimentLevel 0.5 specifies the level of research facility required before the experiment can be conducted
RESULTS
name example definition
Too many to list!
  • default
  • MohoSrf
You ran an Atmosphere Analysis, recording various measurements like temperature, pressure and atmosphere composition Flavor text for the science popup window and science archives that describes what happened when the experiment was conducted.
an array of data that provides flavor text for each scenario that the experiment is conducted in. Left side is a combination of the planet name and the situation bit. No spaces. Right side is the flavor text provided to the GUI.

Contracts Definitions Configuration Files

Contains a single call to STORY_DEF, which then allows for subsets
variable example explanation

Contracts Configuration Files

Agent Configuration Files

Agent configuration files specify specific Agents that may have an impact on the performance (read science, money, and prestige) awarded to your Kerbals for completion of specific tasks. Also specifies agency relations to one another. Many of these configurations are not implemented as of [0.90]

// Agency mentalities
// * Commercial   [Increased financial stakes, both for success and failure]
// * Competitive  [competes with companies which we have a negative standing towards, auto-added if any standings set][not impl]
// * Conglomerate  []
// * Startup   []
// * Cooperative  [not impl]
// * Ecomental   [not impl]
// * Economic   []
// * Hasty    [-deadlines -expiry +rep]
// * Patient   [] 
// * Industrial   [not impl] 
// * Perfectionist  [not impl]
// * Pioneer   [Makes agency more likely to offer a contract to something that's never been done before]
// * Record    [Flags agency as a record-keeping organization, focuses on contracts about breaking existing records and doing new things]
// * Scientific   [Agency is more likely to offer science data gathering contracts][not impl]
// * Stern     [Higher Reputation Stakes for both success and failure]
// * EasyGoing   [Lower Reputation Stakes for both success and failure]
// * Kerbalminded  [not impl][Sets up conditions against losing Kerbals]
// * Moral          [not impl]
// syntax guidelines
//
// standings = agent name string, float
// mentality = MentalityClass [float]


Kerbal Configuration Files

Defines what your Kerbals can do. Contained in the Traits.cfg file.

variable example definition in code
name
  • Pilot
  • Engineer
  • Scientist
describes the Kerbal's job
name = Pilot
title Any text Flavor text of the job
 title = Engineer 
desc Any text Flavor text of job description
desc = Pilots provide assistance in flying the vessel.
EFFECT { Array of skills describes benefits to vessel for having a Kerbal with this job aboard
 EFFECT
 {
  name = VesselScienceReturn
  modifiers = 1.05, 1.1, 1.15, 1.2, 1.25
 }
 EFFECT
 {
  name = PartScienceReturn
  modifiers = 1.05, 1.1, 1.15, 1.2, 1.25
 }

Prop Configuration Files

Contained in several different files, usually labeled prop.cfg, in the /Props/ directory. Describes aspects of parts used on IVAs, included buttons, switches, dials, and screens.

PROP
{
  name = directionalKnob
  MODULE
  {
    name = internalGeneric
  }
}
proxy = 0, 0, 0,  0.0225, 0.0075, 0.0225,  0, 1, 0

PROP
{
  name = RadarAltimeter
  MODULE
  {
    name = InternalRadarAltitude
    indicatorName = indicator
    increments
    {
       inc = 0, 0
       inc = 34, 100
       inc = 70, 200
       inc = 110, 300
       inc = 145, 400
       inc = 180, 500
       inc = 215, 1000
       inc = 232, 2000
       inc = 250, 3000
    }
  }
}
proxy = 0, 0, 0,  0.06, 0.01, 0.06,  1.0, 0.5, 0
PROP
{
  name = NavBall
  MODULE
  {
    name = InternalNavBall
    navBallName = NavSphere
    iconUp = 0, 1, 0
    progradeVectorName = progradeVector
    retrogradeVectorName = retrogradeVector
    progradeWaypointName = progradeWaypoint
    retrogradeWaypointName = retrogradeWaypoint
 normalVectorName = NormalVector
 antiNormalVectorName = antiNormalVector
 radialInVectorName = RadialInVector
 radialOutVectorName = RadialOutVector
 maneuverArrowName = ManeuverArrow
 anchorName = Anchor
  }
}
proxy = 0, 0, 0,  0.075, 0.01, 0.09,  1.0, 0.5, 0
PROP
{
  name = switch
  MODULE
  {
    name = internalGeneric
  }
}
proxy = 0, 0, 0,  0.0225, 0.0075, 0.0225,  0, 1, 0

Internals Configuration Files

Strategies Configuration Files

Contained in Strategies.cfg, used to describe the variable strategies available. Each strategy opens with STRATEGY {

variable samples description in code
name
  • AppreciationCampaignCfg
  • FundraisingCampaignCfg
  • OpenSourceTechProgramCfg
  • UnpaidResearchProgramCfg
  • OutsourcedResearchCfg
  • PatentsLicensingCfg
  • AgressiveNegotiations
  • RecoveryTransponders
Internal Description of Campaign Name. No spaces or special characters
name = AppreciationCampaignCfg
title Recovery Transponder Fitting Flavor text for the campaign name
title = Appreciation Campaign
desc Recovering parts landed far away from the Space Center can be very costly, but I reckon we can reduce those costs by installing better transponders on the parts we launch. These units are not cheap, but they should make it much easier to find parts, improving the recovery value even if they're half-way around Kerbin. What do you say? Flavor text for the description of the campaign
desc = We could definitely improve our 
image by putting some effort into reminding Kerbals 
everywhere of just how great the Space Program is. 
Advertisement space isn't free, however.
department
  • Operations
  • Finances
  • Science
  • Public Relations
Specifies the Department that the strategy belongs to. Can only be a department that already exists (as of [0.90]
department = Public Relations
icon specifies the icon image to be used in conjunction with the campaign. In the campaign selection.
icon = Squad/Strategies/Icons/AppreciationCampaign
groupTag
  • Basic,A
  • Basic,B
  • Basic,C
  • Misc,D
  • Misc,Recovery
Uncertain, clearly has something to do with grouping
groupTag = Basic,A
minLeastDuration positive Integers the minimum shortest amount of time (in days) that the campaign may have (campaigns must run at least this long)
minLeastDuration = 60
maxLeastDuration positive Integers the maximum shortest amount of time (in days) that the campaign may have. Using the sliders, campaigns may be adjusted to require at least this long to run
maxLeastDuration = 100
minLongestDuration positive Integers the minimum longest duration (in days) of the campaign. Using the sliders, campaigns may be adjusted to only run this long
minLongestDuration = 1200
maxLongestDuration positive Integers the maximum longest duration (in days) of the campaign (campaigns cannot run longer than this)
maxLongestDuration = 1600
requiredReputationMin Integers Minimum reputation required to purchase this campaign
requiredReputationMin = -500
requiredReputationMax Integers The most reputation you can be required to have in order to run this campaign
requiredReputationMax = 750
initialCostFundsMin Integers Minimum funds required to purchase this campaign
initialCostFundsMin = 8000.0
initialCostFundsMax Integers The largest amount of Kerbits that can be required to purchase this campaign
initialCostFundsMax = 160000.0
initialCostReputation Integers Minimum cost in reputation to run this campaign
initialCostReputation = 0.0
initialCostScience Integers Minimum cost is science points to run this campaign
initialCostScience = 0.0
hasFactorSlider
  • True
  • False
Can the campaign be adjusted by increasing inputs and getting greater outputs out of the campaign?
hasFactorSlider = True
factorSliderDefault Float multiplication factor for each step along the slider bar
factorSliderDefault = 0.05
factorSliderSteps Numbers number of steps/stages in the slider bar
factorSliderSteps = 20
EFFECT { see table below describes what the particular campaign actually does see table below

EFFECTS

There are currently three different EFFECT types available for use in Strategies: CurrencyOperation, ValueModifier, and CurrencyConverter. Each one has different variables and are detailed below.

CurrencyOperation
variable samples description in code
name
  • CurrencyOperation
internal reference name
name = CurrencyConverter
currency
  • Funds
input and output for campaign operations
currency = Funds
operation
  • Multiply
  • Add
operation to perform on currency
operation = Multiply
effectDescription "to Launch Costs" Flavor text for the operation to be performed
effectDescription = to Launch Costs
minValue Float factor to use in operations
minValue = 1.1
maxValue Float factor to use in operations
maxValue = 1.06
AffectReasons
  • VesselRollout
  • RnDPartPurchase
conditions that trigger the operation
AffectReasons = VesselRollout
ValueModifier
variable samples description in code
name
  • ValueModifier
internal reference name
name = CurrencyConverter
valueID VesselRecoveryFactor Value to be modified
valueId = VesselRecoveryFactor
minValue Float factor to use in operations
minValue = 1.1
maxValue Float factor to use in operations
maxValue = 1.06
CurrencyConverter
variable samples description in code
name
  • CurrencyConverter
internal reference name
name = CurrencyConverter
input
  • Funds
  • Reputation
  • Science
specifies the input for the campaign
input = Funds
output
  • Reputation
  • Funds
  • Science
specifies the outputs for the campaign
output = Reputation
minShare Float specifies the minimum
minShare = 0.0
maxShare Float specifies the maximum
maxShare = 1.0
minRate Float specifies the minimum rate of conversion, based on slider values
minRate = 0.041667
maxRate Float specifies the maximum rate of conversion, based on slider values
maxRate = 0.0520
AffectReasons
  • ContractReward
  • ScienceTransmission
  • ContractAdvance
  • VesselRecovery
  • VesselRollout
  • RnDPartPurchase
criteria for conversions
AffectReasons = ContractReward, ContractAdvance
effectDescription
  • gains
  • Income
describes the type of return
effectDescription = Income

Department Configuration Files

Used in the Strategies system, these specify the Departments available that provide different strategies for use.

variable samples description in code
name
  • Finances
  • Science
  • Public Relations
  • Operations
The department name
name = Public Relations
desc Flavor Text describes the department
desc = Linus is Wernher Von Kerman's Intern. 
Because Wernher himself is too important to be 
bothered with these boring strategy meetings. 
He sends his intern in his stead.
color array of 3 numbers between 0 and 255 specifies the color of the department
color = 149 254 135
avatar
  • Strategy_MechanicGuy
  • Strategy_PRGuy
  • Strategy_ScienceGuy
  • Strategy_Mortimer
Internal name of the Department Head
avatar = Strategy_PRGuy
headName
  • Mortimer Kerman
  • Linus Kerman
  • Walt Kerman
  • Gus Kerman
Flavor Text for the Department Head
headName = Walt Kerman
headImage
  • MORTIMER_KERMAN
  • SCIGUY_KERMAN
  • PRGUY_KERMAN
  • PRGUY_KERMAN
animation file name for the Head shot of the Department Head featured in the strategy selection screen
headImage = PRGUY_KERMAN