Difference between revisions of "CFG File Documentation"

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

@@ Line 1: / Line 1: @@
+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.
+== 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 [https://kerbalspaceprogram.com/api/class_config_node.html 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 [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].
 == Basic Part Making Guidelines ==
@@ Line 24: / Line 36: @@
 </pre>
-== Config file order ==
+== PARTS Configuration Files ==
-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").  DoesItAll will exist in this foldier:
+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>
@@ Line 50: / Line 62: @@
 | { ||
 |-
-| [[#Name|name]] = DoesItAll || the name of your part as referenced in game.
+| [[#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.
 |-
-| [[#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.
+| [[#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.
+* 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]] || You.  This is the place to take credit for this part
+| [[#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.
 |}
@@ Line 67: / Line 82: @@
 | MODEL { || opens the MODEL sub
 |-
-| [[#model|model]] || The name of the mesh. Write its name therein and keep the mesh file in the same directory as the part file.
+| model || The name of the mesh. Write its name therein and keep the mesh file in the same directory as the part file.
 |-
-| [[scale|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.
+| 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|texture]] ||
+| 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|MODEL]], you must use [[#mesh|mesh]] to define the parts collision mesh, like so:
+If you do not use [[#MODEL|MODEL]], you must use mesh to define the parts collision mesh, like so:
 {|class="wikitable"
@@ Line 80: / Line 95: @@
 ! Actual part !! Explanation
 |-
-| [[#mesh|mesh]] || The name of the mesh. Write its name therein and keep the mesh file in the same directory as the part file.
+| mesh || Mesh defines the mesh and texture package used to create the in-game appearance of your part.  Acceptable meshes include .mu files.
 |-
 |}
@@ Line 90: / Line 105: @@
 ! Actual part !! Explanation
 |-
-| [[#mesh|mesh]] = DoesItAll.mu || specifies the mesh to be used
+| [[#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
 |-
-| [[#scale|scale]] || not sure
+| [[#scale|scale]] || scale defines the size of your part.  I am uncertain as to what will happen when you change this value
 |-
-| [[#specPower|specPower]] ||
+| [[#specPower|specPower]] || Specific Power?  fuelLine
 |-
-| [[#rimFalloff|rimFalloff]] ||
+| [[#rimFalloff|rimFalloff]] || 3  fuelLine
 |-
-| [[#alphaCutoff|alphaCutoff]] ||
+| [[#alphaCutoff|alphaCutoff]] || Number: 0.0  fuelLine
 |-
 | [[#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]] ||
+| [[#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.
+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
@@ Line 127: / Line 155: @@
 ! Actual Part !! Explanation
 |-
 | [[#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).
+|}
 <pre>
 node_stack_bottom = x, y, z, angx, angy, angz, size
@@ Line 133: / Line 163: @@
 node_attach = x, y, z, angx, angy, angz, size
 </pre>
-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.
-|-
-|}
 === FX definitions ===
@@ Line 174: / Line 193: @@
 * fx_gasBurst_white
 * fx_exhaustSparks_flameout
+* fx_exhaustSparks_flameout_2
 * fx_exhaustSparks_yellow
+Module Parameters for PREFAB_PARTICLE and MODEL_MULTI_PARTICLE:
 {|class="wikitable"
 |-
-|+ Each fx call follows the same pattern
+! Variable !! Value !! Definition
+|-
+| prefabName || fx_exhaustFlame_blue || The name of the effect you want to use (See list above).
 |-
-! Actual Part !! definition
+| transformName || smokePoint || The name of the point defined in the Unity editor where the effect will appear from.
 |-
-| fx_exhaustFlame_blue_small = 0,0,0,0,0,0,0 ||
+| 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]]:
+<pre>
+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
+}
+</pre>
 === Sound FX definitions ===
@@ Line 212: / Line 264: @@
 Supported files are 48000&nbsp;Hz .wav files and .ogg
-Paired sound types and part status left side specifies sound, right side specifies engine status.
+These are the paired sound types and part statuses.
 {|class="wikitable"
 |-
-! Left Side options !! Right Side options
+! Sound !! Engine Status
 |-
 | sound_jet_low || decouple
@@ Line 250: / Line 302: @@
 | 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
@@ Line 297: / Line 349: @@
 * advScienceTech
 * advancedMotors
-The following Tech Tree nodes are present in stock, but not used unless called for by a mod
+The following Tech Tree nodes are present in stock, but not used unless called for by a mod.
-* experimentalRocketry
 * nanolathing
-* experimentalAerodynamics
+* experimentalMotors
-* aerospaceTech
+The following Tech makes a part unresearchable and unbuildable but does it not remove from existing ships
-* experimentalElectrics
+* Unresearcheable
-* experimentalScience
-* automation (used by MechJeb)
-* experimentalsMotors
 |-
-| entryCost ||
+| 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 || 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 ||
+| 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 || 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 || 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 || 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 || 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.
-This defines how your part attaches to other parts.
 *// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
@@ Line 352: / Line 408: @@
 === 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.
+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
 {|class="wikitable"
@@ Line 358: / Line 414: @@
 ! Actual Part !! Definition
 |-
-| mass = 1 || How much does your part weigh? (Or, for parts that also specify a dryMass parameter, how much does it weigh when full?)
+| 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 || [dragModelType] describes how your part interacts with drag forces.  At present, the known [dragModelType]s include:
+*default
 |-
-| maximum_drag ||
+| 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 ||
+| 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 ||
+| angularDrag || (could use clarification) how much angular drag is there/resistance to turning? (Also usually under 1.)
 |-
-| crashTolerance ||
+| 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 ||
+| 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 ||
+| 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 ||
+| 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 ||
+| 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.
+| 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 ||
+| explosionPotential || unknown purpose.  Possibly for future use for random failures.  Known values are numerical.
-|-
+* 0.1
-| fuelCrossFeed || Will the part crossfeed fuel between parts attached to it?
+* 0 (BSLsnakprobe)
-|-
-| 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]].
 |-
-| linearStrength ||
+| fuelCrossFeed || Will the part crossfeed fuel between parts attached to it?  allows or restricts fuel moving through this part.  Boolean argument:  True or False
 |-
-| angularStrength ||
+| 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
 |-
-| maxLength ||
+| 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.
 |-
-| vesselType ||
+| angularStrength || The amount of stress the given part can sustain without breaking, laterally.  Used for fuel lines and strut connectors
 |-
-| PhysicsSignificance ||
+| 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:
-=== MODULES ===
-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 ===
-  fuelLine
-=== alphaCutoff ===
-Number: 0.0  fuelLine
-=== rescaleFactor ===
-unknown.  Assumed to affect mods such as TweakScale.
-=== iconCenter ===
-,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 ==
-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
@@ Line 724: / Line 471: @@
 * 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:
+| 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 ===
-Known values:  1
+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]
-<span id="MODULES"></span>
+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 ]] {},
-== 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'''
+<span id="MODULES"></span>
-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.
+[[ 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.
+'''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.
-=== ModuleParachute ===
+known [[ Module| MODULE]]s, their associated variables, and the meanings of those variables will be explained below.
-==== 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 ====
-.22 - specifies the drag effect while the parachute is still stowed
-==== semiDeployedDrag ====
-- specifies the drag effect while the parachute is in its semi-deployed state
-==== fullyDeployedDrag ====
-- specifies the drag effect while the parachute is in its fully deployed state
-==== minAirPressureToOpen ====
-.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 ====
-- specifies the speed at which the parachute will enter its fully deployed state
-==== semiDeploymentSpeed ====
-- specifies the speed at which the parachute will enter its semi-deployed state
+{|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
+|-
+|}
-=== ModuleSAS ===
+=== INTERNAL ===
-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.
+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:
-=== KerbalSeat ===
-==== seatPivotName ====
-seatPivot
-==== ejectDirection ====
-* 0, 1, 0.2
-=== ModuleLandingGear ===
-==== BrakeTorque ====
-==== BrakeSpeed ====
-=== ModuleSteering ===
-==== controlAxisType ====
-Forward
-==== steeringAxis ====
-, 0, 1 - array of 3 numers
-==== steeringTransformName ====
-Steering
-==== steeringLocked ====
-true or false
-==== steeringCurve ====
-multi-array of keys,
-, 16
-, 9
-, 2
-, 1
-=== FXModuleConstrainPosition ===
-==== matchRotation ====
-true or false
-==== matchPosition ====
-true or false
-==== CONSTRAINFX ====
-===== targetName =====
-Steering
-===== moversName =====
-wheelCollider
-=== ModuleLandingLeg ===
+* crewCabinInternals
-==== animationName ====
+* cupolaInternal
-Deploy
+* GenericSpace1
-newlandingleg
+* GenericSpace3
-probeleg
+* landerCabinInternals
-==== wheelColliderName ====
+* landerCabinSmallInternal
-wheelCollider
+* mk1CockpitInternal
-==== suspensionTransformName ====
+* mk1PodCockpit
-Piston
+* PodCockpit
-piston
-leg
-==== orientFootToGround ====
-boolean true or false
-==== landingFootName ====
-foot
-==== alignFootUp ====
-boolean true or false
-<nowiki>
- // Foot is aligned to up Axis instead of forward
- alignFootUp = true
-</nowiki>
-<nowiki>
- // Axis is aligned forward instead of up
- alignFootUp = false
-</nowiki>
-==== suspensionUpperLimit ====
-.60, 0.47, 0.65
-==== impactTolerance ====
-, 450, 150
-==== suspensionSpring ====
-.25, 5, 1
-==== suspensionDamper ====
-, 2, 1
-==== suspensionOffset ====
-, 0.02, 0
-=== RetractableLadder ===
+=== RESOURCE ===
-==== ladderAnimationRootName ====
+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.
-TelusBay
+{|class="wikitable"
-Telescopic ladder
+|-
-==== ladderColliderName ====
+! variable !! example !! explanation
-ladderCollider
+|-
-==== ladderRetractAnimationName ====
+| name || ElectricCharge || Name of the resource being stored.
-Retract
+|-
-=== ModuleReactionWheel ===
+| amount || 100 || Amount of the resource included when dragged out of the parts list.
-==== PitchTorque ====
+|-
-numerical value, denotes amount of change can be applied to pitch using reaction wheel power
+| maxAmount || 100 || Maximum amount of the resource that can be stored
-==== YawTorque ====
+|-
-numerical value, denotes amount of change can be applied to yaw using reaction wheel power
+| isTweakable || false || Allows/prevents modification of resource levels in editor.
-==== RollTorque ====
+|-
-numerical value, denotes amount of change can be applied to roll using reaction wheel power
+| hideFlow || true || Allows/prevents display of motion of resource transfer. Not sure why this would be important.
+|}
-==== RESOURCE ====
+=== EFFECTS ===
-The resource used by reaction wheels in order to affect the changes they can produce
+{|class="wikitable"
-===== name =====
+|-
-name of the relevant resource, typically ElectricCharge
+!variable ||explanation
-===== rate =====
+|-
-Rate of consumption, expressed in units/second at full usage.
+|| 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
+|}
-=== ModuleScienceContainer ===
+== Resource Configuration Files ==
-==== reviewActionName ====
+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:
-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 ====
+{|class="wikitable"
-Boolean, True or False
+|-
-Specifies whether or not data storage is restricted to EVA activities.
+! variable !! example !! explanation
-==== storageRange ====
+|-
-Distance, expressed in meters, a Kerbal must be within in order to interact with data and this container.
+| name ||
-==== allowRepeatedSubjects ====
+{|class="wikitable"
-Boolean, True or False
+! 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 ||
+|| 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.
+|}
-=== FlagDecal ===
+== Science Definitions Configuration Files ==
-==== textureQuadName ====
+{|class="wikitable"
-flagTransform:  specifies whether there is a flag displayed on the exterior surface of the object.
+|-
+! 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.
+|}
-=== ModuleScienceLab ===
+== Contracts Definitions Configuration Files ==
-==== containerModuleIndex ====
+{|class="wikitable"
-numerical, 0
+Contains a single call to STORY_DEF, which then allows for subsets
-==== dataTransmissionBoost ====
+|-
-numerical, 1.5
+! variable !! example !! explanation
-==== 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 ===
+== Contracts Configuration Files ==
-==== textureQuadName ====
-flagTransform
+== 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]
-=== ModuleJettison ===
+<pre style="white-space: pre-wrap">
-specifies that pieces of this craft are able to be jettisoned, what they are and how to jettison them
+// Agency mentalities
-==== jettisonName ====
+// * Commercial   [Increased financial stakes, both for success and failure]
-node_fairing_collider
+// * Competitive  [competes with companies which we have a negative standing towards, auto-added if any standings set][not impl]
-fairingL
+// * Conglomerate  []
-fairingR
+// * Startup   []
-fairing
+// * Cooperative  [not impl]
-==== bottomNodeName ====
+// * Ecomental   [not impl]
-bottom
+// * Economic   []
-==== isFairing ====
+// * Hasty    [-deadlines -expiry +rep]
-Boolean.  True or False
+// * Patient   []
-==== jettisonedObjectMass ====
+// * Industrial   [not impl]
-.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.
+// * Perfectionist  [not impl]
-==== jettisonForce ====
+// * Pioneer   [Makes agency more likely to offer a contract to something that's never been done before]
-DeltaV with which the object is jettisoned from its parent object.  Typically very low values, such as 1, 2 or 5
+// * Record    [Flags agency as a record-keeping organization, focuses on contracts about breaking existing records and doing new things]
-==== jettisonDirection ====
+// * Scientific   [Agency is more likely to offer science data gathering contracts][not impl]
-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.
+// * 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>
-=== 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 ===
+{|class="wikitable"
-==== 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 ===
+== Kerbal Configuration Files ==
-==== sensorType ====
+Defines what your Kerbals can do.  Contained in the Traits.cfg file.
-* ACC
-* PRES
-* GRAV
-* TEMP
-=== ModuleControlSurface ===
-==== dragCoeff ====
-this value overrides the maximum_drag value
-.5 (advanced Canard)
-==== deflectionLiftCoeff ====
-.7 (advanced Canard)
-==== ctrlSurfaceRange ====
-(advanced Canard)
-==== ctrlSurfaceArea ====
-.95 (advanced Canard)
+{|class="wikitable"
+|-
-=== ModuleAnimateHeat ===
+! variable !! example !! definition !! in code
-==== ThermalAnim ====
+|-
-HeatAnimationEmissiveLiquidEngine3
+| name ||
-HeatAnimationEmissiveTurbofan
+* Pilot
-HeatAnimationEmissiveJet
+* Engineer
-overheat
+* Scientist
-=== ModuleEngines ===
+|| describes the Kerbal's job || <pre>name = Pilot</pre>
-==== thrustVectorTransformName ====
+|-
-unknown purpose.  Known arguments:
+| title || Any text || Flavor text of the job ||
-* thrustTransform
+<pre> title = Engineer </pre>
-==== throttleLocked ====
+|-
-True or False, defaults to False.  Used to create engines without controllable thrust.
+| desc || Any text || Flavor text of job description || <pre>desc = Pilots provide assistance in flying the vessel.</pre>
-==== exhaustDamage ====
+|-
-True or False.  assumed to indicate whether the exhaust from this engine will damage other parts.
+| EFFECT { || Array of skills
-==== ignitionThreshold ====
+|| describes benefits to vessel for having a Kerbal with this job aboard
-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 ====
+<pre> EFFECT
-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 ====
--dimensional vector coordinates specifying the location of thrust effects
-==== useEngineResponseTime ====
-True or False
-==== engineAccelerationSpeed ====
-.2, 0.12
-==== engineDecelerationSpeed ====
-.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.
-<nowiki>
   {
-   key = 0 0.5 0 0
+   name = VesselScienceReturn
-   key = 1000 1 0 0
+   modifiers = 1.05, 1.1, 1.15, 1.2, 1.25
-  key = 2000 0.5 0 0
-  key = 2400 0 0 0
   }
-</nowiki>
+ EFFECT
-<nowiki>
   {
-   key = 1000 0 0 0
+   name = PartScienceReturn
-   key = 850 0.2 0 0
+   modifiers = 1.05, 1.1, 1.15, 1.2, 1.25
-  key = 0 1 0 0
   }
-</nowiki>
+</pre>
+|}
-=== FXModuleAnimateThrottle ===
+== Prop Configuration Files ==
-==== animationName ====
-colorAnimation
-==== depondOnEngineState ====
-True or False
-==== responseSpeed ====
-.5
-=== ModuleEnginesFX ===
-==== engineID ====
-<nowiki>LES, KS25</nowiki>
-==== runningEffectName ====
-<nowiki> running_closed </nowiki>
-==== 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 ====
--dimensional vector coordinates specifying the location of thrust effects
+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.
-==== PROPELLANT ====
+<pre>
-resource utilized in the operation of this part, generally a fuel or other propellant.
+PROP
+{
+  name = directionalKnob
+  MODULE
+  {
+    name = internalGeneric
+  }
+}
+proxy = 0, 0, 0,  0.0225, 0.0075, 0.0225,  0, 1, 0
+</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>
-===== name =====
+== Internals Configuration Files ==
-name of the resource consumed while this part is in operation
+== Strategies Configuration Files ==
+Contained in Strategies.cfg, used to describe the variable strategies available.  Each strategy opens with STRATEGY {
-===== ratio =====
+{|class="wikitable"
-rate at which this resource is consumed, per second.  Not to be confused with ratio relative to other propellants.
+! 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
+|| 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
+|}
-===== DrawGauge =====
+=== EFFECTS ===
-Boolean value that indicates whether or not the 'fuel remaining' indicator in the staging selection is displayed or not.
+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.
-==== atmosphereCurve ====
+{|class="wikitable"
-specifies variances in operational efficiency
+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>
+|}
-===== key =====
+{|class="wikitable"
-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).
+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>
+|}
-=== ModuleGimbal ===
+{|class="wikitable"
-==== gimbalTransformName ====
+CurrencyConverter
-thrustTransform
+|-
-==== gimbalRange ====
+! variable !! samples !! description !! in code
-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.
+|-
+| name ||
+* CurrencyConverter
+|| internal reference name || <pre>name = CurrencyConverter</pre>
+|-
+| input ||
+* Funds
+* Reputation
+* Science
-=== ModuleTestSubject ===
+|| specifies the input for the campaign || <pre>input = Funds</pre>
-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 ====
+| output ||
-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
+* Reputation
-* 0 = nowhere
+* Funds
-* 1 = the surface of; srf
+* Science
-* 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 ===
+|| specifies the outputs for the campaign || <pre>output = Reputation</pre>
-==== trf_towerPivot_name ====
+|-
-obj_girdercap
+| minShare || Float || specifies the minimum || <pre>minShare = 0.0</pre>
-==== trf_towerStretch_name ====
+|-
-obj_girder
+| maxShare || Float || specifies the maximum || <pre>maxShare = 1.0</pre>
-==== trf_anchor_name ====
+|-
-obj_ground
+| minRate || Float || specifies the minimum rate of conversion, based on slider values || <pre>minRate = 0.041667</pre>
-==== trf_animationRoot_name ====
+|-
-launchclamp
+| maxRate || Float || specifies the maximum rate of conversion, based on slider values || <pre>maxRate = 0.0520</pre>
-==== anim_decouple_name ====
+|-
-launchclamp
+| AffectReasons ||
-=== ModuleGenerator ===
+* ContractReward
-==== isAlwaysActive ====
+* ScienceTransmission
-specifies whether this module is always active or not.  true/false
+* ContractAdvance
-==== OUTPUT_RESOURCE ====
+* VesselRecovery
-===== name =====
+* VesselRollout
-specifies the name of the produced resource.
+* RnDPartPurchase
-===== rate =====
-specifies the rate of resource produced, expressed in units per second.
-=== ModuleDockingNode ===
+|| criteria for conversions || <pre>AffectReasons = ContractReward, ContractAdvance</pre>
-A module for docking ports
+|-
-==== referenceAttachNode ====
+| effectDescription ||
-Specifies the node on the part that is used for the docking port, generally top or bottom
+* gains
-* top
+* Income
-* bottom
+|| describes the type of return || <pre>effectDescription = Income</pre>
-==== 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
-specifies the ISP in atmosphere
-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
+== Department Configuration Files ==
+Used in the Strategies system, these specify the Departments available that provide different strategies for use.
-=== ModuleScienceExperiment ===
+{|class="wikitable"
-==== experimentID ====
+|-
-* atmosphereAnalysis
+! variable !! samples !! description !! in code
-* mysteryGoo
+|-
-* crewReport
+| name ||
-* seismicScan
+* Finances
-* barometerScan
+* Science
-==== experimentActionName ====
+* Public Relations
-Flavor text for contextual menu to describe to the player what the part does when collecting data
+* Operations
-==== resetActionName ====
+|| The department name || <pre>name = Public Relations</pre>
-Flavor text for contextual menu to describe to the player what the part does when collecting data
+|-
-==== reviewActionName ====
+| desc || Flavor Text || describes the department || <pre>
-Flavor text for contextual menu to describe to the player what the part does when collecting data
+desc = Linus is Wernher Von Kerman's Intern.
-==== useStaging ====
+Because Wernher himself is too important to be
-Boolean True/False - speficies whether this module can be activated through the normal staging system
+bothered with these boring strategy meetings.
-==== useActionGroups ====
+He sends his intern in his stead.</pre>
-Boolean True/False - specifies whether this module can be activated by an Action Group
+|-
-==== hideUIwhenUnavailable ====
+| color || array of 3 numbers between 0 and 255 || specifies the color of the department || <pre>color = 149 254 135</pre>
-Boolean True/False - specifies whether this module will show its activation buttons through the contextual menu, even if it is not available
+|-
-==== rerunnable ====
+| avatar ||
-Boolean True/False.  Defaults to false.
+* Strategy_MechanicGuy
-==== xmitDataScalar ====
+* Strategy_PRGuy
-.35
+* Strategy_ScienceGuy
-==== FxModules ====
+* Strategy_Mortimer
-(gooExperiment)
+|| Internal name of the Department Head || <pre>avatar = Strategy_PRGuy</pre>
-==== dataIsCollectable ====
+|-
-Boolean True/False
+| headName ||
-==== collectActionName ====
+* Mortimer Kerman
-Flavor text
+* Linus Kerman
-==== interactionRange ====
+* Walt Kerman
-The range, expressed in meters, from which a Kerbal on EVA can interact with this module (for example to reset the experiment)
+* Gus Kerman
+|| Flavor Text for the Department Head || <pre>headName = Walt Kerman</pre>
-=== ModuleGrappleNode ===
+|-
-==== nodeTransformName ====
+| headImage ||
-* ArticulatedCap
+* MORTIMER_KERMAN
-==== deployAnimationController ====
+* SCIGUY_KERMAN
-* 1
+* PRGUY_KERMAN
-==== nodeType ====
+* PRGUY_KERMAN
-* size1
+|| animation file name for the Head shot of the Department Head featured in the strategy selection screen|| <pre>headImage = PRGUY_KERMAN</pre>
-==== captureRange ====
+|}
-* 0.05
-==== captureMinFwdDot ====
-* 0.866
-==== captureMaxRvel ====
-* 1
-=== ModuleLight ===
-==== lightName ====
-spotlight
-landinglight
-==== useAnimationDim ====
-true or false
-==== lightBrightenSpeed ====
-.5
-==== lightDimSpeed ====
-.5
-==== resourceAmount ====
-.4
-==== animationName ====
-LightAnimation
-==== useResources ====
-true or false
-==== useAutoDim ====
-true or false
-=== ModuleLiftingSurface ===
-==== deflectionLiftCoeff ====
-.3 (BSLmk2ScienceFuselage)
-==== dragAtMaxAoA ====
-.15 (BSLmk2ScienceFuselage)
-==== dragAtMinAoA ====
-.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 ====
-.18, 0.4, 0.3
-==== packetSize ====
-, 2, 2
-==== packetResourceCost ====
-, 10, 12.5
-==== requiredResource ====
-ElectricCharge
-==== DeployFxModules ====
-==== ProgressFxModules ====
-=== 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 ====
-.0
-==== canSteer ====
-true
-==== controlAxisType ====
-Forward
-==== steeringModeType ====
-AutomaticSteer
-TankSteer
-==== brakeTorque ====
-==== brakeSpeed ====
-.2
-==== impactTolerance ====
-==== overSpeedDamage ====
-==== WHEEL ====
-===== wheelName =====
-wheel
-===== wheelColliderName =====
-wheelCollider
-===== suspensionTransformName =====
-suspensionTraverse
-===== suspensionNeutralPointName =====
-suspensionNeutralPoint
-===== damagedObjectName =====
-bustedwheel
-===== rotateX =====
-===== rotateY =====
-===== rotateZ =====
-==== steeringCurve ====
-keys, 0 16
-9
-2
-==== torqueCurve ====
-keys
-250 0 0
-100 0 0
-14 0 0
-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 ====
-==== 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
-[[Category:Tutorials]][[Category:Documentation]]
+[[Category:Tutorials]]
+[[Category:Documentation]]
+[[Category:Modding]]

Difference between revisions of "CFG File Documentation"

Latest revision as of 06:31, 2 January 2022

Contents

Config Format

Module Manager

Basic Part Making Guidelines

PARTS Configuration Files

General Parameters

Model Parameters

Asset Parameters

Node Definitions

FX definitions

Sound FX definitions

Editor Parameters

Attachment rules

Standard Part Parameters

MODULES

INTERNAL

RESOURCE

EFFECTS

Resource Configuration Files

Science Definitions Configuration Files

Contracts Definitions Configuration Files

Contracts Configuration Files

Agent Configuration Files

Kerbal Configuration Files

Prop Configuration Files

Internals Configuration Files

Strategies Configuration Files

EFFECTS

Department Configuration Files

Navigation menu

Search