-
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.
Most of the player-facing functionality in a PartModule is usually handled by [KSPField]s and [KSPEvent]s. Any property with [KSPField(isPersistant=true)] will be automatically saved in craft files and vessels in flight.
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.
The current scene can be accessed via HighLogic.LoadedScene.
In the IVA world, this is an analog to a Part. Each part may specify one InternalModel by name, which will be instantiated when a Kerbal is in the part. The InternalModel contains InternalSeats and InternalProps.
An InternalModel is created from a top-level INTERNAL node in a .cfg file. It may have one or more MODEL nodes that specify the .mu files to instantiate for that internal space. If there isn't one, then a .mu file in the same folder as the .cfg will be used. The collection of InternalModel prefabs is stored in the GameDatabase.
The INTERNAL node may contain PROP nodes which are references to props to place, including their position, scale, and rotation. Typically these are not edited by hand, but created by exporting the internal cfg from PartTools. These PROP nodes may also have MODULE nodes that will be added to that prop's list of modules on load.
The INTERNAL node may also contain MODULE nodes directly. These nodes will create an empty prop in the internal space and add the module to it. This is how InternalSeat and InternalCameraSwitch modules are typically added in the stock internal spaces.
Props are decorations that can be placed in InternalModels. Some of them are actually interactive, like the stock throttle lever prop. And some can show information like the stock altimeter. RasterPropMonitor and MOARdV's Avionics Systems are two mods that expand the functionality of props so that it can be possible to fly entire missions from IVA.
A Prop is created from a top-level PROP node in a .cfg file. It may have one or more MODEL nodes, as well MODULE nodes that give it behaviors. The collection of Prop prefabs is stored in the GameDatabase. These prefabs are cloned when loading the InternalModels into the GameDatabase.
Similar to how PartModules add behaviors to Parts, InternalModules add behaviors to Props. There are 3 ways that InternalModules can be set up in a .cfg file: Inside a top-level PROP node (in which case the MODULE is added to every placement of that prop), inside a top-level INTERNAL node (in which case the module belongs to the internal space itself), or inside a PROP node inside an INTERNAL node (which adds the module to that singular placement of the prop).
This is a star, planet, or moon in the solar system.
The GameDatabase contains all of the loaded content (audio, textures, models, parts, props, and more!) and ConfigNodes.