Difference between revisions of "User:Greys"

From Kerbal Space Program Wiki
Jump to: navigation, search
(Duplicated CFG_File_Documentation, removed dummy file code blocks, added Outdated markers and comments designated by Ø symbols)
 
(A little out of date, but still useful)
 
(47 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Outdated|Does not include the new 0.18 or 0.20 config format changes}}
+
{{Box|type=warning| This page is being broken up into separate pages for more specific topics
{{Box|This document is presented as a tutorial when, as suggested by the page title, it should be a reference.}}
+
[[User:Greys/The_CFG_File_and_ConfigNodes|The CFG File and ConfigNodes]]
At first glance, the configuration file for an addon is a pretty confusing and infuriating thing. This tutorial will walk through the individual parts of the configuration file and hopefully give you an idea what everything does. As we go along, we'll build up a dummy part file that will behave exactly like a real one, only lacking models, sounds, and textures.
+
[[User:Greys/GameData_and_Assets| GameData and Assets]]
 +
some organization of pages dedicated to singular top level confignodes such as PART
 +
}}
 +
{{Box|Does not include the new 0.18 or 0.20 config format changes
 +
*Gamedata addressed
 +
*Config Nodes addressed
 +
*partModules not addressed
 +
*module deprecation partially addressed}}
 +
{{Box|*Ø comments indicate notes on existing content that is incorrect or inadequate, and will need to be addressed
 +
*þ comments are formatting or structural changes that need to be made}}
 +
= Conventions =
 +
KSP's cfg format can be difficult to converse about without getting into how the code works because the format is a direct reflection of the code, but also because it's not very regular and a lot of labels get used repeatedly for different meanings while a lot of meanings get labeled differently in various places; all the while there are misnomers abound and piles of deprecated things that may or may not still work.
  
== Basic Part Making Guidelines ==
+
In it's most basic form the structure of a cfg file is as follows
{{Outdated|None of this information is currently accurate}}
 
Before you delve into the part file, it's important that you make sure you check through your model for anything that might break the game on loading, but isn't related due to a CFG error.
 
