Search the Community

IMPORTANT: PAGE UNDER CONSTRUCTION, NOT FINAL Before I begin: 1. This is my own idea, it is in no way official, nor affiliated with any developer of ModuleManager. 2. I thought it would be helpful. 3. No one told me not to. 4. This is for you, @Ooglak Kerman. And all the others who wished to manage their modules, but could not. So, I figured that many KSP players who use a lot of mods may not exactly have the mods just the way the want. Or maybe a budding modder wants to learn some stuff about CFG files. Part 1: What is Module Manager? ModuleManager is a mod created by @ialdabaoth and currently maintained by @sarbian. A large portion of KSP's data are stored in text files with the .cfg extension. This includes resource definitions, part functionality, science flavor text and gains, and much, much, more. Sometimes, a mod may need to change this existing data as well as adding it's own. That is where Module Manager comes in to help. With ModuleManager, the text in CFG files can change what is actually loaded into the game from what is in the other files. For example, Snacks, a life-support mods, adds some life support supplies to all crewed pods using ModuleManager. THIS GUIDE WILL NOT TELL YOU HOW TO INSTALL MODULE MANAGER. Part 2: The Node Structure The CFG files are set up into a hierarchy of nodes. These nodes contain fields, where data is, and other nodes. Let's take a look at the definition of the Liquid Fuel resource. At the top, in caps, we see "RESOURCE_DEFINITION". This is the type of node. As it does not exist within another node, we call it a top-level node. Within it, are some other nodes and fields. First, is the "name" field. This is not what is displayed, it is an internal name. It is very important, however, for selecting that node for later editing. It also has some other functions for things like functionality. You may notice, that in the displayName and abbreviation fields, there is some #autoLOC_<numbers>. This uses the localization system, displaying a different value based on what language is selected for the game. This will be later discussed further. So, we have those fields, but we also have the "RESOURCE_DRAIN_DEFINITION" node, with its own fields inside. There could be other nodes inside that, and you can go on forever. Part 3: Selecting a Node for Editing At the top of the previous example, we saw the line "RESOURCE_DEFINITION". In front of that, we could have put a few thing, and behind it, we could have put a lot more things. If, at the front, we had an "@" character, we could select a RESOURCE_DEFINITION for editing. if we had a "+" character, it would make a copy and let us edit that. the "!" and "-" characters delete the selected node, but you still have to specify a little something. More detail on this later. Finally, the "%" character edits something if it already exists, and if not, creates it. At the back, we could have put some square brackets. Inside those brackets, we could select a name of the specific node to edit, as there are lots of nodes of the same type. The name is the same as the "name" field specified in the initial creation of the node. You can put the "*" character inside the name, and it will represent any number of any characters. So, "abc*" would select "abc1", "abc2", "abcde", but not "ab3". Additionally, the "?" character can be any one random character. If you want to select every part, you can put just the "*" character into the square brackets. After the square brackets, we can put a comma and then a number, or some other selectors. The numbers indicate which node to edit, if the node they are in have multiple with the same name. The selectors are: HAS, NEEDS, FOR, BEFORE, AFTER, FIRST, and FINAL. They will be discussed in more detail later. After each of these words, there is some stuff in square brackets, and then a colon between everything. Here's an example, from the Blueshift thread: Let's look at each line. First, it edits the parts with a specific set of nodes. Curly braces indicate that we are going a level in. Then, we edit a module node with the name "WBIWarpEngine". Again, curly braces. Finally, we edit the warpSpeedSkillMultiplier field to be 0.6. Remember to make sure that each opening curly brace is paired with a closed curly brace. This is one of the most common mistakes! Part 4: Selecting Fields Fields also need to have the selection character at the front, and can have the other selectors or numbers applied to them. Oh, and the number can be the star symbol to select all of them. If there is no number, the first one is used. These go before the new value, like this: @WhatEverThisIs, 3:NEEDS[xyz] = abc Part 5: Other Selectors There are a few things you can put after each selected node or field: 1. HAS HAS will only make the patch apply to parts with some condition. After the word goes a set of square brackets. Inside, you can put: <character><node/fieldType>[<name>]. The character can be @, # or !. If the character is @, then the patch will only run on parts with that node. If the character is !, then the patch will only run on parts without that node. The # character will be covered later, when we get to variables. The node type should be self-explanatory. is it a PART? MODULE? RESOURCE? The name is just the same as the name field when selecting a part. 2. FOR This one's simple, a mod name goes in the box. This lets Module Manager know that the patch is for that mod. 3. NEEDS For this selector, inside the box goes the name of a mod. The patch will only run if that mod is installed. The ! character can be used to make the patch only run if the mod is not installed, and the | character acts like a logical OR gate, so either of two mods can be installed and the patch will run. To determine whether a mod exists: A. if there is a patch, that runs at all, with the FOR selector carrying a name that is the same as what is in the NEEDS box B. Or, if there is a folder in GameData with the name you are looking for. 4-5. BEFORE and AFTER Mod names go in the box. These make the patch run before or after patches with FOR selectors of the mod name. Useful to avoid pouring the drink before getting out a cup, so to speak. 6-7. FIRST and FINAL Simply put, these just make the patches run before or after everything else. No square brackets needed. COMMUNITY UPDATING As it seems others have begun to add things to this, I will quote them here in the OP. Thanks, everyone!

Hi all, I am very new to add-on development, and I was wondering why part attach nodes are written in the CFG if they're configured in Unity along with the materials, CoM etc. (photo of node lines in the CFG) Also, a little side question, does anyone know of any good tutorials for developing parts? The one on the KSP wiki is quite outdated.

so I started to poke around in the cfg files just for giggles and ive notice something. C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\Squad\Parts\FuelTank\adapterTanks im running 1.3.1, stock install. if you open up the mk3-size2 for example. note the mass. (1.79) now open up mk3-shuttleadapter. and again note the mass. (0.7) start ksp and compare notes. in game -->shuttleadapter mass: 0.7 in game --> mk3-size2 mass: 14.29 this cant be the only discrepancy like this too. anyone got any ideas? a quick install of KER confirms mass is 14.29kg for the size2 adapter