-
Notifications
You must be signed in to change notification settings - Fork 0
KSP Core Concepts
This is an attribute that you can place on a class that inherits from MonoBehaviour, which will mark that class as an addon. KSP will instantiate an object with this component on certain scene transitions according to the parameters you use for the Startup and once values.
ConfigNodes are created from .cfg text files in GameData, and are the core way that objects are configured for the game. A ConfigNode has a name, a list of child nodes, and a list of key/value field pairs. The name of the ConfigNode is the keyword used before the curly braces. It usually indicates the type of the node rather than its name, although there are exceptions like fx blocks in parts. Many ConfigNodes also have a name field which uniquely identifies it among all the possible nodes of the same type (i.e. ConfigNode.name).
The GameDatabase holds all loaded .cfg files and nodes.
ModuleManager is a tool for using .cfg files to modify other .cfg files, and is invaluable in the modding ecosystem so that different mods can alter the same parts without needing to actually overwrite each other's files.
A collection of static events where you can register a delegate to be called when various things happen. IMPORTANT: If you add an event handler, you must remove it when your object is destroyed (generally use OnDestroy for this) or else you will cause a memory leak. Do not use lambda expressions as event handlers because you cannot easily remove them.
Represents a distinct vessel in flight. Note that Kerbals on EVA, flags, and asteroids are all Vessels. There is only one active vessel, which is the one that the player is controlling. This can be accessed via FlightGlobals.activeVessel - but be warned that it may be null in some cases.
When two vessels dock, they become one vessel. Any time they separate - whether undocking, decoupling, a part breaking - then they become multiple vessels again.
A vessel can be loaded or unloaded - vessels that are unloaded do not have Parts instantiated. Generally, vessels that are within a certain range of the active vessel will be loaded. Further, a loaded vessel can be packed or unpacked - packed vessels do not simulate physics. All vessels are packed during timewarp, and a non-active vessel will not be unpacked until it gets rather close to the active one.
Vessels are primarily a collection of Parts, which in turn have a collection of PartModules. Parts are arranged in a tree - each Vessel has one root Part, and each Part has one parent and potentially many children.
Parts are created by cloning a prefab from the GameDatabase. The prefab is accessible via Part.partInfo.partPrefab. The prefab is created during loading via a top-level PART node in a cfg file. In addition to the usual [KSPField]s, Parts use LoadObjectFromConfig which means that all fields marked [Persistent] will also be loaded from the cfg file. Even further, top-level keys in the PART ConfigNode will populate a field with the same name and type in the Part class using reflection.
Most of the behavior of Parts is provided by PartModules. These are instantiated as components on the Part gameobject. The PART node in the cfg file specifies which modules are in the part.
Classes that inherit from VesselModule will be added to every Vessel in the world. This is a good place to store information per-vessel and especially for unloaded vessels, as well as persisting per-vessel data to the save file. Please pay careful attention to the Activation and ShouldBeActive methods so that you do not spend time updating unloaded vessels, flags, debris, etc. if you don't need to.