Before you start editing the part, make sure that:
 
  
* The file is a .dae file. (For me, a .obj file simply doesn't work in game, and others have been saying the same thing. For convenience's sake, stick to .dae)
+
<pre>
:Ø .dae files are considered a legacy mode
+
Node
* That every single mesh has a material, even the collision mesh.
+
{
:Ø Collision mesh nolonger require a material, or even a renderer to hold the material
+
Field = Value
* That you've named the parts correctly. The collision mesh should always be called "node_collider", etc.
+
}
:Ø Collision mesh can be named anything you want as long as they have a mesh collider component
+
</pre>
<br />
 
  
:These considerations only apply when dealing with the .dae legacy mode
+
All cfg structures can be represented as this. Nodes can be in other nodes but fields must be in a node. More specifically Nodes, such as PART, RESOURCE_DEFINITION, and MODULE, only exist in certain contexts. PART does not work inside another PART and MODULE does not work outside of PART. From there Fields hold Values, but those values have to be asked for by the code or they never get loaded. As well, Nodes must be asked for by the code, they don't do anything without a code counterpart. Node names and Field names are '''Case Sensitive''', if they are spelled wrong or in the wrong case they will not exist as far as the code cares. For the purposes of this article we will be referring to the organization of things in code in a format similar to the code, Node.Field=value, in example: PART.MODULE.name="ModuleWheel", though it can be easier to shorten that to PART.ModuleWheel.name, the value of which is "ModuleWheel". Keep in mind that the shorthand is technically incorrect
  
== Part file creation ==
+
In the code, the allowable contents of a Field are quite specifically defined based on C# Types. Predominantly you will see string, int, and float, and if the data does not match the necessary type it will likely cause some kind of crash. One example is PART.cost, cost is an int or integer, in past versions of KSP cost would fail if given a value that is not an int, such as a float such as 4.7 or a string such as 4,000 (the comma makes it a string or text value). This has been fixed now, but previously giving it a bad value would cause an exception that immediately ended the loading process, causing KSP to skip over all following values in that part, but also all parts following, and go straight to the landing screen with the Kerbal floating around.
{{Outdated|File name and directory location considerations have changed and should be explained}}
 
Okay, now that's out the way we can start looking into Part files, and how they work. Although it looks pretty confusing at first glance, it's actually a pretty simple ordeal to create one. To start, we're going to actually need an empty file in the right location.
 
  
*Fire up notepad
+
It is also important to note that the way things are organized in the cfg does not strictly reflect how they are organized into code. Again for example PART.cost. In code this information gets placed into Part.partInfo.cost, where partInfo is an instance of AvailablePart, so really cost is found at AvailablePart.cost. Reflecting the organization of the code helps to a degree, but a perfect replication is neither the goal or particularly useful.
*Save it as "part.cfg" in the directory of your addon
 
:Ø File name does not have to be "part" anymore
 
** Usually "../KerbalSpaceProgramDirectory/Parts/yourAddon"
 
:Ø /KSP/Parts/ is considered a legacy mode folder, parts that use it will not have the config options added in 0.20 available to them
 
<br />
 
  
There, you now have an empty file waiting for juicy bits of configuration to be stuck into it. So let's keep going.
+
= GameData =
 +
{{Box|'''Tentatively complete:''' I believe this section to be complete aside from inconsistent terminology and refining the exact text. Please discuss on the talk page if you have concerns or things to add}}
 +
All add-on files should be placed in the GameData folder, located in the root KSP folder alongside the KSP executable. Everything related to a given Add-on should be contained within a folder created specifically for that Add-on. Inside the dedicated folder, the directory structure is largely unimportant.
  
=== Config file order ===
+
All of the stock parts are contained within GameData as well, and Squad uses this structure:
{{Outdated|This section is and has always been entirely false, order has never been significant}}
+
<pre>
 +
/Flags/            -- Flags must go here or they won't be loaded as flags, Capitalization Matters
 +
/Parts/Aero/      -- Aerodynamic parts
 +
/Parts/Command/    -- Command pods, probe cores, and reaction wheels
 +
/Parts/Electrical/ -- Parts that create and store electricity
 +
/Parts/Engine/    -- Engines
 +
/Parts/FuelTank/  -- Fuel Tanks
 +
/Parts/Structural/ -- Parts that don't do anything, and don't contain resources
 +
/Parts/Utility/    -- Parts that do things and don't contain resources (except some of them do)
 +
/Parts/Wheel/      -- Things that roll
 +
/Props/            -- Props are the functional little elements in IVAs
 +
/Resources/        -- This folder contains the file that declares all of the stock resources
 +
/Sounds/          -- Can you hear the love tonight
 +
/Spaces/          -- Spaces are IVAs
 +
</pre>
 +
(This is just the way Squad does it, you can do it any way you want)
  
The part.cfg file has a pretty much specific order in which things are done. The order is:
 
  
<pre>
+
All assets will be loaded in a depth first alphabetic order, in sets based on file type. Parts will be displayed in the order they are loaded in.
// Title
+
Because of this parts located in /GameData/Squad/Parts/Utility/ will always be listed before those in /GameData/Squad/Parts/Wheel/, even if the wheel part's name is before the utility part's name alphabetically.
// Name of your part
 
//  
 
  
// --- general parameters ---
+
Aside from load order, the directory structure of /GameData/YourFolder/ only serves as an organizational tool for the developer.
  
// --- asset parameters ---
+
== .CFG Files ==
 +
{{Box|'''Tentatively complete'''}}
 +
File type .cfg is used for every configuration file in KSP except persistence files, which are stored in .sfs, these files are simply disk-storable containers for Config Nodes and as such their names and locations are almost entirely insignificant. Each .cfg file will be addressed in depth-first alphabetical order based on it's position within /GameData/, relative to other .cfg files, and that is the extent of the value that a file's name has.
  
// --- node definitions ---
+
It is entirely possible to merge all of the top level config nodes of a given add-on pack into a single file, but this is likely to make working with that file much more difficult. It's generally accepted that the best practice is to have a single top level config node per file, or put a small number of closely related parts in a single file. For example, if you have a command pod you could have the PART{}, INTERNAL{}, any custom PROP{}s and any custom RESOURCE_DEFINITION{}s in a single file, but as far as KSP is concerned, having a part.cfg, internal.cfg, props.cfg, etc, in one folder is functionally the same thing.
  
// --- FX definitions ---
+
Note that the .cfg file is not loaded into RAM. The config nodes in it are used to build code objects, and the variables are populated into those objects. As such, reducing the total number of files has zero impact on RAM usage.
  
// --- Sound FX definition ---
+
== Model Assets ==
 +
{{Box|Goals:
 +
* Improve formatting
 +
* Include relevant links
 +
* Address Transform relevancy}}
 +
There are only two model formats which KSP will load without outside forces, .MU, and .DAE
  
// --- editor parameters ---
+
* '''.DAE''' is a legacy mode option and should not be used for a multitude of reasons, the first is that .DAE is much more complex to set up, and more finicky about what will work. You also don't have a lot of the options that you would have with .mu
 +
* '''.MU''' is a compiled model format developed by our holy father Mu produced in Unity using PartTools. .MU files permit a large number options to be applied and changed, and stored inside the model itself. These include animations, manipulations to the texture sheets, customized and primative colliders, control over the shaders used on a part, and the inclusion of Transforms.
  
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
+
þ make 'Unity' and 'PartTools' links, give PartTools it's own page?
  
// --- standard part parameters ---
+
þ Transforms are maybe not relevant to this text
  
// --- specific part parameters ---
+
A Transform is a Unity Game Object in a specific place and with a specific orientation that is referenced by code to achieve many things, the Gimbal Transform is used to move an engine's nozzle mesh, which is a child of the transform, and the Thrust Transform is used as the coordinates and orientation to apply force to a part, RCS thrusters also use transforms for this.
</pre>
 
  
So you'll notice those slashes in front of each title - that means that those lines have been '''commented out''' and so will not be read by Kerbal Space Program when it's loading your addon. From the point of view of the program, those lines don't exist. As we go through the tutorial, we'll build up the CFG file from its bare bones to an actual working configuration file.
+
Model assets can be located anywhere within /GameData/ and referenced by their address from .cfg files using MODEL{}, if not using MODEL{} they need to be in the same folder as the .cfg file.
  
=== Give your part a title ===
+
== Texture Assets ==
{{Outdated|this section serves no purpose and may be misleading}}
+
{{Box|Goals:
If you look at the very, very top of most part files you'll notice a couple of lines that look like this:
+
* Improve formatting
 +
* Suggest and link to some free graphics editors}}
 +
þ Phrasing may be confusing, perhaps omit that Unity can natively handle texture formats KSP doesn't recognize
 +
There are a lot of kinds of textures which can be used in KSP but only 3 formats are currently accepted by the loader, .MBM, .TGA, and .PNG
  
<pre>
+
Once loaded the format you choose '''Does Not Matter''', KSP will convert everything into DXT1 or DXT5 depending on the presence of an alpha channel (transparency), both of which are lossy formats. Both formats are direct bits-per-pixel formats so the actual content of those pixels is unimportant but because DXT5 has an alpha channel, it is directly twice as large as DXT1. KSP chooses the format based on the image so make sure you don't have unnecessary alpha channels.
// Kerbal Space Program - Configuration file
 
// My super awesome engine that can go at a kajillion miles per hour, lol
 
</pre>
 
  
Those are quite simply, unimportant lines to KSP. The program doesn't read them, and doesn't give a crap about them either way. However, they are useful when other friendly people want to <s>steal your work</s> learn from your part file.
+
* '''.TGA''' and '''.PNG''' are both editable, '''.MBM''' is technically editable, but it is not a format that graphics editing software will know what to do with, and you'll have to edit some stuff by hand before it can be opened.
 +
* '''.MBM''' is uncompressed, and '''.TGA''' has very little compression but is a lossy format.
 +
* '''.PNG''' is a very well compressed lossless format that allows for an alpha channel.
  
The first line simply states that this is a part file for KSP, and the second line is simply the name you give your part to other people to identify it.
+
To repeat, the format of your files does not matter in game, it only impacts the amount of Data On Disk and the time it takes to read that data off the disk.
  
So let's start creating our dummy CFG file.  
+
There are various programs available to edit PNG and TGA images like [http://www.getpaint.net/ Paint.NET] or [http://www.gimp.org/ GIMP]. While Paint.NET's interface is easier that GIMP's, GIMP is not only available for Windows but also for Linux and Mac OS X.
  
 +
== Sound Assets ==
 +
{{Box|Goals
 +
* Find someone who knows how this works
 +
* Make them write this section}}
 +
They're not broken, they're just weird.
  
Onwards!
+
= Config Nodes =
 +
{{Box|Goals:
 +
* Suggest reviewing stock cfg files and the files of addons}}
 +
(Note to plugin developers, this document only pertains to .cfgs)
 +
Starting in KSP 0.15 a .cfg structure known as Config Nodes was introduced, and later in KSP 0.20.0 alongside the game database system and /GameData/ directory structure. Config Nodes, generally seen as any string of upper case letters, numbers<sup><small>[confirmation needed]</small></sup> and underscores followed by an opening curly bracket ( { ) and later a closing one are a means of having more complexly organized data inside a part's configuration.
  
== General Parameters: ==
+
Prior to KSP 0.20.0 all parts had to exist by themselves in a file specifically named 'part.cfg', limiting any one folder to containing only one part, and due to restrictions on addressing assets, every part had to have it's own textures and models.
{{Outdated|module is depreciated except for a small number of modules which have not yet been replaced with a partModule}}
 
Now, let's look at the next section of the file - the general parameters.
 
  
<pre>// --- general parameters ---</pre>
+
Following the release of KSP 0.20.0 parts must exist inside a .cfg file with any name, and must be wrapped in a PART{} config node. You are permitted to have multiple PART{}s in any given file, and the means of addressing assets has changed to be relative, treating /KSP/GameData/ as the root of any address.
This section comes straight under your title, and provides a few general things that apply to all parts. Here's a list of what goes under General Parameters:
 
  
 +
Between the curly brackets of a config node you are able to define variables, their values, and other config nodes so long as they exist in that context.
 +
For an example:
 
<pre>
 
<pre>
name = solidBooster
+
PART{
module = SolidRocket
+
    name = Example
:module SolidRocket is depreciated
+
    title = Superfly
author = Il Carnefice
+
    description = These are variables, they are case sensitive and the code defines what that case is
 +
    you = can define anything you want, but the code in game is only going to use what it needs.
 +
    banana = is a fully valid variable, that will not be used by anything in KSP
 +
    not = every key or config node uses a reliable capitalization scheme so if you're having problems, double check your case
 +
 
 +
    RESOURCE{
 +
        name = LiquidFuel
 +
        amount = 400
 +
    }
 +
    MODULE{
 +
        name = etc
 +
    }
 +
}
 
</pre>
 
</pre>
 +
It is important to note that everything in KSP is Case Sensitive, from the variables and values in a .cfg file, to the names of asset files and folders. The capitalization scheme of keys and config nodes is defined entirely by the code that will use it, RESOURCE{} and Resource{} are not the same thing, and the later will do nothing, but also RESOURCE{Name=LiquidFuel} is not valid. Unfortunately within KSP there is no singular capitalization scheme to fall back on. "Generally" Config Nodes are in ALL CAPS, sometimes they're in lowerCamelCase, but you always have to follow the code, or it won't work.
  
Pretty easy, huh? No? Still a bit muddled? Okay, explanation time.
+
Proper tabulation in .cfg files is not necessary, but extremely useful in maintaining readability of complex configurations and will help to make sure all your config nodes are closed properly.
 +
== Keys ==
  
;name
+
The order of keys in a .cfg file is completely unimportant. All config nodes and keys are loaded in one solid step, before any other code is given the chance to access the data, as such all of the information in a .cfg file is available to the code immediately. It will not occur that one thing doesn't load right because some piece of information has not been loaded yet. Organize your configurations as you see fit.
:This is just that, a name. It can be anything, but notice that it's ''NOT'' commented out. This is what KSP will refer to the part as internally. It's good form to keep it all one word. Don't worry, you won't see it called this in game, so it can honestly be anything. Must be unique and cannot contain the underscore.
 
:Ø or spaces
 
;module
 
:Now this is slightly more difficult. Each part can be one of several different types of parts, defined by what comes after module. What type the part is defines how it works - for example, a solid rocket booster behaves differently from a liquid rocket motor. See [[#Parts|Valid Part Modules]] for values you can use here.
 
;author
 
:Put your name here, you're the author!
 
  
So let's get on with our dummy file.
+
What does matter is the kinds of information that the code expects a key to contain.
 
+
Also, Capitalization Always Matters. In both Keys and Values, if it's not capitalized the right way, it won't do what you want. This becomes problematic because KSP's capitalization scheme is rather inconsistent.
 
 
There we go, a liquid engine type part, by proud author YourName.
 
 
 
==== Parts ====
 
{{Outdated|Nearly all modules have been depreciated and replaced with partModules which offer more control
 
So what part types can you have?
 
  
 +
þ This table will likely need multiple revisions to achieve an optimal representation of the truth in a form that conveys the information adequately.
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Part Name
+
! Data Type !! Something !! Example
! Description
 
 
|-
 
|-
! [[Parts#Solid Fuel Boosters|SolidRocket]]
+
| Integer || A Number without decimal values and without any formatting || 40008
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Liquid Fuel Engines|LiquidEngine]]
+
| Float || A number with decimal values but still no formatting || 40.008
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Liquid Fuel Tanks|FuelTank]]
+
| Text || Plain text || Hi, my name is Guacamole, and I'm stealing your car right now.
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Pods|CommandPod]]
+
| Identifier || A set of letters and numbers, capital or lower case, without spaces or punctuation (exceptions...) || SmallGearBay
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#S.A.S.|SASModule]]
+
| Address || An address relative to /KSP/GameData/ (always use /, never \) || /Squad/Parts/Engine/liquidEngine2-2/
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#S.A.S.|SASModule2]]
+
| List || A set of comma separated values, usually integers or floats || 0.00, 0.147, 0.00, 0.0, 1.0, 0.0, 1
| this module never did anything
 
 
|-
 
|-
! [[Parts#Adapters, Couplers & Struts|Strut]]
+
| Binary || A 0 or 1 indicating a yes or no to enable or disable certain things || 1
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Decouplers and Seperators|Decoupler]]
+
| Vector || A list of 3 values, X, Y, and Z, used to describe coordinates, orientations, and complex scales || 4.743, 7.853, 0.042
| this module has been depreciated and should not be used
+
|}
 +
 
 +
The format of defining a key and it's value is as follows regardless of the data being contained within it. No line end marker is necessary.
 +
<pre>
 +
Key = Value
 +
</pre>
 +
 
 +
The keys you set in a .cfg files don't fit into many clear cut groups, some related to visual assets, some relate to aspects of that part in the world, but most of them fit into several groups, are used at various levels, and don't really do quite what you think. In the following tables they've been roughly organized by category as a factor of what they do, not where they're used.
 +
 
 +
== Stock Config Nodes ==
 +
{{Box|Goals
 +
* Create table of keys for each node
 +
* Describe each node's function, and any nodular relationships
 +
* Describe glitches and limitations
 +
}}
 +
 
 +
'''Top Level Config Nodes'''
 +
{| class="wikitable"
 
|-
 
|-
! [[Parts#Decouplers and Seperators|RadialDecoupler]]
+
! Node !! Used For
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Parachutes|Parachutes]]
+
| PART{} || Defines a new part
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Controlled wings and surfaces|ControlSurface]]
+
| RESOURCE_DEFINITION{} || Defines a new resource to be used in and by PART{}s
| Movable wing-like surface. Can act as a rudder, aileron, elevator, canard or other aerodynamic control surface - function depends on placement on a ship.
+
|-
 +
| INTERNAL{} || Defines an internal space which can be used by PART{}s
 
|-
 
|-
! [[Parts#Propulsion|WarpEngine]]
+
| PROP{} || Defines an prop, a functional self contained element, which can be used in INTERNALS{}
| This module never did anything
+
|}
 +
 
 +
 
 +
=== PART{} Config Nodes ===
 +
 
 +
RESOURCE{} Sets a resource and quantity of resource for a part to contain
 +
{| class="wikitable"
 
|-
 
|-
! [[Parts#Wings and Wing Parts|Winglet]]
+
! Key !! Data Type !! What it does
| A lift producing part. Not movable.
 
 
|-
 
|-
! [[Parts#Wings and Wing Parts|Stabilizer]]
+
| name || Identifier || The Resource the part will contain
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[EAS-4 Strut Connector|StrutConnector]]
+
| amount || Float || The amount of resource the part will initially contain, will be rounded down to maxAmount if greater, so no overcharging.
|???
 
 
|-
 
|-
! [[Parts#RCS Fuel Tanks|RCSFuelTank]]
+
| maxAmount || Float || The amount of resource the part can contain
| this module has been depreciated and should not be used
+
|}
 +
 
 +
MODEL{} Alternate to mesh and texture variables, gives much better control but has some bugs
 +
{| class="wikitable"
 
|-
 
|-
! [[Parts#RCS|RCSModule]]
+
! Key !! Data Type !! What it does
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Jet Engines|AtmosphericEngine]]
+
| parent || || (Optional) Specifies what hierarchical element to append this model onto
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#S.A.S.|AdvSASModule]]
+
| model || Address || The model file (file.mu) that you wish to add to a part
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Decouplers and Seperators|DecouplerGUI]]
+
| texture || List || The texture you want to replace, comma, the address of the texture you want to replace it with
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Docking|DockingPort]]
+
| position || Vector || Offset from 0,0,0 in meters
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[FTX-2 External Fuel Duct|FuelLine]]
+
| rotation || Vector || Rotation along X,Y,Z (Units unconfirmed)
| Allows for transfer of fuel.
 
 
|-
 
|-
! [[Parts#Liquid Fuel Tanks|FuelTankGUI]]
+
| scale || Vector || Modifies the scale of the model along each of the three axis. 1=1:1 scale, 2=2:1 scale, etc
| this module has been depreciated and should not be used
+
|}
 +
ATTACH{} Alternate to node_ definitions, very buggy, generally not used because of problems
 +
 
 +
MODULE{} Used to associate functionality with a part by linking a partModule to the PART{} instance
 +
 
 +
== Part Modules ==
 +
{{Box|This section is grossly inadequate and outdated, as partModules are the primary way of attaching functionality to a part now
 +
* Write entire section
 +
* Come up with goals list}}
 +
þ Merge into Config Nodes -> Stock Config Nodes -> PART{MODULE{}}
 +
þ Several available partModules deserve their own pages, explaining them sufficiently in this page would be unnecessary clutter.
 +
 
 +
== PART Keys ==
 +
{{Box|Goals:
 +
* populate key table - Partially complete
 +
* Describe things
 +
}}
 +
 
 +
 
 +
 
 +
{| class="wikitable sortable"
 
|-
 
|-
! [[Parts#Landing Gear|LandingLeg]]
+
! Key !! "Category" !! Data Type !! What it does
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Landing Gear|HLandingLeg]]
+
| name || Internal || Identifier || Internal designation of the part used by code
| A moving landing leg, using .cfg parameters to move.
 
 
|-
 
|-
! [[Parachute|HParachutes]]
+
| title || Label || Text || External designation of the part used by players
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Parts#Landing Gear|LandingGear]]
+
| author || Label || Text || The names of the people who made it, often involved with add-on licensing
| this module has been depreciated and should not be used
 
 
|-
 
|-
! [[Light|SatELight]]
+
| category || Label || Identifier || Determines which tab of the VAB/SPH the part appears in; choose only one.
| It is unclear what this module is used for.
 
 
|-
 
|-
! [[Liquid fuel engine|LiquidFuelEngine]]
+
| manufacturer || Label || Text || Flavor text presented to the player, displays in a limited space
| this module has been depreciated and should not be used
 
 
|-
 
|-
! Part
+
| description || Label || Text || Flavor text presented to the player, can be used to explain use of a part
| This module should be used for all parts except for a few specific instances where the module has not yet been replaced with a partModule
 
<br />
 
There is nothing special about module Part.
 
 
|-
 
|-
|}
+
| cost || Label || Integer || Representation of the value of a part in an undefined currency, not used by stock but used by some add-ons and challenges
 
 
== Part Modules ==
 
{{Outdated|This section is grossly inadequate and outdated, as partModules are the primary way of attaching functionality to a part now}}
 
Please read: [http://forum.kerbalspaceprogram.com/showthread.php/10296-0-15-code-update-PartModule-KSPField-KSPEvent-ConfigNode-and-PartResource "0.15 code update - PartModule, KSPField, KSPEvent, ConfigNode and PartResource"]
 
 
 
{| class="wikitable"
 
 
|-
 
|-
! Module Name
+
| subcategory || Internal || Integer || Supposedly unused value for further sorting parts
! Description
 
 
|-
 
|-
! [[ModuleAerodynamicLift]]
+
| scale || Asset || Float || !!! Functionality of this key has become ambiguous
| Lift producing module?
 
 
|-
 
|-
! [[ModuleAnimateHeat]]
+
| rescaleFactor || Asset || Float || A value used to manipulate the size of models after the fact, usually for reusing elements without needing to remake, or being able to remake the model differently
|???
 
 
|-
 
|-
! [[ModuleAnimatorLandingGear]]
+
| mass || Physical || Float || The mass of the part, note, weight is a function of local gravity, so your Thrust to Weight ratio will vary by where you are, but your mass varies by how much resources you have.
| Animated landing gear module?
 
 
|-
 
|-
! [[ModuleCommand]]
+
| maxTemp || Physical || Integer || The temperature at which the part will explode to death
| Command module?
 
 
|-
 
|-
! [[ModuleEngineRocketLiquid]]
+
| crashTolerance || Physical || Integer || How hard the part can hit the ground and not explode
| Liquid rocket engine module?
 
 
|-
 
|-
! [[ModuleResource]]
+
| breakingForce || Physical || Integer || The linear force at which a joint between two parts will fail, and the two parts will no longer be joined.
| Generic resource module?
 
 
|-
 
|-
! [[ModuleResourceIntake]]
+
| breakingTorque || Physical || Integer || The rotational force at which a joint between two parts will fail, and the two parts will no longer be joined.
| Generic resource "intake" module, to add to or take away from "ModuleResource"?
 
 
|-
 
|-
! [[ModuleTest]]
+
| PhysicsSignificance || Physical || Binary || If 1, the part doesn't really exist, doesn't have mass, drag, temperature, and can't do a bunch of other stuff.
|???
 
 
|-
 
|-
|}
+
| specPower || Asset || Float|| The specular reflectivity of your part. It's best to leave it as it is.
  
== Asset Parameters ==
+
|-
{{Outdated|Whoever wrote this section has some rather severe misunderstandings about the functionality and purpose of scale/rescale. Also texture is depreciated
+
| rimFalloff || Asset || Float || This defines the strength of the highlight effect in game. Higher values lead to a more pronounced effect near the edges.
This section defines the assets of our module - it provides us with links to our model and to our texture file, as well as giving us some extra settings to play around with.
 
  
 +
|-
 +
| alphaCutoff || Asset || Float || This number defines the threshold for transparency on the part's texture. If your texture has an alpha channel (transparency), you can adjust this number to make sure your part is transparent or opaque where it should be. A value of 0 means nothing in the texture is considered to be transparent. A value of 1 means a completely transparent part.
  
Lets go through them.
+
|-
 +
| dragModelType || Physical || ??? || Which atmospheric drag model to use, always use "default"
  
;mesh
+
|-
:Easy, the name of the mesh you want to use for your model. Just write its name in there, but keep the mesh file in the same directory as the part file.
+
| maximum_drag || Physical || Float || The maximum drag value
  
;scale
+
|-
:The scale of your model, depending on how you used the units in your 3D modelling program. If you used one unit = one meter, use a scale of 1. If it's 1 unit = 0.1 meters, use a scale of 0.1, that simple. I tend to stick to using a 0.1 scale factor and then scale my model to fit with the rest of the parts, it's easier than fiddling around with scale factors. Note that this will only affect the units involved in node placement, and will not affect the actual size of the part.
+
| minimum_drag || Physical || Float || The minimum drag value
:Ø If scale is not 1, you have failed to properly configure your modeller and should correct this before moving forwards, as it does significantly complicate things
 
  
;texture
+
|-
:The name of your texture file, which would be found inside the ''KSPDirectory/Parts/yourAddon/textures'' folder. Textures should be either 256x256, 512x512 or 1024x1024
+
| stageOffset || Internal || Integer ||
:Ø texture is depreciated
 
:Ø The name of the texture to be used is included in the .mu file, and does not need to be explicitly stated unless it differs, and you would not use this variable to do so
 
  
;specPower
+
|-
:The specular reflectivity of your part. It's best to leave it as it is.
+
| childOffset || Internal || Integer ||
  
;rimFalloff
+
|-
:This defines the strength of the highlight effect in game. Higher values lead to a more pronounced effect near the edges.
+
| fuelCrossFeed || Internal || Binary || Whether fuel will cross through the part at all (Only stack attachment nodes can crossfeed)
  
;alphaCutoff
+
|-
:This number defines the threshold for transparency on the part's texture. If your texture has an alpha channel (transparency), you can adjust this number to make sure your part is transparent or opaque where it should be. A value of 0 means nothing in the texture is considered to be transparent. A value of 1 means a completely transparent part.
+
| NoCrossFeedNodeKey || Internal || ??? || Disables fuel crossfeed over a specific stack node
  
;rescaleFactor
+
|}
:This optional parameter is not usually included in most parts, but the option is available for resizing a part for personal use. Note that 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.
 
:Ø rescale factor should be explicitly set to eliminate complications
 
  
There, that's everything under asset parameters covered. Let's continue building our dummy part file.
 
  
 +
'''stageOffset''' and '''childStageOffset''' - Can be 0, 1, etc. defines whether this part will create a new stage before or after itself, or both (as do decouplers). This only applies for the automatically generated staging sequence. These replace stageBefore and stageAfter.
  
Onwards!
 
  
== Node Definitions ==
+
=== Node_s ===
{{Outdated|Does not mention ATTACH{}, and ang_ notation can be confusing, should refer to rotation instead of angle}}
+
{{Box|Does not mention ATTACH{}, and ang_ notation can be confusing, should refer to rotation instead of angle}}
 
Another fairly easy section, this defines where we attach our part to other parts. You can have as many as you want, for example, tricouplers have four, three bottom and one top, while most parts simply have two, and a few parts have only one.
 
Another fairly easy section, this defines where we attach our part to other parts. You can have as many as you want, for example, tricouplers have four, three bottom and one top, while most parts simply have two, and a few parts have only one.
  
 
<pre>
 
<pre>
 
node_stack_bottom = x, y, z, angx, angy, angz, size
 
node_stack_bottom = x, y, z, angx, angy, angz, size
node_stack_top = 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
+
node_attach       = x, y, z, angx, angy, angz, size
 
</pre>
 
</pre>
  
Line 303: Line 337:
 
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.
 
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.
  
 
+
=== Attachment rules: ===
== FX definitions: ==
+
þ table
 
 
More definitions! But this time, you're positioning the flame coming out the back of the rocket.
 
 
 
fx_exhaustFlame_yellow = x, y, z, angx, angy, angz, active
 
fx_exhaustLight_yellow = x, y, z, angx, angy, angz, active
 
fx_smokeTrail_medium = x, y, z, angx, angy, angz, active
 
 
 
Okay, looks pretty similar to node_definitions, right?
 
 
 
You'll notice, just like node definitions, there are separate parts to each effect. You have fx_exhaustFlame, fx_exhaustLight, and fx_smokeTrail.
 
 
 
There are exactly what they sound like, the flame, the light, and the smoke trail.
 
 
 
There are variations on flame color, blue is also an option. To get a blue flame, you would use fx_exhaustFlame_blue. You would do the same for the exhaustLight.
 
 
 
The 'active' switch on the end is used to define ''when'' this effect will be visible. See the [[FX Groups]] listing to know which effect groups are available, and when they are used.
 
It's also possible to assign an effect to more than just one FX Group. If for instance, you want a smoke effect to be visible both when the part activates and also when it deactivates itself, you can do this:
 
 
 
fx_gasBurst_white = x, y ,z, angx, angy, angz, activate, deactivate
 
 
 
This is particularly useful if you're defining a lot of effects, like the gas discharges on an RCS module.
 
 
 
Feel like you're getting the hang of this now? Let's keep building the dummy part file, and add in a blue flame and light, but leave out the smoke trail.
 
 
 
 
 
== Sound FX definition ==
 
{{Outdated|The stock sound loading system was broken at some point, none of this works anymore}}
 
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.
 
 
 
There are 3 ways to add a sound to a part. KSP has an internal sound library, which contains a few sound effects. By defining a sound as in the example above, KSP will search for that sound in its internal library.
 
KSP also has a Sounds folder on its main directory. This folder contains sounds that are available to every part in the Parts folder. To use a sound from the Sounds folder, you must include the file extension in the sound name (e.g., sound_vent_medium.wav = activate)
 
The 3rd way is to include your own sound effects to your Part folder (e.g., KSPDirectory/Parts/MyPartFolder/Sounds), and define your sound effect in the same manner as above.
 
 
 
REMEMBER: If you add a custom sound, the file name must start with '''sound_''' (e.g., sound_myNewSoundEffect.wav).
 
 
 
Sounds added to a Sounds folder inside the Part folder may not be accessed by other parts. Think of those as 'private' sounds.
 
 
 
Adding sound FX to our dummy part file:
 
 
 
 
 
== Editor Parameters: ==
 
 
 
Aha! We're back to parameters! These set of parameters let us decide how our part is displayed in the rocket editor. This section has the following:
 
 
 
// --- editor parameters ---
 
cost = 450
 
:Ø Cost must be an integer, no commas or periods; and it might need to be greater than 0. non-integer values will cause this part and every scheduled to be loaded after it to not be loaded.
 
category = Propulsion
 
subcategory = 0
 
title =
 
manufacturer =
 
description =  
 
 
 
;cost
 
:This hasn't really been implemented yet, but when it is it sets the cost for spaceship parts. You can set this to anything for now, it's entirely up to you.
 
 
 
;category
 
:There are seven categories:
 
 
 
{| class="wikitable"
 
|-
 
! Category
 
! Description
 
|-
 
! Pods
 
| Command pods and cockpits go here
 
|-
 
! Propulsion
 
| Engines, Fuel Tanks, RCS Tanks, etc.
 
|-
 
! Control
 
| SAS modules, RCS Thrusters, etc.
 
|-
 
! Structural
 
| Struts, decouplers, adapters, etc.
 
|-
 
! Aero
 
| Wings, Control Surfaces and nose cones.
 
|-
 
! Utility
 
| Parachutes, Escape towers, heat shields, lights, landing gear/legs, ladders, batteries, solar panels, generators, etc.
 
|-
 
! Science
 
| Sensors, Antennae, Satellite Dishes, etc.
 
|}
 
 
 
 
 
 
 
;subcategory
 
:No use yet. Set it to 0
 
 
 
;title
 
:What do you want your part to be called in the rocket editor?
 
 
 
;manufacturer
 
:Who built your part?
 
 
 
;description
 
:Describe your part here. (Do not use linebreaks. KSP breaks lines automatically in the part's tooltip. A linebreak will cause your description to appear truncated)
 
 
 
And that's that. Updating the dummy cfg file now:
 
 
 
 
 
== Attachment rules: ==
 
 
 
 
This defines how your part attaches to other parts.  
 
This defines how your part attaches to other parts.  
  
Line 441: Line 362:
 
*stackSymmetry = 3  
 
*stackSymmetry = 3  
  
 +
=== FX definitions: ===
  
Easy enough, right? Adding to dummy file and continuing.
+
More definitions! But this time, you're positioning the flame coming out the back of the rocket.
 +
 
 +
fx_exhaustFlame_yellow = x, y, z, angx, angy, angz, active
 +
fx_exhaustLight_yellow = x, y, z, angx, angy, angz, active
 +
fx_smokeTrail_medium  = x, y, z, angx, angy, angz, active
 +
 
 +
Okay, looks pretty similar to node_definitions, right?
  
 +
You'll notice, just like node definitions, there are separate parts to each effect. You have fx_exhaustFlame, fx_exhaustLight, and fx_smokeTrail.
  
== Standard Part Parameters: ==
+
There are exactly what they sound like, the flame, the light, and the smoke trail.  
{{Outdated|heatConductivity and heatDissipation are depreciated and do not function}}
 
This defines how your part performs in the air and its limits. Note that not all of these parameters need to be defined. If they're left out of the cfg file, KSP will use a default value for them.
 
  
*mass =
+
There are variations on flame color, blue is also an option. To get a blue flame, you would use fx_exhaustFlame_blue. You would do the same for the exhaustLight.
*dragModelType = default
 
*maximum_drag =
 
*minimum_drag =
 
*angularDrag =
 
*crashTolerance =
 
*breakingForce =
 
*breakingTorque =
 
*maxTemp =
 
*heatConductivity =
 
*heatDissipation =
 
*stageOffset =
 
*childStageOffset =
 
*fuelCrossFeed =
 
*NoCrossFeedNodeKey =
 
  
'''mass''' - How much does your part weigh? (Or, for parts that also specify a dryMass parameter, how much does it weigh when full?)
+
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:
  
'''dragModelType''' - Leave this as default.
+
fx_gasBurst_white = x, y ,z, angx, angy, angz, activate, deactivate
 +
=== Scaling ===
 +
Due to a series of bugs introduced in 0.20 and 0.21 scaling is not as simple is it should be. These bugs have not yet been properly quantified but revolve around MODEL{scale}, scale, and rescaleFactor
  
'''maximum_drag''' - What's the maximum amount of drag on your part? (Usually under 1.)  Generally drag when part's direction of travel is along its y-axis.
+
* '''Bug #1, PART{scale} is impacting the entire part, not just the mesh.'''
  
'''minimum_drag''' - The minimum amount of drag your part will encounter. (Usually under 1 and lower than maximum_drag) (this value is unused if dragModelType is set to default)  Generally drag when the part's direction of travel is perpendicular to its y-axis.
+
PART{scale} exists to correct mesh that are not in 1m scale. This includes parts that are in say, 1cm scale, or parts that are in imperial units. The mesh is multiplied by this value to result in 1m scale, so a mesh in 1cm scale would have PART{scale=0.01}. This is because KSP/Unity assumes everything to be in meter scale regardless so that 1cm scale part ends up being ten times larger than intended.
  
'''angularDrag''' - how much angular drag is there/resistance to turning? (Also usually under 1.)
+
Scale is not supposed to change the scale of anything else. Starting in ___ scale is being applied to the entire part, namely including the nodes. This means that if your model is in the wrong scale, you will have to position your nodes in that wrong scale and they will be fixed alongside the mesh. Normally PART{rescaleFactor} is used to rescale the part, so you correct the mesh with scale, place the nodes in 1m coordinates, and change them both with rescaleFactor. Effectively due to this bug, scale and rescaleFactor do the same thing.
  
'''crashTolerance''' - How good is your part at surviving crashes? The higher the number the more durable. Numbers are approximately maximum impact speed in m/s.
+
It is best to make sure your models are in proper 1m scale to begin with, and always leave scale=1 (scale does not default to 1)
  
