General overview of custom modules: Difference between revisions

From KSP 2 Modding Wiki
No edit summary
(Add page contents)
Line 1: Line 1:
[[Category:Custom Modules]]
[[Category:Custom Modules]]
== 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:
* <code>Module_Deployable</code> - adds deploy functionality (landing legs, antennae...)
* <code>Module_DataTransmitter</code> - adds connection and data transmittance functionality (capsules, antennae...)
* <code>Module_Color</code> - adds ability to color a part (base color, accent color)
* <code>Module_Engine</code> - adds engine functionality (thrust, throttle, ISP, propellant requests...)
All stock Module definitions can be found inside the game's <code>Assembly-CSharp.dll</code> under namespaces: <code>KSP.Modules</code> (ModuleData and PartBehaviourModule) and <code>KSP.Sim.impl</code> (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:
* <code>Module_LifeSupportConsumer</code> - mod: KerbalLifeSupportSystem - provides life support consumption (oxygen, water, food) to parts with crew capacity
* <code>Module_OrbitalSurvey</code> - 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.
<code>ModuleData</code>
* 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
<code>PartBehaviourModule</code>
* 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
* use it for immediate frontend logic - player enables the module, engines change their modes, entries in PAM need to be shown/hidden, etc.
<code>PartComponentModule</code>
* 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
* use it also 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.
# In your C# plugin define your classes that derive from <code>ModuleData</code>, <code>PartBehaviourModule</code>  and <code>PartComponentModule</code> classes
# 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 <code>.patch</code> extension that you place somewhere in your plugin folder structure.
Here's a rudimentary example of a Custom Module being injected to all parts.
<code>MyCustomModule.patch</code>:
:parts {
    +Module_MyCustomModule {
       +Data_MyCustomModule {
       }
   }
}
With Patch Manager installed this patch will add your <code>MyCustomModule</code> 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:
* KLSS: https://github.com/Safarte/KerbalLifeSupportSystem/tree/main/plugin_template/patches
* Orbital Survey: https://github.com/Falki-git/OrbitalSurvey/tree/master/plugin_template/patches

Revision as of 17:43, 11 January 2024


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
  • 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
  • use it also 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: