Difference between revisions of "CFG File Documentation"

Revision as of 20:47, 17 December 2014 (view source) Joshuadery (talk | contribs) m ← Older edit		Revision as of 21:43, 17 December 2014 (view source) Joshuadery (talk | contribs) (Began converting to example-based format with anchors, instead of headings) Newer edit →
Line 1:		Line 1:
−	{{TOC limit|2}}	+	== Basic Part Making Guidelines ==
−	{{Box|type=error|Large portions of this page are originally incorrect or so outdated that they are no longer useable.}}	+
−	{{Outdated|	+	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.
−	* Large portions of this page describe legacy mode options and deprecated concepts (roughly KSP 0.15.0) that are against current best practices.	+
−	* This page is no longer sufficient to create a part.	+	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.
−	Currently there is a incomplete version in development at [[User:Greys]]. It isn't finished yet but most likely will replace the content here. So changes to the page here will be replaced most likely.}}	+	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.
−	This tutorial will walk through the individual parts of the configuration file by building a dummy part file that will behave exactly like a real one, only lacking models, sounds, and textures.	+	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!)
−	== Basic Part Making Guidelines ==	+	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>
		+	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
		+	</pre>
−	Ensure that the model itself will not break the game on loading:	+	== Config file order ==
−	* Every mesh must have a material.	+	As of at least 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").  Note:  this is a general explanation. Additional information can be found be clicking the provided links:
−	== Part file creation ==	+	{|class="wikitable"
		+	|-
		+	! Actual part !! Explanation
		+	|-
		+	| PART { || - specifies that this cfg relates to a part
		+	|-
		+	| { ||
		+	|-
		+	| [[#Name|name]] = DoesItAll || the name of your part as referenced in game.
		+	|-
		+	| [[#module|module]] = Part || this convention has been deprecated.  Just use it as is, to make sure there are no errors with your part.  There are some unusual parameters still in use for this convention.
		+	|-
		+	| [[#author|author]] || You.  This is the place to take credit for this part
		+	|-
		+	| MODEL { || 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
		+	|-
		+	|- { || if you used MODEL, this is where you open the new sub
−	Save an empty notepad file, which will become the .cfg, in the directory of your addon—usually "../KerbalSpaceProgramDirectory/Parts/yourAddon".
−	This empty file will become the .cfg	+	|-
		+	| mesh = DoesItAll.mu || specifies the mesh to be used
		+	|-
		+	| scale || not sure
		+	|-
		+	| 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)
		+	|-
−	=== Config file order ===
−	<pre>
−	PART {
−	// Title	+	//
−	// Name of your part
−	//
	// --- general parameters ---		// --- general parameters ---
	// --- asset parameters ---		// --- asset parameters ---
Line 41:		Line 70:
	}		}
	// --- other MODULEs ---		// --- other MODULEs ---
−	}	+	|}}
−	</pre>	+
−	The slashes before each title indicate that the line thereof has been '''commented out'''; the program ignores such lines.
	=== Title ===		=== Title ===

---

Revision as of 21:43, 17 December 2014

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

Config file order

As of at least 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"). Note: this is a general explanation. Additional information can be found be clicking the provided links:

// // --- general parameters --- // --- asset parameters --- // --- node definitions --- // --- FX definitions --- // --- Sound FX definition --- // --- editor parameters --- // --- attachment rules: stck, srfAttach, allowStack, allowSrfAttach, allowCollision --- // --- standard part parameters --- // --- specific part parameters --- MODULE { // ---specific module parameters --- } // --- other MODULEs ---

Actual part	Explanation
PART {	- specifies that this cfg relates to a part
{
name = DoesItAll	the name of your part as referenced in game.
module = Part	this convention has been deprecated. Just use it as is, to make sure there are no errors with your part. There are some unusual parameters still in use for this convention.
author	You. This is the place to take credit for this part
MODEL {	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
mesh = DoesItAll.mu	specifies the mesh to be used
scale	not sure
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)

}

Title

Atop most part files are a couple of lines that resemble the ones below:

// Kerbal Space Program - Configuration file
// My super awesome engine that can go at a kajillion miles per hour, lol

These lines are useful when others want to learn from your part file.

The first line states that this file is a part file for KSP; the second states its name.

// Kerbal Space Program - Part CFG file
// Mark V Rocket Engine

Onwards!

General Parameters

// --- general parameters ---

This section follows the title and describes several properties of all parts. Below is a list of what goes under General Parameters:

name = solidBooster
//Leave this next line as is unless you have a reason
module = Part
author = Il Carnefice

name

It can be anything that is unique, one word, and without an underscore; it's not commented out because KSP will use this name internally (the user will not see this name) to refer to the part. Note that this is the name that the crash/damage reports give for a particular part, so it's advantageous for you to use something that corresponds closely to the actual part name.

module

This was used to describe the specific part class behavior but now this is handled by the Module tags later in the file. Set it to Part.

author

Author name

Below is an example:

// Kerbal Space Program - Part CFG file
// Mark V Rocket Engine

// --- General Parameters ---
name = LiquidThrusterV
module = Part
author = YourName

Parts

Part Name	Description
SolidRocket	Resembles a solid rocket booster - a continually burning rocket that lacks thrust control and cannot be deactivated once lit.
LiquidEngine	Resmebles an orbital maneuvering system - a rocket engine with controllable thrust.
FuelTank	Contains fuel.
CommandPod	Contains crew and a control system.
SASModule	Holds course.
SASModule2	???
Strut	Connects rocket parts. Has no special abilities.
Decoupler	Connects rocket parts and can jettison itself and the parts it's connected to.
RadialDecoupler	Connects and can jettison parts much as does a Decoupler, but radially.
Parachutes	Deploys a parachute.
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 fixed, lifting part.
Stabilizer	Similar to ControlSurface (recommend to not use)
StrutConnector	???
RCSFuelTank	A RCS tank.
RCSModule	A RCS thruster.
AtmosphericEngine	Atmospheric engine 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 via the right-click GUI.
DockingPort	An unfinished docking port?
FuelLine	Transfers fuel.
FuelTankGUI	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	An 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.

Part Modules

Please read: "0.15 code update - PartModule, KSPField, KSPEvent, ConfigNode and PartResource"

Asset Parameters

This section defines the assets of a module - it links to the model and texture file and provides extra settings.

// --- asset parameters ---
mesh = modelname.mu
scale = 0.1
rescaleFactor = 1.25

mesh

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.

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.

Below, the example:

// Kerbal Space Program - Part CFG file
// Mark V Rocket Engine

// --- General Parameters ---
name = LiquidThrusterV
module = LiquidEngine
author = YourName

// --- Asset Parameters ---
mesh = modelname.mu
scale = 0.1
rescaleFactor = 1.2

Node Definitions

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_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

Above are three example nodes. Two are useful in this tutorial: node_stack and node_attach. 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.

All node 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 indication 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_attach; they are only helpful in identifying a node's position.

// 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

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_exhaustLight_yellow = x, y, z, angx, angy, angz, active
fx_smokeTrail_medium = x, y, z, angx, angy, angz, active

Okay, looks pretty similar to node_definitions, right?

You'll notice, just like node definitions, there are separate parts to each effect. You have fx_exhaustFlame, fx_exhaustLight, and fx_smokeTrail.

There are exactly what they sound like, the flame, the light, and the smoke trail.

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.

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.

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.

// 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

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

Adding sound FX to our dummy part file:

// 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

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 ---
TechRequired = basicRocketry
cost = 450
category = Propulsion
subcategory = 0
title = 
manufacturer =
description = 

TechRequired

Tech node which must be unlocked for this item to appear in career and/or science game mode.

cost

This sets the cost for spaceship parts.

category

There are seven categories:

Module Name	Description
ModuleEngine	Engine?
ModuleAnimateHeat	???
ModuleLandingGear	Animated landing gear module?
ModuleCommand	Command module?
ModuleGenerator	Used by RTG, input/output resources.
ModuleResourceIntake	Generic resource "intake" module, to add to or take away from resource
ModuleAnimateGeneric	Animation?
ModuleScienceExperiment	Scientific experiment?
ModuleWheel	Rover wheel
ModuleLandingGear	Landing Gear
ModuleSteering	Adds steering to wheel
ModuleLight	Adds light to wheel

Category	Description
Pods	Command pods and cockpits go here
Propulsion	Engines, Fuel Tanks, RCS Tanks, etc.
Control	SAS modules, RCS Thrusters, etc.
Structural	Struts, decouplers, adapters, etc.
Aero	Wings, Control Surfaces and nose cones.
Utility	Parachutes, Escape towers, heat shields, lights, landing gear/legs, ladders, batteries, solar panels, generators, etc.
Science	Sensors, Antennae, Satellite Dishes, etc.

subcategory

No use yet. Set it to 0

title

What do you want your part to be called in the rocket editor?

manufacturer

Who built your part?

description

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)

And that's that. Updating the dummy cfg file now:

// Kerbal Space Program - Part CFG file
// Mark V Rocket Engine

// --- General Parameters ---
name = LiquidThrusterV
module = LiquidEngine
author = YourName

// --- Asset Parameters ---
mesh = modelname.mu
scale = 0.1 

// --- 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 = Propulsion
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

This defines how your part attaches to other parts.

• // 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

Easy enough, right? Adding to dummy file and continuing.

// 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 = Propulsion
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

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.

• mass =
• dragModelType = default
• maximum_drag =
• minimum_drag =
• angularDrag =
• crashTolerance =
• breakingForce =
• breakingTorque =
• maxTemp =
• heatConductivity =
• heatDissipation =
• stageOffset =
• childStageOffset =
• fuelCrossFeed =
• NoCrossFeedNodeKey =

mass - How much does your part weigh? (Or, for parts that also specify a dryMass parameter, how much does it weigh when full?)

dragModelType - Leave this as default.

maximum_drag - What's the maximum amount of drag on your part? (Usually under 1.) Generally drag when part's direction of travel is along its y-axis.

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) Generally drag when the part's direction of travel is perpendicular to its y-axis.

angularDrag - how much angular drag is there/resistance to turning? (Also usually under 1.)

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.

breakingForce - How much will the attachment between this part and the part it's connected to resist to linear forces?

breakingTorque - How much will the attachment resist rotational forces?

maxTemp - The maximum temperature your part can experience before exploding.

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.

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.

stageOffset and childStageOffset - Can be 0, 1, etc. 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. These replace stageBefore and stageAfter.

fuelCrossFeed - Will the part crossfeed fuel between parts attached to it?

NoCrossFeedNodeKey - if set to bottom will keep fuel from flowing FROM bottom nodes (avoiding some stack imbalances and partially mitigating the 0.15 bug of engines generating fuel). Used with parts with multiple bottom nodes, such as the TVR-1180C Mk1 Stack Tri-Coupler.

There you go, another section down.

Resources

Some parts contain a resource, such as SolidFuel.

RESOURCE
{  
name = SolidFuel  
amount = 433  
maxAmount = 433
}

The value entered in the RESOURCE node is what will appear in the in-game UI, but does not necessarily reflect a mass or volume. The game uses the resource's density defined in files with RESOURCE_DEFINITION nodes to calculate the mass of that resource in the given part. As an example, Squad's RT-10 Solid Fuel Booster's cfg defines its mass as 0.5, and the resource node says it hold 433 SolidFuel. The density of SolidFuel is defined by Squad as being 0.0075. Therefore:

Mass of RT-10+(resource amount*resource density)=0.5+(433*0.0075)=3.7475 tonne

which matches the in-game mass for this part.

The above is important to remember when making a part that will contain resources in that, if you set a resource's density first and want a part to hold a specific amount, you need to calculate the amount and not just enter the tonnes you want in the RESOURCE node. Regardless of how much mass that resource is, the in-game resource UI will always show the value in the RESOURCE node.

If using the default liquid fuel and the volume of the tank is known, the amounts of fuel and oxidizer can be calculated as follows (to agree with the amounts used in the default fuel tanks):

liquid fuel amount=(2,655,406*v)/27775 oxidizer amount=(86920*v)/1111 where v is the volume of the fuel tank in m^3. If the tank is a cylinder, v=pi/4*diameter^2*height

This was determined by solving the following system of equations,where x is the amount of oxidizer and y is the amount of liquid fuel: mass of fuel=y*.005 mass of oxidizer=x*.005 moxidizer/mfuel=2.2/1.8=1.22 (x*.005)/(y*.005)=1.22 equation 1: .005x-.00611y=0 equation 2: x+y=v*173.84 In order to agree with the amounts used in the default fuel tanks, the volume has to be multiplied by 173.84. The system of equations was solved using wolframalpha.com.

Dummy CFG

Dummy CFG:

// 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 = Propulsion
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

Specific Part Parameters

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.

You cannot mix and match parameters from different module types - it doesn't work.

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)

For example, if your part type (module) was SolidRocket, your specific part parameters would be composed of:

• thrust = 130
• dryMass = 0.36
• 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.

Liquid Engine

A liquid engine has the following special parameters:

• maxThrust =
• minThrust =
• heatProduction =
• fuelConsumption =

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:

maxThrust - The maximum thrust of the liquid engine.

minThrust - The minimum thrust. Usually 0, unless you want a rocket that can't fully be turned off.

heatProduction - How much heat your rocket puts out.

fuelConsumption - How much fuel your rocket uses.

Solid Rocket Booster

• thrust =
• dryMass =
• heatProduction =
• fuelConsumption =
• internalFuel =

• fullExplosionPotential =
• emptyExplosionPotential =

• thrustCenter = x, y, z
• thrustVector = angx, angy, angz

A lot of those values look pretty similar to the liquid engine parameters, right?

thrust - The thrust of the solid rocket booster. Note how there is no minimum thrust because it can not be turned off once lit.

dryMass - How much the SRB weighs when empty.

heatProduction - Exactly the same as the liquid rocket, how much heat your rocket puts up.

fuelConsumption - How much fuel the rocket uses per second.

internalFuel - How much fuel does the SRB hold inside it?

fullExplosionPotential - The potential for explosion when the rocket is full of fuel

emptyExplosionPotential - And the potential when it's empty.

thrustCenter - Where the thrust comes from.

thrustVector - And which direction it goes.

Fuel Tank

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 
// --- 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 = Propulsion
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

More Example?

// KSP - Parts
// Chemi Ion engine , using normal fueltank :D
// Mark I Ion engine
// 

// --- general parameters ---
name = ChemiIonEngine
module = LiquidEngine
author = Chemi | G-min
// --- asset parameters ---
mesh = CIonengMK1.dae

scale = 0.1
texture = hotsurf.png
specPower = 0.5
rimFalloff = 4
alphaCutoff = 0

// --- node definitions ---
node_stack_bottom = 0, 0, 0, 0, -1.0, 0, 1

node_stack_top = 0, 0.2, 0, 0, 1.0, 0, 1

// --- FX definitions ---
fx_exhaustFlame_yellow = 0, -0.05, 0, 0, 1.0, 0, active

fx_exhaustLight_yellow = 0, -0.05, 0, 0, 0, 0, active
fx_smokeTrail_medium = 0, 0, 0, 0, 1.0, 0, active
// --- Sound FX definition ---
sound_chemiionengine.wav = activate

sound_chemiionengine.wav = active
sound_vent_soft = deactivate

// --- editor parameters ---
cost = 1000

category = Propulsion
subcategory = 0
title = Chemi Ion engine MK1
manufacturer = Chemi Jet Propulson Laboratory / G-min Parts design
description = The great Ion engine :D

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,1,1,1,0
// --- standard part parameters ---
mass = 1.22

dragModelType = default 
maximum_drag = 0.399 
angularDrag = 0.4
crashTolerance = 29.16
breakingForce = 1024
breakingTorque = 567
maxTemp = 3100
heatConductivity = 3.6
heatDissipation = 0.014
// --- specific part parameters ---
maxThrust = 369

minThrust = 0
heatProduction = 58
fuelConsumption = 0.009
// end!

If you like and/or use this information, please stop by the Discussion section and leave a comment. It makes me feel better about doing all this work, and frankly, if someone doesn't do it soon, I'm just gonna stop and keep this all to myself. Yeah, you could figure it all out on your own, but let me tell you...from putting it together myself, it's a real pain in the tookus.

Each Configuration file is comprised 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 {},

General Parameters

Name

"name = " 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

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

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

StrutConnector has the additional properties of linearStrength, angularStrength and maxLength. This method is used on the stock Strut Connector

Winglet

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

model

[model] specifies the model file name used when representing this part in-game

scale

texture

Asset Parameters

mesh

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

unknown. Assumed to affect mods such as TweakScale.

iconCenter

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

node definitions

// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z

node_stack_top

node_stack_bottom

node_stack_connect01

node_stack_connect02

node_stack_connect03

node_attach

node_stack_bottom01

node_stack_bottom02

node_stack_bottom03

node_stack_bottom04

FX definitions

specifies a type of Special effects and the location relative to the part at which that effect is displayed, also includes a type as a 7th variable, probably referring to the state of the part (e.g.: power, flameout, running)

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_yellow

Sound FX definition

Paired sound types and part status left side specifies sound, right side specifies engine status.

Left Side options:

• sound_jet_low
• sound_jet_deep
• sound_vent_soft
• sound_vent_large
• sound_vent_medium
• sound_rocket_hard
• sound_rocket_mini
• sound_decoupler_fire
• sound_explosion_low
• sound_parachute_open
• sound_parachute_single

Right Side Options

• decouple
• engage
• running
• power
• disengage
• flameout
• activate
• activate
• deploy

editor paramaters

This is where the functional "meat and potatoes" gets started. Information here generally relates to acquisition of the part itself.

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
• 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

• experimentalRocketry
• nanolathing
• experimentalAerodynamics
• aerospaceTech
• experimentalElectrics
• experimentalScience
• automation (used by MechJeb)
• experimentalsMotors

entryCost

entryCost represents the amount Kerbits 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 Kerbits to attach a single instance of this part to your craft. It does not include resources available on your part (fuel tanks' costs are this cost plus the cost of the appropriate resource). cost has no use in Sandbox or Science modes, it is only used in Career mode.

category

Contrary to some opinions, parts are not organized in-game according to the folder that they are in in the Squad\parts\ directory. Rather, they are organized according to the category value assigned here. 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 six useable categories:

• Propulsion
• Aero
• Pods
• Structural
• Science
• Utility

Although, from the folder names provided, it seems that Squad is planning on expanding these options in a future release. My best guess is that the groupings will eventually be:

• Command
• Propulsion (possibly sub-divided)
• Aero
• Electrical
• Structural
• Utility
• Wheel

subcategory

subcategory is not currently in use as of [0.25.0]. 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.

stack

Boolean, 0 or 1: specifies whether this part stacks. Creates or requires an attachment node

srfAttach

Boolean, 0 or 1: specifies whether this part can attach to the surface of another part

allowStack

Boolean, 0 or 1: specifies whether another part can stack on this one. Creates or requires an attachment node

allowSrfAttach

Boolean, 0 or 1: specifies whether parts are allowed to attach to the surface of this part (at locations other than the nodes)

allowCollision

Boolean, 0 or 1: specifies whether this part is subject to collision physics

stackSymmetry

2 from standardNoseCone. Uncertain.

standard part parameters

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.

mass

[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.

dragModelType

[dragModelType] describes how your part interacts with drag forces. At present, the known [dragModelType]s include:

• default

maximum_drag

minimum_drag

angularDrag

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. Since Stock KSP doesn't use environmental heating, the only Stock heat sources are engine exhaust, and we will talk about how much heat engines produce later on. Once this value (expressed in degree Celsius {or degrees Kerbius, if you prefer}) 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. Unless you want them to blow up, that is. ~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 (Horizontal Decoupler Icon)
• LIQUID_ENGINE (Liquid Engines, or engines that have controllable thrust)
• SOLID_BOOSTER (Solid Rocket Boosters, or engines without controllable thrust)

stageOffset

• 1 - could be that this creates a new stage in the staging line-up
• -1 - used in parachutes...signals that activation of this object does not cause a staging effect?

childStageOffset

• 1 - could be that this mandates a new stage after this part in the staging line-up

explosionPotential

unknown purpose. Possibly for future use for random failures. Known values are numerical.

• 0.1
• 0 (BSLsnakprobe)

fuelCrossFeed

allows or restricts fuel moving through this part. Boolean argument: True or False.

NoCrossFeedNodeKey

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 paraments:

• 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

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 [MODULE]s share variables with other modules, which can make deciphering their purpose difficult.

known [MODULE]s, their associated variables, and the meanings of those variables will be explained below.

ModuleParachute

semiDeployedAnimation

specifies the animation to use in the semi-deployed state

• semiDeploySmall

fullyDeployedAnimation

specifies the animation to use in the fully deployed state

• fullyDeploySmall

invertCanopy

boolean, true or false, defaults to true. unknown purpose. true in parachuteMk1, true in parachuteMk2-R

autoCutSpeed

specifies the speed at which the parachute will be automatically cut, rendering it ineffective.

capName

• cap

canopyName

• canopy

stowedDrag

0.22 - specifies the drag effect while the parachute is still stowed

semiDeployedDrag

1 - specifies the drag effect while the parachute is in its semi-deployed state

fullyDeployedDrag

500 - specifies the drag effect while the parachute is in its fully deployed state

minAirPressureToOpen

0.01 - specifies the minimum Air pressure (or atmosphere) required for the parachute to enter its semi-deployed state

deployAltitude

configurable, sets the altitude above the planetary collision mesh at which the parachute will enter its fully deployed state

deploymentSpeed

1 - specifies the speed at which the parachute will enter its fully deployed state

semiDeploymentSpeed

1 - specifies the speed at which the parachute will enter its semi-deployed state

ModuleSAS

no known parameters. Possibly used a reference to determine whether this part is activated by the SAS function of the interface. ie. when you turn on SAS, turn on this part.

KerbalSeat

seatPivotName

seatPivot

ejectDirection

• 0, 1, 0.2

ModuleLandingGear

BrakeTorque

12

BrakeSpeed

3

ModuleSteering

controlAxisType

Forward

steeringAxis

0, 0, 1 - array of 3 numers

steeringTransformName

Steering

steeringLocked

true or false

steeringCurve

multi-array of keys, 0, 16 10, 9 30, 2 100, 1

FXModuleConstrainPosition

matchRotation

true or false

matchPosition

true or false

CONSTRAINFX

targetName

Steering

moversName

wheelCollider

ModuleLandingLeg

animationName

Deploy newlandingleg probeleg

wheelColliderName

wheelCollider

suspensionTransformName

Piston piston leg

orientFootToGround

boolean true or false

landingFootName

foot

alignFootUp

boolean true or false // Foot is aligned to up Axis instead of forward alignFootUp = true // Axis is aligned forward instead of up alignFootUp = false

suspensionUpperLimit

0.60, 0.47, 0.65

impactTolerance

300, 450, 150

suspensionSpring

1.25, 5, 1

suspensionDamper

1, 2, 1

suspensionOffset

0, 0.02, 0

RetractableLadder

ladderAnimationRootName

TelusBay Telescopic ladder

ladderColliderName

ladderCollider

ladderRetractAnimationName

Retract

ModuleReactionWheel

PitchTorque

numerical value, denotes amount of change can be applied to pitch using reaction wheel power

YawTorque

numerical value, denotes amount of change can be applied to yaw using reaction wheel power

RollTorque

numerical value, denotes amount of change can be applied to roll using reaction wheel power

RESOURCE

The resource used by reaction wheels in order to affect the changes they can produce

name

name of the relevant resource, typically ElectricCharge

rate

Rate of consumption, expressed in units/second at full usage.

ModuleScienceContainer

reviewActionName

Flavor text for reviewing the data contained in a science container.

storeActionName

Flavor text for placing data into a science container.

collectActionName

Flavor text for removing data from a science container.

evaOnlyStorage

Boolean, True or False Specifies whether or not data storage is restricted to EVA activities.

storageRange

Distance, expressed in meters, a Kerbal must be within in order to interact with data and this container.

allowRepeatedSubjects

Boolean, True or False

FlagDecal

textureQuadName

flagTransform: specifies whether there is a flag displayed on the exterior surface of the object.

ModuleScienceLab

containerModuleIndex

numerical, 0

dataTransmissionBoost

numerical, 1.5

crewsRequired

numerical, 2

canResetConnectedModules

Boolean, True or False

canResetNearbyModules

Boolean, True or False

interactRange

numerical, possible integers only, 5

REOURCE_PROCESS

name

names the resource required, e.g.: ElectricCharge

amount

specified, numerical, the number of units of the specified resource expended

FlagDecal

textureQuadName

flagTransform

ModuleJettison

specifies that pieces of this craft are able to be jettisoned, what they are and how to jettison them

jettisonName

node_fairing_collider fairingL fairingR fairing

bottomNodeName

bottom

isFairing

Boolean. True or False

jettisonedObjectMass

0.1, specifies the mass of the jettisoned object. It is uncertain, yet, if this mass is removed from the total mass of the vehicle. It is also uncertain if, when a fairing is added in vehicle assembly, this mass is added to the parent object.

jettisonForce

DeltaV with which the object is jettisoned from its parent object. Typically very low values, such as 1, 2 or 5

jettisonDirection

Three-dimensional array which specifies the direction of the jettisonForce relative to the original part, laterally is 0 0 1 and 0 0 -1, for example.

ModuleAlternator

Specifies that this part produced a resource, based on the percentage of thrust produced by the engine.

RESOURCE

name

name of the resource produced, usually ElectricCharge

rate

rate at which the resource is produced at 100% thrust, expressed in units/second

ModuleCommand

minimumCrew

Specifies the minimum number of crew needed to operate this module. Use 0 to specify a probe.

RESOURCE

If this Module requires a resource

name

This is the name of that resource

rate

and the rate in units/second of resource consumed

ModuleEnviroSensor

sensorType

• ACC
• PRES
• GRAV
• TEMP

ModuleControlSurface

dragCoeff

this value overrides the maximum_drag value 0.5 (advanced Canard)

deflectionLiftCoeff

0.7 (advanced Canard)

ctrlSurfaceRange

20 (advanced Canard)

ctrlSurfaceArea

0.95 (advanced Canard)

ModuleAnimateHeat

ThermalAnim

HeatAnimationEmissiveLiquidEngine3 HeatAnimationEmissiveTurbofan HeatAnimationEmissiveJet overheat

ModuleEngines

thrustVectorTransformName

unknown purpose. Known arguments:

• thrustTransform

throttleLocked

True or False, defaults to False. Used to create engines without controllable thrust.

exhaustDamage

True or False. assumed to indicate whether the exhaust from this engine will damage other parts.

ignitionThreshold

appears to not be used. Suggests a minimum thrust output value, below which the engine will no longer operate. Typical values are 0.1 (10%)

minThrust

Minimum thrust value. Engines will be considered 'off' at or below this value.

maxThrust

Just like the name implies, this is the maximum thrust a single unit of this module can produce. In order to create a more powerful engine, set this value higher.

heatProduction

a measure of the amount of heat energy produced per second. measured in degrees Kerbius (degrees Celsius)

fxOffset

3-dimensional vector coordinates specifying the location of thrust effects

useEngineResponseTime

True or False

engineAccelerationSpeed

0.2, 0.12

engineDecelerationSpeed

0.35, 0.21

allowShutdown

True or False, defaults to True. Specifies engines that cannot be turned off, regardless of whether their thrust can be controlled.

useVelocityCurve

True or False

PROPELLANT

resource utilized in the operation of this part, generally a fuel or other propellant. Engines may use multiple propellant types.

name

name of the resource consumed while this part is in operation

ratio

rate at which this resource is consumed, per second. Not to be confused with ratio relative to other propellants.

DrawGauge

Boolean value that indicates whether or not the 'fuel remaining' indicator in the staging selection is displayed or not.

atmosphereCurve

specifies variances in operational efficiency

key

uses two values to specify engine efficiency relative to the depth of the atmosphere (based on Kerbin sea-level!) First number indicates the relative pressure (0 = vacuum, 1 Kerbin sea-level), second numer indicates ISP value). Translates directly to ISP. In order to make a more efficient engine, set the second number of this array higher.

velocityCurve

uncertain as to how exactly this works, but appears to control the degree of acceleration at particular velocities. uses a 4 part key, the first part of the key is definitely specific accelerations, the second part is percentage of velocities. { key = 0 0.5 0 0 key = 1000 1 0 0 key = 2000 0.5 0 0 key = 2400 0 0 0 } { key = 1000 0 0 0 key = 850 0.2 0 0 key = 0 1 0 0 }

FXModuleAnimateThrottle

animationName

colorAnimation

depondOnEngineState

True or False

responseSpeed

0.5

ModuleEnginesFX

engineID

LES, KS25

runningEffectName

running_closed

thrustVectorTransformName

unknown purpose. Known arguments:

• thrustTransform
• obj_gimbal

exhaustDamage

True or False. assumed to indicate whether the exhaust from this engine will damage other parts.

throttleLocked

uncertain. Boolean values of True or False. Assumed to specify that solid Rocket Boosters cannot have their throttle adjusted while in flight.

ignitionThreshold

appears to not be used. Suggests a minimum thrust output value, below which the engine will no longer operate. Typical values are 0.1 (10%)

minThrust

Minimum thrust value. Engines will be considered 'off' at or below this value.

maxThrust

Just like the name implies, this is the maximum thrust a single unit of this module can produce.

heatProduction

a measure of the amount of heat energy produced per second. measured in degrees Kerbius (degrees Celsius)

fxOffset

3-dimensional vector coordinates specifying the location of thrust effects

PROPELLANT

resource utilized in the operation of this part, generally a fuel or other propellant.

name

name of the resource consumed while this part is in operation

ratio

rate at which this resource is consumed, per second. Not to be confused with ratio relative to other propellants.

DrawGauge

Boolean value that indicates whether or not the 'fuel remaining' indicator in the staging selection is displayed or not.

atmosphereCurve

specifies variances in operational efficiency

key

uses two values to specify engine efficiency relative to the depth of the atmosphere (based on Kerbin sea-level!) First number indicates the relative pressure (0 = vacuum, 1 Kerbin sea-level), second numer indicates ISP value).

ModuleGimbal

gimbalTransformName

thrustTransform

gimbalRange

represents the maximum angle, in degrees, that gimballing is supported. Recommend keeping this number relatively low (under 20 for sure), as setting the number too high can have catastrophic effects on ship design.

ModuleTestSubject

Used for the contract system, determines atmospheric conditions under which this part may be considered for testing. Also specifies whether the part is able to be tested using the Staging process or must be manually selected and "Perform Test" used to satisfy contract requirements.

environments

A single numerical value, between 0 (nowhere) and 15 (anywhere), that specifies the atmospheric conditions the part may be tested under. Add numbers together to specify multiple environments

• 0 = nowhere
• 1 = the surface of; srf
• 2 = the ocean of; ocean
• 3 = the surface or ocean of; srf, ocean
• 4 = the atmosphere of; atmo
• 5 = the surface or atmosphere of; srf, atmo
• 6 = the ocean or atmosphere of; ocean, atmo
• 7 = the surface, ocean or atmosphere of; srf, ocean, atmo
• 8 = the space above; space
• 9 = the surface or space above; srf, space
• 10 = the ocean or space of; srf, ocean, space
• 11 = the surface, ocean or space of; srf, ocean, space
• 12 = the space or atmosphere of; atmo, space
• 13 = the surface, space or atmosphere of; srf, atmo, space
• 14 = the ocean, space, or atmosphere of; ocean, atmo, space
• 15 = anywhere; srf, ocean, atmo, space

useStaging

Boolean True or False, specifies whether the part can be tested using the Staging Process

useEvent

Boolean True or False, specifies whether the part can be tested using the "Perform Test" action.

LaunchClamp

trf_towerPivot_name

obj_girdercap

trf_towerStretch_name

obj_girder

trf_anchor_name

obj_ground

trf_animationRoot_name

launchclamp

anim_decouple_name

launchclamp

ModuleGenerator

isAlwaysActive

specifies whether this module is always active or not. true/false

OUTPUT_RESOURCE

name

specifies the name of the produced resource.

rate

specifies the rate of resource produced, expressed in units per second.

ModuleDockingNode

A module for docking ports

referenceAttachNode

Specifies the node on the part that is used for the docking port, generally top or bottom

• top
• bottom

deployAnimationController

Boolean, 1 or 0

nodeType

Specifies the type of node for attachment. When perform docking operations, nodes must have the same value for nodeType in order to dock with one another.

• size1
• size2
• size0

controlTransformName

• controlNode = apparently only used for docking nodes that have related animations, see dockingPortInline

ModuleRCS

Note: ModuleRCS can use either a single resource, or a series of PROPELLANT calls.

thrusterTransformName

RCSthruster

thrusterPower

This is the power that the RCS thrusters provide. To make stronger RCS, use a higher numer

resourceName -------- interchangeable with PROPELLANT calls

The name of the resource used by the RCS thruster, typically MonoPropellant

resourceFlowMode -- for resourceName only --

Specifies the manner in which the resource is requested from the vessel

• STAGE_PRIORITY_FLOW
• STACK_PRIORITY_FLOW
• ALL_VESSEL
• NONE

PROPELLANT

Introduced with the inclusion of the Vernor RCS, it is recommended to use PROPELLANT calls only when using multiple resources. It is expected that older RCS will be updated to the new convention prior to final release.

name

name of the resource consumed

ratio

ratio of the resource consumed

resourceFlowMode

using the same pull method as a single resource, specifies how to pull the resource from the rest of the vessel

atmosphereCurve

Specifies the efficiency of the RCS thruster using 2-part keys 0 specifies the ISP in atmosphere 1 specifies the ISP at Kerbin Sea Level entries in between specify the ISP at specific percentages of Kerbin Sea Level (e.g: 0.5 = 1/2 Kerbin Atmosphere)

ModuleResourceIntake

used to create a part that produces a resource.

resourceName

defines the type of resource produced by this module. Any resource may be used for this purpose, including those not defined at all

checkForOxygen

An optional method that specifies this module must check to see if oxygen/atmosphere is present whenever attempting to generate the requested resource. true/false

area

area is the amount of space used for determining how much resource to produce. The larger the number, the more of the resource is produced per second.

intakeSpeed

unknown. Assumed to be a minimum m/s measure to determine if this module operates or not.

intakeTransformName

unknown. known arguments are:

• Intake

ModuleScienceExperiment

experimentID

• atmosphereAnalysis
• mysteryGoo
• crewReport
• seismicScan
• barometerScan

experimentActionName

Flavor text for contextual menu to describe to the player what the part does when collecting data

resetActionName

Flavor text for contextual menu to describe to the player what the part does when collecting data

reviewActionName

Flavor text for contextual menu to describe to the player what the part does when collecting data

useStaging

Boolean True/False - speficies whether this module can be activated through the normal staging system

useActionGroups

Boolean True/False - specifies whether this module can be activated by an Action Group

hideUIwhenUnavailable

Boolean True/False - specifies whether this module will show its activation buttons through the contextual menu, even if it is not available

rerunnable

Boolean True/False. Defaults to false.

xmitDataScalar

0.35

FxModules

0 (gooExperiment)

dataIsCollectable

Boolean True/False

collectActionName

Flavor text

interactionRange

The range, expressed in meters, from which a Kerbal on EVA can interact with this module (for example to reset the experiment)

ModuleGrappleNode

nodeTransformName

• ArticulatedCap

deployAnimationController

• 1

nodeType

• size1

captureRange

• 0.05

captureMinFwdDot

• 0.866

captureMaxRvel

• 1

ModuleLight

lightName

spotlight landinglight

useAnimationDim

true or false

lightBrightenSpeed

2.5

lightDimSpeed

2.5

resourceAmount

0.4

animationName

LightAnimation

useResources

true or false

useAutoDim

true or false

ModuleLiftingSurface

deflectionLiftCoeff

0.3 (BSLmk2ScienceFuselage)

dragAtMaxAoA

0.15 (BSLmk2ScienceFuselage)

dragAtMinAoA

0.1 (BSLmk2ScienceFuselage)

ModuleAnimateGeneric

animationName

• Deploy
• CrewCabinLight
• dish
• dockingring for dockingPortShielded
• dockingporthull for dockingPortInline

isOneShot

• false

startEventGUIName

Flavor text to describe turning the animation to its 'On' State

endEventGUIName

Flavor text to describe turning the animation to its 'Off' State

actionGUIName

Flavor text to describe switching the animation between it's 'on' and 'off' states

allowManualControl

true/false. Defaults to true.

ModuleDataTransmitter

packetInterval

0.18, 0.4, 0.3

packetSize

2, 2, 2

packetResourceCost

20, 10, 12.5

requiredResource

ElectricCharge

DeployFxModules

0

ProgressFxModules

1

FXModuleLockAtConstraint

FlagDecal

textureQuadName

• flagTransform

ModuleAsteroid

no procedures or calls

ModuleDeployableSolarPanel

animationName

unknown for sure. Assumed to refer to an animation describing part transformation from its closed state to its open state. known parameters are:

• solarpanels
• solarpanels2
• solarpanels4
• altsolarpanelbase
• bigsolarpanel

sunTracking

Boolean argument. unknown purpose. Assumed to indicate whether the animation will turn the panel towards the sun.

raycastTransformName

optional. unknown. Known arguments:

• suncatcher

pivotName

optional. unknown. Known arguments:

• suncatcher

isBreakable

optional. unknown purpose, assumed to indicate whether the part will break on high-dynamic stress. true or false

resourceName

the resource provided by this module. Any resource may be used, including resources not defined.

chargeRate

Amount of resource provided per second at 100% output. Positive values only, please.

powerCurve

powerCurve is a special call consisting of subtypes called [key]. Each [key] uses four numbers to define what it will do at a specific distance from a source. In the case of solar panels, where powerCurve is typically used, there are typically 4 [key]s. [powerCurve] defines the rate at which resources are provided relative to the [chargeRate] and distance from the specified source (ie. Kerbol)

• 206000000000 0.00 0 0
• 013599840256 1.00 0 0
• 068773560320 0.50 0 0
• 000000000000 10.0 0 0

ModuleWheel

hasMotor

true or false

resourceName

ElectricCharge

resourceConsumptionRate

1.0

canSteer

true

controlAxisType

Forward

steeringModeType

AutomaticSteer TankSteer

brakeTorque

300

brakeSpeed

1.2

impactTolerance

2000

overSpeedDamage

60

WHEEL

wheelName

wheel

wheelColliderName

wheelCollider

suspensionTransformName

suspensionTraverse

suspensionNeutralPointName

suspensionNeutralPoint

damagedObjectName

bustedwheel

rotateX

0

rotateY

1

rotateZ

0

steeringCurve

keys, 0 16 10 9 30 2

torqueCurve

keys 0 250 0 0 20 100 0 0 30 14 0 0 34 0 0 0

FXModuleLookAtConstraint

CONSTRAINLOOKFX

targetName

rotatorsName

FXModuleConstrainPosition

matchRotation

true or false

matchPosition

true or false

CONSTRAINFX

targetName

steering

moversName

lateral

ModuleAnchoredDecoupler

anchorName

anchor

ejectionForce

450

explosiveNodeID

specifies the location of the explosion.

srf

surface of the attachment

ModuleDecouple

isOmniDecoupler

true or false. Specifies whether this decoupler separates on both ends or not. Defaults to false.

ejectionForce

specifies the DeltaV with which the part separates

explosiveNodeID

for non-OmniDecouplers, specifics the Node of separation

• top
• srf

MODULES POSSIBLY FROM MODS

defining a module has it's own problems, of course, and I'm no expert, but I did find this along the way:

MODULE:NEEDS[KAS] for the module

KASModuleContainer

maxSize

specifies the size of the container relative to Kerbal Attachment System parts.

maxOpenDistance

sndStorePath

KAS/Sounds/hookBayStore

sndOpenPath

KAS/Sounds/containerOpen

sndClosePath

KAS/Sounds/containerClose

bipWrongSndPath

KAS/Sounds/bipwrong

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. For details of these cfgs, please refer to #REDIRECT INTERNAL cfgs. 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.

name

name of the resource being stored

amount

amount of the resource initially provided. When dragged from the parts list to your vessel, this is the amount of the resource that it attaches with

maxAmount

This is the maximum amount of the resource that this part can store. I haven't tried it myself, but I wouldn't recommend setting amount higher than this.

isTweakable

In the parts file, I believe this is what prevents you from filling the part prior to launch

hideFlow

Prevents display of motion of resource transfer. Not sure why this would be important.

RESOURCE_DEFINITION

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:

name

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.

density

[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

[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?)

flowMode

[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:

• STACK_PRIORITY_SEARCH
• NO_FLOW
• STAGE_PRIORITY_FLOW
• ALL_VESSEL

transfer

[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]:

• PUMP
• NONE

isTweakable

[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.

EFFECTS

Thrust

AUDIO

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