'''breakingForce''' - How much will the attachment between this part and the part it's connected to resist to linear forces?
 
  
'''breakingTorque''' - How much will the attachment resist rotational forces?
 
  
'''maxTemp''' - The maximum temperature your part can experience before exploding.
+
* '''Bug #2, rescaleFactor v. MODEL{scale}'''
 +
''This bug was corrected in 0.25.0, rescaleFactor is no longer applied twice
 +
Existing parts using MODEL with compensated values will have been broken by 0.25.0
 +
The fix is to simply reverse the compensation''
  
'''heatConductivity''' - How good is your part at conducting heat? Defaults to 0.08, CFG values are used in 0.13.3, but not in 0.15.2.
+
From 0.20.0 to 0.24.5 rescaleFactor was applied twice to instances of MODEL. For rescaleFactors of 1, this had no effect, but for all other values the result was the square of rescaleFactor.
  
'''heatDissipation''' - How good is your part at dissipating heat from the ship? Defaults to 0.08, CFG values are used in 0.13.3, but not in 0.15.2.
+
There are two dominant ways to resolve this equation:
 +
* Set rescaleFactor to the square root of the intended value
 +
This works but any values or subnodes which take a coordinate must similarly be modified, this can considerably obfuscate the numbers and generally that's not a good thing.
 +
