General overview of custom modules

From KSP 2 Modding Wiki


What are Modules?

Each part in the game has one or more Modules attached to it. Purpose of a Module is to provide a functionality to a part.

Some examples are:

  • Module_Deployable - adds deploy functionality (landing legs, antennae...)
  • Module_DataTransmitter - adds connection and data transmittance functionality (capsules, antennae...)
  • Module_Color - adds ability to color a part (base color, accent color)
  • Module_Engine - adds engine functionality (thrust, throttle, ISP, propellant requests...)

All stock Module definitions can be found inside the game's Assembly-CSharp.dll under namespaces: KSP.Modules (ModuleData and PartBehaviourModule) and KSP.Sim.impl (PartComponentModule)

What are Custom Modules?

Custom Modules are Modules that we modders can create and attach to a part to give it some custom functionality.

Some examples are:

  • Module_LifeSupportConsumer - mod: KerbalLifeSupportSystem - provides life support consumption (oxygen, water, food) to parts with crew capacity
  • Module_OrbitalSurvey - mod: Orbital Survey - provides scanning functionality to parts with a Module_DataTransmitter module (antennae)

Anatomy of a Module

Modules have 3 basic components, C# classes that inherit from a base class.

ModuleData

  • base class whose function is to define and maintain data used by the Module
  • data is stored either in save game files ([KSPState] attribute) or in part definition json ([KSPDefinition] attribute) or persists only during runtime
  • some examples of data stored in ModuleData: CurrentDeployState (state of deployment for the part), IsTransmitting (is part currently transmitting or not), thrustPercentage (at what percentage is the thrust currently at for this engine)
  • use it to store data that other components will use or that will be displayed in PAM or OAB/R&D

PartBehaviourModule

  • base class that's responsible for how a part behaves, what happens when a button is pushed, what is displayed in PAM (in Flight and OAB), what happens on a game tick update
  • this class exists only when the vessel is loaded (i.e. player is directly controlling the vessel)
  • use it for immediate frontend logic - player enables the module, engines change their modes, entries in PAM need to be shown/hidden, etc.

PartComponentModule

  • base class used mostly for background/backend Module logic, things that aren't directly connected to PAM
  • example of backend logic: Orbital Survey initiates scans if the conditions are right
  • class is instantiated when the part is first placed in the OAB and it continues to exist until the part is destroyed. Update loops are being executed even on unloaded vessels
  • use it for things that continually need to run in background - e.g. life support consumption on game ticks, continuous scanning while the vessel is unloaded, EC collection for solar panels, etc.

You're free to define your own logic inside these classes, of course, but it's always good to follow established conventions as much as possible.

Attaching a Custom Module to a part

To define and add your Custom Module to parts there are 2 things you need to do.

  1. In your C# plugin define your classes that derive from ModuleData, PartBehaviourModule and PartComponentModule classes
  2. Use the Patch Manager mod to inject your Custom Module to parts you want.

Patch Manager

Think of Patch Manager as a successor to Module Manager from KSP1. You define patches in a text file with a .patch extension that you place somewhere in your plugin folder structure.

Here's a rudimentary example of a Custom Module being injected to all parts.

MyCustomModule.patch:

:parts {
    +Module_MyCustomModule {
        +Data_MyCustomModule {
        }
    }
}

With Patch Manager installed this patch will add your MyCustomModule to all parts in the game (don't do this :)).

You can get Patch Manager either with CKAN or download it from here: https://spacedock.info/mod/3482/Patch%20Manager

For an in-depth walkthrough of Patch Manager functionalities, syntax, best practices and more sensible examples of Custom Module patches refer to Patch Manager documentation: https://pm.kerbal.wiki/

Some examples for custom module patches: