3.0 Module Manager Configuration

Home || Prev || Next

Section 1 General Information
Section 2 CLS API

---

Module Manager Configuration

CLS uses Module Manager, a plugin that allows adding to a part's configuration. Using Module manager, CLS adds a module named ModuleConnectedLivingSpace, to provide CLS with information on whether or not a part can contain crew, or is internally passable by a crew member.

Habitability/Passability Detection

When no MM config file exists for a part, CLS will attempt to determine if a part is habitable or passable based on existing information in the part.cfg file. Often it can properly determine what is needed and add the cls module. Sometimes it cannot. To correct this issue a config file can be created to provide the needed information.

MM Config file structure

Module Manager uses a JSON style file containing many wildcards and options for creating additional info for parts. it is beyond the scope of this wiki to describe all these features. It is essentially a language in and of itself, and is very powerful. Review the Module Manager wiki for more information on using this powerful tool. For the purposes of this Wiki, some samples will be provided to help in understanding what CLS needs/expects to support its operations.

Here is a sample part configuration for a part in KW Rocketry:

@PART[KWFlatadapter2x1]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
	    name = ModuleConnectedLivingSpace
	    passable = true
    }
}

This config adds a module to a KW flat adpter. It checks to see if the module already exists and adds it if needed. Note the module name: ModuleConnectedLivingSpace. This module will be handled inside the CLS code to look for the properties listed in the module.

This part is an adapter, so Kerbals can pass through the part to another part. Therefore, the Passable flag exists and is set to true.

@PART[B9_Cockpit_S2]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
	    name = ModuleConnectedLivingSpace
	    passable = true
	    impassablenodes = top
    }
}

This part, from B9, is a cockpit so it is passable, but the top node is not. So, an attribute named "impassablenodes" is set to "top". You can look at the samples provided by the many configs that come with CLS for clues on how to create your own config files. All attributes are detailed below.

Module Attributes

• name = ModuleConnectedLivingSpace The Name of the Module will always stay the same. This is used to identify the module to CLS
• passable = true/false This flag determine whether or not crew can pass through the part.
• passableWhenSurfaceAttached = true/false This flag tells CLS when the part is surface attached (usually radially), that it is or is not passable.
• surfaceAttachmentsPassable = true/false This flag tells CLS when a part has other parts attached to its surface if they are passable or not. So, you can have a part that is passable connected to a part that does not accept passable connections and therefore the passability would end up as false.
• impassablenodes = top/bottom This flag identifies what nodes cannot be passed through. The node names used to the right of the equality sign correspond to node names identified in the part.cfg for that part. So possible nodes could be like: bottom1, bottom2, top1, top8, etc. depending on the number of nodes and the names used in the part to identify the node.
• passablenodes = top/bottom These two values allow a list of attachment node names to be specified where the passablity of those nodes is different from the passable for the whole part. This allows parts to be entered via some nodes by not others. The names of the nodes are the names specified in the Node Definitions section of the .cfg file, but without the "node_stack_" prefix. In the example above there are two node that are defined "top" and "bottom". (note that node_attach is used to surface attach the part and can not be specified). It is possible to set more than one node to be passable or impassable by seperating them with a comma - for example impassablenode=top,side
• passableDockingNodeTypes and
• impassableDockingNodeTypes Some Docking Nodes in a part are specified by reference to a transform in the 3D model, rather than an attachment node in the .cfg file. In order to override if these docking nodes are to be passable, you can specify a list of passable or impassable docking node types. These values ned to match up with "nodeType" specified in the ModuleDockingNode for the part.