* Set MODEL.scale to 1 divided by rescaleFactor
 +
With this rescaleFactor and all other coordinates will be the intended values, and only MODEL.scale will be messed with.
  
'''stageOffset''' and '''childStageOffset''' - Can be 0, 1, etc. defines whether this part will create a new stage before or after itself, or both (as do decouplers). This only applies for the automatically generated staging sequence. These replace stageBefore and stageAfter.
+
* '''Bug #3, PART.NODE ignores PART.rescaleFactor
  
'''fuelCrossFeed''' - Will the part crossfeed fuel between parts attached to it?
+
As of 0.25.0, PART.NODE is 'functional', it still has significant bugs but the only critical one is that NODE does not respect rescaleFactor, the only scaling factor it respects is the instance of MODEL.scale for the model that contains the transform which NODE references. This is problematic because MODEL does respect rescaleFactor.
  
'''NoCrossFeedNodeKey''' - if set to bottom will keep fuel from flowing FROM bottom nodes (avoiding some stack imbalances and partially mitigating the 0.15 bug of engines generating fuel). Used with parts with multiple bottom nodes, such as the [[TVR-1180C Mk1 Stack Tri-Coupler]].
+
If you want to use NODE, PART.rescaleFactor MUST be equal to 1.
  
There you go, another section down.
+
== Modules ==
 +
{{Box|Nearly all modules have been depreciated and replaced with partModules which offer more control}}
 +
So what part types can you have?
 +
þ Reorder rows based on frequency of use: Part, Winglet ControlSurface, HLandingLeg, FuelLine, Strut
 +
{| class="wikitable"
 +
|-
 +
! Part Name
 +
! Description
 +
|-
 +
! [[Parts#Controlled wings and surfaces|ControlSurface]]
 +
| Movable wing-like surface. Can act as a rudder, aileron, elevator, canard or other aerodynamic control surface - function depends on placement on a ship.
 +
|-
 +
! [[Parts#Wings and Wing Parts|Winglet]]
 +
| A lift producing part. Not movable.
 +
|-
 +
! [[EAS-4 Strut Connector|StrutConnector]]
 +
| Used for making struts (the space ducttape kind)
 +
|-
 +
! [[FTX-2 External Fuel Duct|FuelLine]]
 +
| Allows for transfer of fuel.
 +
|-
 +
! [[Parts#Landing Gear|HLandingLeg]]
 +
| A moving landing leg, using .cfg parameters to move.
 +
|-
 +
! Part
 +
| This module should be used for all parts except for a few specific instances where the module has not yet been replaced with a partModule
 +
<br />
 +
There is nothing special about module Part.
 +
|-
 +
|}
  
Dummy CFG:
 
  
 +
=== Module Settings ===
 +
þ merge with Modules section
  
== Specific Part Parameters: ==
 
{{Outdated|Specific parameters of depreciated/SNBU modules are also depreciated/SNBU}}
 
 
We're almost finished, a complete part is almost at our hands and you should know almost everything you need to create a part.cfg file. However, remember back when we were setting types? Well each type has an individual set of specific part parameters that change depending on what type of part it is.  
 
We're almost finished, a complete part is almost at our hands and you should know almost everything you need to create a part.cfg file. However, remember back when we were setting types? Well each type has an individual set of specific part parameters that change depending on what type of part it is.  
  
Line 505: Line 454:
  
 
These specific parameters are actually public variables defined in the Part classes themselves. The standard parameters are declared in the Part base class, and the specific ones in each Part extension (i.e., Modules)
 
These specific parameters are actually public variables defined in the Part classes themselves. The standard parameters are declared in the Part base class, and the specific ones in each Part extension (i.e., Modules)
 
For example, if your part type (module) was SolidRocket, your specific part parameters would be composed of:
 
 
*thrust = 130
 
*dryMass = 0.36
 
*heatProduction = 550
 
*fuelConsumption = 4
 
*internalFuel = 100
 
*fullExplosionPotential = 0.8
 
*emptyExplosionPotential = 0.1
 
*thrustCenter = 0, -0.5, 0
 
*thrustVector = 0, 1, 0
 
  
 
Time to go through and see what special parameters each module can have.
 
Time to go through and see what special parameters each module can have.
  
=== Liquid Engine ===
+
Winglets
 
 
A liquid engine has the following special parameters:
 
 
 
*maxThrust =
 
*minThrust =
 
*heatProduction =
 
*fuelConsumption =
 
 
 
Looks pretty easy, and everything is pretty much what you'd expect. By now, you should be able to work out what they all mean, but just in case:
 
 
 
'''maxThrust''' - The maximum thrust of the liquid engine.
 
 
 
'''minThrust''' - The minimum thrust. Usually 0, unless you want a rocket that can't fully be turned off.
 
 
 
'''heatProduction''' - How much heat your rocket puts out.
 
 
 
'''fuelConsumption''' - How much fuel your rocket uses.
 
 
 
=== Solid Rocket Booster ===
 
 
 
*thrust =
 
*dryMass =
 
*heatProduction =
 
*fuelConsumption =
 
*internalFuel =
 
 
 
*fullExplosionPotential =
 
*emptyExplosionPotential =
 
 
 
*thrustCenter = x, y, z
 
*thrustVector = angx, angy, angz
 
 
 
A lot of those values look pretty similar to the liquid engine parameters, right?
 
 
 
'''thrust''' - The thrust of the solid rocket booster. Note how there is no minimum thrust because it can not be turned off once lit.
 
 
 
'''dryMass''' - How much the SRB weighs when empty.
 
 
 
'''heatProduction''' - Exactly the same as the liquid rocket, how much heat your rocket puts up.
 
 
 
'''fuelConsumption''' - How much fuel the rocket uses per second.
 
 
 
'''internalFuel''' - How much fuel does the SRB hold inside it?
 
 
 
'''fullExplosionPotential''' - The potential for explosion when the rocket is full of fuel
 
 
 
'''emptyExplosionPotential''' - And the potential when it's empty.
 
 
 
'''thrustCenter''' - Where the thrust comes from.
 
 
 
'''thrustVector''' - And which direction it goes.
 
 
 
=== Fuel Tank ===
 
 
 
Fuel tanks are a bit different, seeing as they have no thrust parameters.
 
 
 
*fuel =
 
*dryMass =
 
*fullExplosionPotential =
 
*emptyExplosionPotential =
 
 
 
If you've read above, you should know exactly what those parameters do, and so I won't explain them to you again.
 
 
 
=== SAS Module ===
 
 
 
*maxTorque =
 
 
 
'''maxTorque''' - The maximum amount of torque the module can apply to halt the ship's rotation.
 
 
 
'''Ki, Kd and Kp''' - These parameters allow for tuning of the internal workings of the SAS module. If you're not experienced in working with PID controllers, just leave them as they are.
 
  
=== Winglets ===
+
:þ Make this a table
 
 
*dragCoeff =
 
*deflectionLiftCoeff =
 
  
 
'''dragCoeff''' - The drag co-efficiency of the wings.
 
'''dragCoeff''' - The drag co-efficiency of the wings.
Line 601: Line 465:
 
'''deflectionLiftCoeff''' - How much lift the wings generate.
 
'''deflectionLiftCoeff''' - How much lift the wings generate.
  
=== Control Surfaces ===
+
Control Surfaces
  
*dragCoeff =
+
:þ Make this a table
*deflectionLiftCoeff =
 
*ctrlSurfaceRange =
 
*ctrlSurfaceArea =
 
  
 
'''ctrlSurfaceRange''' - How far off centre the control surface (rudder / aileron etc) can move under control
 
'''ctrlSurfaceRange''' - How far off centre the control surface (rudder / aileron etc) can move under control
Line 612: Line 473:
 
'''ctrlSurfaceArea''' - The effective surface area of the control surface - the bigger the surface, the bigger the surface area must be set to
 
'''ctrlSurfaceArea''' - The effective surface area of the control surface - the bigger the surface, the bigger the surface area must be set to
  
=== Decouplers ===
+
[[Category:Modding Tutorials]][[Category:Documentation]]
 
 
*ejectionForce =
 
 
 
'''ejectionForce''' - How hard it separates on stage ejection.
 
 
 
''Note, decouplers also add two lines to Standard Part Parameters, "stageAfter = True" and "stageBefore = True"
 
 
 
=== Parachutes ===
 
 
 
*useAGL =
 
*autoDeployDelay =
 
*minAirPressureToOpen =
 
*deployAltitude =
 
*closedDrag =
 
*semiDeployedDrag =
 
*fullyDeployedDrag =
 
 
 
'''useAGL''' - Whether or not the parachute opens at the set altitude above ground level, instead of above sea level.
 
 
 
'''autoDeployDelay''' - Time before parachutes attached to jettisoned parts are activated.
 
 
 
'''minAirPressureToOpen''' - The minimum air pressure required before the chute will activate.
 
 
 
'''deployAltitude''' - At what altitude the parachute deploys fully once activated.
 
 
 
'''closedDrag''' - The drag when the parachute is closed.
 
 
 
'''semiDeployedDrag''' - The drag when it's semi-deployed
 
 
 
'''fullyDeployedDrag''' - And finally, the drag when it's entirely deployed.
 
 
 
== Conclusion: ==
 
 
 
There you go then. By now, you should know the ins and outs of the part.cfg file, and how to create one, edit one, play around with one, etc. All sorts of cool stuff like that. The final dummy part.cfg file will be after this, with the special part parameters added in.
 
 
 
Anyway, that's that, now you know, now go make some cool addons like FTL drives and newton-defying inertial dampeners.
 
 
 
<!--[[Category:Tutorials]][[Category:Documentation]]-->
 

Latest revision as of 15:42, 21 June 2015

This page is being broken up into separate pages for more specific topics

The CFG File and ConfigNodes GameData and Assets some organization of pages dedicated to singular top level confignodes such as PART

Does not include the new 0.18 or 0.20 config format changes
  • Gamedata addressed
  • Config Nodes addressed
  • partModules not addressed
  • module deprecation partially addressed
  • Ø comments indicate notes on existing content that is incorrect or inadequate, and will need to be addressed
  • þ comments are formatting or structural changes that need to be made

Conventions

KSP's cfg format can be difficult to converse about without getting into how the code works because the format is a direct reflection of the code, but also because it's not very regular and a lot of labels get used repeatedly for different meanings while a lot of meanings get labeled differently in various places; all the while there are misnomers abound and piles of deprecated things that may or may not still work.

In it's most basic form the structure of a cfg file is as follows

Node
{
	Field = Value
}

All cfg structures can be represented as this. Nodes can be in other nodes but fields must be in a node. More specifically Nodes, such as PART, RESOURCE_DEFINITION, and MODULE, only exist in certain contexts. PART does not work inside another PART and MODULE does not work outside of PART. From there Fields hold Values, but those values have to be asked for by the code or they never get loaded. As well, Nodes must be asked for by the code, they don't do anything without a code counterpart. Node names and Field names are Case Sensitive, if they are spelled wrong or in the wrong case they will not exist as far as the code cares. For the purposes of this article we will be referring to the organization of things in code in a format similar to the code, Node.Field=value, in example: PART.MODULE.name="ModuleWheel", though it can be easier to shorten that to PART.ModuleWheel.name, the value of which is "ModuleWheel". Keep in mind that the shorthand is technically incorrect

In the code, the allowable contents of a Field are quite specifically defined based on C# Types. Predominantly you will see string, int, and float, and if the data does not match the necessary type it will likely cause some kind of crash. One example is PART.cost, cost is an int or integer, in past versions of KSP cost would fail if given a value that is not an int, such as a float such as 4.7 or a string such as 4,000 (the comma makes it a string or text value). This has been fixed now, but previously giving it a bad value would cause an exception that immediately ended the loading process, causing KSP to skip over all following values in that part, but also all parts following, and go straight to the landing screen with the Kerbal floating around.

It is also important to note that the way things are organized in the cfg does not strictly reflect how they are organized into code. Again for example PART.cost. In code this information gets placed into Part.partInfo.cost, where partInfo is an instance of AvailablePart, so really cost is found at AvailablePart.cost. Reflecting the organization of the code helps to a degree, but a perfect replication is neither the goal or particularly useful.

GameData

Tentatively complete: I believe this section to be complete aside from inconsistent terminology and refining the exact text. Please discuss on the talk page if you have concerns or things to add

All add-on files should be placed in the GameData folder, located in the root KSP folder alongside the KSP executable. Everything related to a given Add-on should be contained within a folder created specifically for that Add-on. Inside the dedicated folder, the directory structure is largely unimportant.

All of the stock parts are contained within GameData as well, and Squad uses this structure:

/Flags/            -- Flags must go here or they won't be loaded as flags, Capitalization Matters
/Parts/Aero/       -- Aerodynamic parts
/Parts/Command/    -- Command pods, probe cores, and reaction wheels
/Parts/Electrical/ -- Parts that create and store electricity 
/Parts/Engine/     -- Engines
/Parts/FuelTank/   -- Fuel Tanks
/Parts/Structural/ -- Parts that don't do anything, and don't contain resources
/Parts/Utility/    -- Parts that do things and don't contain resources (except some of them do)
/Parts/Wheel/      -- Things that roll
/Props/            -- Props are the functional little elements in IVAs
/Resources/        -- This folder contains the file that declares all of the stock resources
/Sounds/           -- Can you hear the love tonight
/Spaces/           -- Spaces are IVAs

(This is just the way Squad does it, you can do it any way you want)


All assets will be loaded in a depth first alphabetic order, in sets based on file type. Parts will be displayed in the order they are loaded in. Because of this parts located in /GameData/Squad/Parts/Utility/ will always be listed before those in /GameData/Squad/Parts/Wheel/, even if the wheel part's name is before the utility part's name alphabetically.

Aside from load order, the directory structure of /GameData/YourFolder/ only serves as an organizational tool for the developer.

.CFG Files

Tentatively complete

File type .cfg is used for every configuration file in KSP except persistence files, which are stored in .sfs, these files are simply disk-storable containers for Config Nodes and as such their names and locations are almost entirely insignificant. Each .cfg file will be addressed in depth-first alphabetical order based on it's position within /GameData/, relative to other .cfg files, and that is the extent of the value that a file's name has.

It is entirely possible to merge all of the top level config nodes of a given add-on pack into a single file, but this is likely to make working with that file much more difficult. It's generally accepted that the best practice is to have a single top level config node per file, or put a small number of closely related parts in a single file. For example, if you have a command pod you could have the PART{}, INTERNAL{}, any custom PROP{}s and any custom RESOURCE_DEFINITION{}s in a single file, but as far as KSP is concerned, having a part.cfg, internal.cfg, props.cfg, etc, in one folder is functionally the same thing.

Note that the .cfg file is not loaded into RAM. The config nodes in it are used to build code objects, and the variables are populated into those objects. As such, reducing the total number of files has zero impact on RAM usage.

Model Assets

Goals:
  • Improve formatting
  • Include relevant links
  • Address Transform relevancy

There are only two model formats which KSP will load without outside forces, .MU, and .DAE

  • .DAE is a legacy mode option and should not be used for a multitude of reasons, the first is that .DAE is much more complex to set up, and more finicky about what will work. You also don't have a lot of the options that you would have with .mu
  • .MU is a compiled model format developed by our holy father Mu produced in Unity using PartTools. .MU files permit a large number options to be applied and changed, and stored inside the model itself. These include animations, manipulations to the texture sheets, customized and primative colliders, control over the shaders used on a part, and the inclusion of Transforms.

þ make 'Unity' and 'PartTools' links, give PartTools it's own page?

þ Transforms are maybe not relevant to this text

A Transform is a Unity Game Object in a specific place and with a specific orientation that is referenced by code to achieve many things, the Gimbal Transform is used to move an engine's nozzle mesh, which is a child of the transform, and the Thrust Transform is used as the coordinates and orientation to apply force to a part, RCS thrusters also use transforms for this.

Model assets can be located anywhere within /GameData/ and referenced by their address from .cfg files using MODEL{}, if not using MODEL{} they need to be in the same folder as the .cfg file.

Texture Assets

Goals:
  • Improve formatting
  • Suggest and link to some free graphics editors

þ Phrasing may be confusing, perhaps omit that Unity can natively handle texture formats KSP doesn't recognize There are a lot of kinds of textures which can be used in KSP but only 3 formats are currently accepted by the loader, .MBM, .TGA, and .PNG

Once loaded the format you choose Does Not Matter, KSP will convert everything into DXT1 or DXT5 depending on the presence of an alpha channel (transparency), both of which are lossy formats. Both formats are direct bits-per-pixel formats so the actual content of those pixels is unimportant but because DXT5 has an alpha channel, it is directly twice as large as DXT1. KSP chooses the format based on the image so make sure you don't have unnecessary alpha channels.

  • .TGA and .PNG are both editable, .MBM is technically editable, but it is not a format that graphics editing software will know what to do with, and you'll have to edit some stuff by hand before it can be opened.
  • .MBM is uncompressed, and .TGA has very little compression but is a lossy format.
  • .PNG is a very well compressed lossless format that allows for an alpha channel.

To repeat, the format of your files does not matter in game, it only impacts the amount of Data On Disk and the time it takes to read that data off the disk.

There are various programs available to edit PNG and TGA images like Paint.NET or GIMP. While Paint.NET's interface is easier that GIMP's, GIMP is not only available for Windows but also for Linux and Mac OS X.

Sound Assets

Goals
  • Find someone who knows how this works
  • Make them write this section

They're not broken, they're just weird.

Config Nodes

Goals:
  • Suggest reviewing stock cfg files and the files of addons

(Note to plugin developers, this document only pertains to .cfgs) Starting in KSP 0.15 a .cfg structure known as Config Nodes was introduced, and later in KSP 0.20.0 alongside the game database system and /GameData/ directory structure. Config Nodes, generally seen as any string of upper case letters, numbers[confirmation needed] and underscores followed by an opening curly bracket ( { ) and later a closing one are a means of having more complexly organized data inside a part's configuration.

Prior to KSP 0.20.0 all parts had to exist by themselves in a file specifically named 'part.cfg', limiting any one folder to containing only one part, and due to restrictions on addressing assets, every part had to have it's own textures and models.

Following the release of KSP 0.20.0 parts must exist inside a .cfg file with any name, and must be wrapped in a PART{} config node. You are permitted to have multiple PART{}s in any given file, and the means of addressing assets has changed to be relative, treating /KSP/GameData/ as the root of any address.

Between the curly brackets of a config node you are able to define variables, their values, and other config nodes so long as they exist in that context. For an example:

PART{
    name = Example
    title = Superfly
    description = These are variables, they are case sensitive and the code defines what that case is
    you = can define anything you want, but the code in game is only going to use what it needs.
    banana = is a fully valid variable, that will not be used by anything in KSP
    not = every key or config node uses a reliable capitalization scheme so if you're having problems, double check your case

    RESOURCE{
        name = LiquidFuel
        amount = 400
    }
    MODULE{
        name = etc
    }
}

It is important to note that everything in KSP is Case Sensitive, from the variables and values in a .cfg file, to the names of asset files and folders. The capitalization scheme of keys and config nodes is defined entirely by the code that will use it, RESOURCE{} and Resource{} are not the same thing, and the later will do nothing, but also RESOURCE{Name=LiquidFuel} is not valid. Unfortunately within KSP there is no singular capitalization scheme to fall back on. "Generally" Config Nodes are in ALL CAPS, sometimes they're in lowerCamelCase, but you always have to follow the code, or it won't work.

Proper tabulation in .cfg files is not necessary, but extremely useful in maintaining readability of complex configurations and will help to make sure all your config nodes are closed properly.

Keys

The order of keys in a .cfg file is completely unimportant. All config nodes and keys are loaded in one solid step, before any other code is given the chance to access the data, as such all of the information in a .cfg file is available to the code immediately. It will not occur that one thing doesn't load right because some piece of information has not been loaded yet. Organize your configurations as you see fit.

What does matter is the kinds of information that the code expects a key to contain. Also, Capitalization Always Matters. In both Keys and Values, if it's not capitalized the right way, it won't do what you want. This becomes problematic because KSP's capitalization scheme is rather inconsistent.

þ This table will likely need multiple revisions to achieve an optimal representation of the truth in a form that conveys the information adequately.

Data Type Something Example
Integer A Number without decimal values and without any formatting 40008
Float A number with decimal values but still no formatting 40.008
Text Plain text Hi, my name is Guacamole, and I'm stealing your car right now.
Identifier A set of letters and numbers, capital or lower case, without spaces or punctuation (exceptions...) SmallGearBay
Address An address relative to /KSP/GameData/ (always use /, never \) /Squad/Parts/Engine/liquidEngine2-2/
List A set of comma separated values, usually integers or floats 0.00, 0.147, 0.00, 0.0, 1.0, 0.0, 1
Binary A 0 or 1 indicating a yes or no to enable or disable certain things 1
Vector A list of 3 values, X, Y, and Z, used to describe coordinates, orientations, and complex scales 4.743, 7.853, 0.042

The format of defining a key and it's value is as follows regardless of the data being contained within it. No line end marker is necessary.

Key = Value

The keys you set in a .cfg files don't fit into many clear cut groups, some related to visual assets, some relate to aspects of that part in the world, but most of them fit into several groups, are used at various levels, and don't really do quite what you think. In the following tables they've been roughly organized by category as a factor of what they do, not where they're used.

Stock Config Nodes

Goals
  • Create table of keys for each node
  • Describe each node's function, and any nodular relationships
  • Describe glitches and limitations

Top Level Config Nodes

Node Used For
PART{} Defines a new part
RESOURCE_DEFINITION{} Defines a new resource to be used in and by PART{}s
INTERNAL{} Defines an internal space which can be used by PART{}s
PROP{} Defines an prop, a functional self contained element, which can be used in INTERNALS{}


PART{} Config Nodes

RESOURCE{} Sets a resource and quantity of resource for a part to contain

Key Data Type What it does
name Identifier The Resource the part will contain
amount Float The amount of resource the part will initially contain, will be rounded down to maxAmount if greater, so no overcharging.
maxAmount Float The amount of resource the part can contain

MODEL{} Alternate to mesh and texture variables, gives much better control but has some bugs

Key Data Type What it does
parent (Optional) Specifies what hierarchical element to append this model onto
model Address The model file (file.mu) that you wish to add to a part
texture List The texture you want to replace, comma, the address of the texture you want to replace it with
position Vector Offset from 0,0,0 in meters
rotation Vector Rotation along X,Y,Z (Units unconfirmed)
scale Vector Modifies the scale of the model along each of the three axis. 1=1:1 scale, 2=2:1 scale, etc

ATTACH{} Alternate to node_ definitions, very buggy, generally not used because of problems

MODULE{} Used to associate functionality with a part by linking a partModule to the PART{} instance

Part Modules

This section is grossly inadequate and outdated, as partModules are the primary way of attaching functionality to a part now
  • Write entire section
  • Come up with goals list

þ Merge into Config Nodes -> Stock Config Nodes -> PART{MODULE{}} þ Several available partModules deserve their own pages, explaining them sufficiently in this page would be unnecessary clutter.

PART Keys

Goals:
  • populate key table - Partially complete
  • Describe things


Key "Category" Data Type What it does
name Internal Identifier Internal designation of the part used by code
title Label Text External designation of the part used by players
author Label Text The names of the people who made it, often involved with add-on licensing
category Label Identifier Determines which tab of the VAB/SPH the part appears in; choose only one.
manufacturer Label Text Flavor text presented to the player, displays in a limited space
description Label Text Flavor text presented to the player, can be used to explain use of a part
cost Label Integer Representation of the value of a part in an undefined currency, not used by stock but used by some add-ons and challenges
subcategory Internal Integer Supposedly unused value for further sorting parts
scale Asset Float  !!! Functionality of this key has become ambiguous
rescaleFactor Asset Float A value used to manipulate the size of models after the fact, usually for reusing elements without needing to remake, or being able to remake the model differently
mass Physical Float The mass of the part, note, weight is a function of local gravity, so your Thrust to Weight ratio will vary by where you are, but your mass varies by how much resources you have.
maxTemp Physical Integer The temperature at which the part will explode to death
crashTolerance Physical Integer How hard the part can hit the ground and not explode
breakingForce Physical Integer The linear force at which a joint between two parts will fail, and the two parts will no longer be joined.
breakingTorque Physical Integer The rotational force at which a joint between two parts will fail, and the two parts will no longer be joined.
PhysicsSignificance Physical Binary If 1, the part doesn't really exist, doesn't have mass, drag, temperature, and can't do a bunch of other stuff.
specPower Asset Float The specular reflectivity of your part. It's best to leave it as it is.
rimFalloff Asset Float This defines the strength of the highlight effect in game. Higher values lead to a more pronounced effect near the edges.
alphaCutoff Asset Float This number defines the threshold for transparency on the part's texture. If your texture has an alpha channel (transparency), you can adjust this number to make sure your part is transparent or opaque where it should be. A value of 0 means nothing in the texture is considered to be transparent. A value of 1 means a completely transparent part.
dragModelType Physical  ??? Which atmospheric drag model to use, always use "default"
maximum_drag Physical Float The maximum drag value
minimum_drag Physical Float The minimum drag value
stageOffset Internal Integer
childOffset Internal Integer
fuelCrossFeed Internal Binary Whether fuel will cross through the part at all (Only stack attachment nodes can crossfeed)
NoCrossFeedNodeKey Internal  ??? Disables fuel crossfeed over a specific stack node


stageOffset and childStageOffset - Can be 0, 1, etc. defines whether this part will create a new stage before or after itself, or both (as do decouplers). This only applies for the automatically generated staging sequence. These replace stageBefore and stageAfter.


Node_s

Does not mention ATTACH{}, and ang_ notation can be confusing, should refer to rotation instead of angle

Another fairly easy section, this defines where we attach our part to other parts. You can have as many as you want, for example, tricouplers have four, three bottom and one top, while most parts simply have two, and a few parts have only one.

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

There's three example nodes. There are three different kinds, but only two are useful to us at the moment. We have node_stack and node_attach. Node stack is for defining where the part stacks vertically together with other parts, and node attach is used for defining where on the surface of your part other parts attach - so horizontal attachment.

All node attachment values are given with respect 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.

Attachment rules:

þ table This defines how your part attaches to other parts.

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

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

stack - Can your part be stacked on others?

SrfAttach - Can your part be placed onto a surface?

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

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

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


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

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

FX definitions:

More definitions! But this time, you're positioning the flame coming out the back of the rocket.

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

Okay, looks pretty similar to node_definitions, right?

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

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

There are variations on flame color, blue is also an option. To get a blue flame, you would use fx_exhaustFlame_blue. You would do the same for the exhaustLight.

The 'active' switch on the end is used to define when this effect will be visible. See the FX Groups listing to know which effect groups are available, and when they are used. It's also possible to assign an effect to more than just one FX Group. If for instance, you want a smoke effect to be visible both when the part activates and also when it deactivates itself, you can do this:

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

Scaling

Due to a series of bugs introduced in 0.20 and 0.21 scaling is not as simple is it should be. These bugs have not yet been properly quantified but revolve around MODEL{scale}, scale, and rescaleFactor

  • Bug #1, PART{scale} is impacting the entire part, not just the mesh.

PART{scale} exists to correct mesh that are not in 1m scale. This includes parts that are in say, 1cm scale, or parts that are in imperial units. The mesh is multiplied by this value to result in 1m scale, so a mesh in 1cm scale would have PART{scale=0.01}. This is because KSP/Unity assumes everything to be in meter scale regardless so that 1cm scale part ends up being ten times larger than intended.

Scale is not supposed to change the scale of anything else. Starting in ___ scale is being applied to the entire part, namely including the nodes. This means that if your model is in the wrong scale, you will have to position your nodes in that wrong scale and they will be fixed alongside the mesh. Normally PART{rescaleFactor} is used to rescale the part, so you correct the mesh with scale, place the nodes in 1m coordinates, and change them both with rescaleFactor. Effectively due to this bug, scale and rescaleFactor do the same thing.

It is best to make sure your models are in proper 1m scale to begin with, and always leave scale=1 (scale does not default to 1)


  • Bug #2, rescaleFactor v. MODEL{scale}

This bug was corrected in 0.25.0, rescaleFactor is no longer applied twice Existing parts using MODEL with compensated values will have been broken by 0.25.0 The fix is to simply reverse the compensation

From 0.20.0 to 0.24.5 rescaleFactor was applied twice to instances of MODEL. For rescaleFactors of 1, this had no effect, but for all other values the result was the square of rescaleFactor.

There are two dominant ways to resolve this equation:

  • Set rescaleFactor to the square root of the intended value

This works but any values or subnodes which take a coordinate must similarly be modified, this can considerably obfuscate the numbers and generally that's not a good thing.

  • Set MODEL.scale to 1 divided by rescaleFactor

With this rescaleFactor and all other coordinates will be the intended values, and only MODEL.scale will be messed with.

  • Bug #3, PART.NODE ignores PART.rescaleFactor

As of 0.25.0, PART.NODE is 'functional', it still has significant bugs but the only critical one is that NODE does not respect rescaleFactor, the only scaling factor it respects is the instance of MODEL.scale for the model that contains the transform which NODE references. This is problematic because MODEL does respect rescaleFactor.

If you want to use NODE, PART.rescaleFactor MUST be equal to 1.

Modules

Nearly all modules have been depreciated and replaced with partModules which offer more control

So what part types can you have? þ Reorder rows based on frequency of use: Part, Winglet ControlSurface, HLandingLeg, FuelLine, Strut

Part Name Description
ControlSurface Movable wing-like surface. Can act as a rudder, aileron, elevator, canard or other aerodynamic control surface - function depends on placement on a ship.
Winglet A lift producing part. Not movable.
StrutConnector Used for making struts (the space ducttape kind)
FuelLine Allows for transfer of fuel.
HLandingLeg A moving landing leg, using .cfg parameters to move.
Part This module should be used for all parts except for a few specific instances where the module has not yet been replaced with a partModule


There is nothing special about module Part.


Module Settings

þ merge with Modules section

We're almost finished, a complete part is almost at our hands and you should know almost everything you need to create a part.cfg file. However, remember back when we were setting types? Well each type has an individual set of specific part parameters that change depending on what type of part it is.

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

These specific parameters are actually public variables defined in the Part classes themselves. The standard parameters are declared in the Part base class, and the specific ones in each Part extension (i.e., Modules)

Time to go through and see what special parameters each module can have.

Winglets

þ Make this a table

dragCoeff - The drag co-efficiency of the wings.

deflectionLiftCoeff - How much lift the wings generate.

Control Surfaces

þ Make this a table

ctrlSurfaceRange - How far off centre the control surface (rudder / aileron etc) can move under control

ctrlSurfaceArea - The effective surface area of the control surface - the bigger the surface, the bigger the surface area must be set to