CFG File Documentation

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.

Basic Part Making Guidelines

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

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

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

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

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

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

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

Config file order

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

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.

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

Known node definitions are listed below:

• 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

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_yellow

Each fx call follows the same pattern

Actual Part	definition
fx_exhaustFlame_blue_small = 0,0,0,0,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

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

Left Side options	Right Side options
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 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) As of [0.90], sub-divided into: FuelTank Engine 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.

• // 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.
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) (Pods) (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 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 {},

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

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

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

Module Name
ModuleParachute

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.

variable	example	explanation
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:

variable	example	explanation
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

ModuleParachute

variable name	sample	explanation