| name | module-manager |
| description | Knowledge base for Module Manager (MM), the essential KSP modding tool that allows config-file patching at load time. Covers patch syntax, operators, ordering directives, NEEDS dependency checking, variables, common patterns, and troubleshooting. Compiled from the official GitHub wiki, the KSP Forum thread, and community guides.
|
| author | Acea |
| sources | ["https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax","https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering","https://github.com/sarbian/ModuleManager","https://forum.kerbalspaceprogram.com/topic/50533-18x-112x-module-manager-423-july-03th-2023-fireworks-season/","https://forum.kerbalspaceprogram.com/topic/198716-basic-module-manager-tutorial/"] |
| category | gaming |
| version | 1 |
| last_updated | "2026-06-18T00:00:00.000Z" |
| applies_when | file_exists:GameData/ModuleManager*.dll |
Module Manager — KSP Config Patching Tool
⚠ CONDITIONAL SKILL: This knowledge base applies only when Module Manager is installed in the current KSP instance. To verify: check that GameData/ModuleManager*.dll (e.g. ModuleManager.4.2.3.dll) exists directly in the GameData folder. If not present, the information below is not relevant.
Detection method:
ls GameData/ModuleManager*.dll 2>/dev/null && echo "MM installed" || echo "MM NOT installed"
Test-Path "$env:KSP_DIR\GameData\ModuleManager*.dll" -PathType Leaf
1. WHAT IS MODULE MANAGER?
Module Manager (MM), originally by Ialdabaoth and maintained by Sarbian & Blowfish, is the single most important dependency mod in KSP. It lets mod authors write patch files (.cfg) that modify game parts, modules, and properties at load time, without overwriting any original files.
Philosophical note: MM is the foundation of the KSP modding ecosystem. Almost every mod either ships with MM or requires it. Without MM, mod authors would have to manually overwrite Squad's config files — breaking compatibility with every other mod.
2. CORE CONCEPTS
2.1 ConfigNode Structure
KSP stores all part, module, and game configuration in a nested tree of ConfigNodes. Module Manager patches operate directly on this tree.
// Comment (everything after // is ignored)
PART
{
name = myPart
module = Part
MODULE
{
name = ModuleEngines
}
}
2.2 Patch Prefixes
Every patch line starts with an operator character that tells MM what to do:
| Operator | Name | Description |
|---|
@ | Edit | Modify existing node or value |
+ or $ | Copy | Duplicate a node/value |
- or ! | Delete | Remove node or value |
% | Edit-or-Create | Edit if exists; create if not |
& | Create | Create only if not already present |
| | Rename | Rename a node |
# | Copy Node | Copy a node from elsewhere in the tree |
2.3 Patch Ordering Directives
At the top-level node, you can specify one ordering directive to control when the patch applies:
| Directive | Pass | Use Case |
|---|
:FIRST | First pass | Critical foundational changes |
:BEFORE[modname] | Before mod's pass | Prepare data for another mod |
:FOR[modname] | During mod's pass | Register your mod's name for others to reference |
:AFTER[modname] | After mod's pass | Modify after another mod has done its work |
:LAST | Late pass | Late-stage modifications |
:FINAL | Final pass | Reserved for end-user personal patches only |
Application order overall: INSERT(first) → :FIRST → (no directive) → :BEFORE/:FOR/:AFTER (sorted alphabetically by modname) → :LAST → :FINAL
2.4 Valid Modname Values
Module Manager builds a list of valid modnames (case-insensitive) from:
- DLL files in
GameData/ (uses assembly name, not filename)
- Folders directly in
GameData/
- Mods that declare
:FOR[modname] in any of their patches
Example — registering so other mods can reference you:
// Even if MyCoolMod lives in a subfolder, this :FOR declaration
// makes it visible to :BEFORE[MyCoolMod] and :AFTER[MyCoolMod]
@PART[somePart]:FOR[MyCoolMod]
{
@someValue = 1
}
3. PATCH OPERATORS
Full patch operator reference extracted to references/patch-operators.md, covering value/node syntax, Insert, Edit (@), Copy (+/$), Delete (-/!), Edit-or-Create (%), Create (&), Rename (|), and Copy Node (#) with code examples for each.
4. DEPENDENCY CHECKING (NEEDS)
The :NEEDS directive can be used on patches, nodes, or individual values to conditionally apply changes based on which mods are installed.
Syntax:
:NEEDS[expression]
Operators:
| Symbol | Meaning |
|---|
& or , | AND |
| | OR |
! | NOT |
Evaluation precedence: ! (NOT) binds tighter than & (AND), which binds tighter than | (OR). Use parentheses implicitly — NEEDS[A|B&C] = A OR (B AND C).
Examples:
// Patch only if both RealFuels and ModularFuelSystem are installed
PART:NEEDS[RealFuels&ModularFuelSystem] { ... }
// Patch if either mod is present
PART:NEEDS[RealFuels|ModularFuelSystem] { ... }
// Different descriptions depending on which mod is active
PART
{
name = myPart
description:NEEDS[RealFuels&!ModularFuelSystem] = Used in Real Fuels
description:NEEDS[ModularFuelSystem&!RealFuels] = Used in Modular Fuel System
}
DLL Detection: Module Manager checks the assembly name (File Description in DLL properties), not the filename. A DLL named MyMod.dll with assembly name MyCoolMod registers as MyCoolMod.
5. VARIABLES
Module Manager supports variable substitution using # and $ syntax.
| Symbol | Meaning |
|---|
# | Variable indicator |
$ | Start/end of variable identifier |
@ | Reference a different top-level node |
Example — copy a value from another part:
@title = #$@PART[liquidEngine1-2]/title$
@MODULE[ModuleEngines]
{
@PROPELLANT[LiquidFuel]
{
@mass = #$../../mass$ // Reference parent node's mass
}
}
6. COMMON USE CASES
Common use case code examples, troubleshooting guide, and community resources extracted to references/examples-and-refs.md, covering adding modules, modifying engines, cloning parts, removing modules, conditional patching, setting defaults, and common issues with solutions.
7. BEST PRACTICES
- Use
:FOR[YourModName] at least once so other modders can reference you with :BEFORE/:AFTER.
- Reserve
:FINAL for end-user personal patches only — never ship a distributed mod with :FINAL.
- Prefer
:BEFORE/:AFTER over :FINAL for inter-mod compatibility.
- Use
& (create) for setting safe defaults that users can override.
- Use
! (delete) with caution — test that the deleted module truly exists first.
- Test your patches on a clean install of your target dependencies to catch unexpected interactions.
- Wildcards
* and ? are powerful but expensive — narrow your target as much as possible.
8. COMMON ISSUES & SOLUTIONS
Troubleshooting guide and community resources extracted to references/examples-and-refs.md, covering MM hang at load, patch not applying, slow loading, wrong values, and installation errors.
9. COMMUNITY RESOURCES
Community resources (official links, tutorials) extracted to references/examples-and-refs.md.
Related Knowledge Bases:
- KSP World Knowledge: ksp-world-knowledge.skill
- MechJeb: mechjeb.skill
- kRPC Programming: krpc-programming.skill
