Search the Community

Ahoy Kerbonauts! Senior designer Tom Vinita here with a short update about part modules for you today! Part modules are the extra optional bits of functionality that are added to the part in order to allow it to perform specialized functions. For example, if we add Module_Engine to a part, it now has the ability to provide thrust, consume resources for that thrust, and many of the other essential functions required in a rocket engine. If a part doesn’t have any modules, then it tends to be something simple like a truss or an I-beam. Kerbal Space Program has a lot of different parts, and so it follows that it has a lot of different modules. One of our design goals with Kerbal Space Program 2 is to create a simulation that feels as close to Kerbal Space Program’s as possible while building fresh improvements along the way. If you build a rocket that worked in KSP, it is our goal for that rocket to perform in largely the same way if you rebuild it in KSP2. To that end, the team is going to painstaking lengths to document and remake, and enhance KSP’s extensive list of part modules in addition to all of the new part modules coming in KSP2. To see one example of this in action, let’s take a look at lights: Fairly simple in concept, right? They turn on, and they turn off. Well, KSP’s lights have a little more going on than that, and they’re useful in a variety of important situations. At the start of the process for bringing a part module into KSP2, a designer first studies KSP’s documentation and common uses of the module in question during general gameplay and wacky uses the community has come up with. From there, they write a series of user stories that define a list of use cases that this part module must be able to accomplish. A short example for lights would be: • As a player, I want a tool to help me see the ground when I’m landing on the dark side of a planet. • As a player, when I’m docking I want to be able to see my vessel and the vessel I’m docking with, even when both vessels are in shadow. • As a player, I want to customize my vessel with a wide variety of light patterns, whether they’re stylish, goofy, or both! Once these user stories are defined, the designer studies the player-facing tweakable values of the part—in this case things like the blink timer and the dynamic light color—and the list of values that are exposed in the part’s data for fine-tuning its behavior. The designer provides detailed documentation for everything being brought forward into KSP2, and looks for spots where the module can be enhanced. With all these values defined and the module’s functions outlined, the spec is handed off to an engineer who does the hard work of programming the module. Once the module has been written, it falls to a designer (usually myself) to attach that module to all the necessary parts, tuning the numbers of each part along the way as necessary. You can check out the results of this process below, with the new and improved Mk1 Illuminator showing off its new ability to pitch! That’s a look at some of the work that goes into making sure all the fun stuff you can accomplish in KSP can still be done in KSP2, as well as an example of finding a way to make that fun stuff even better in KSP2. Shine on! -Tom

I've answered a number of questions related to this in recent times, so I figured I'd explain in detail the entire life cycle of a PartModule. Birth When parsing a part from the game database, KSP looks for MODULE nodes to parse as part modules. It looks for a name = XXX value in the MODULE node and tries to find a class that derives from PartModule with that name. If it finds one, it will attach an instance to the part's GameObject (part modules are Unity components and can only exist attached to game objects). The newly created module will then be added to the part's module list. Load(ConfigNode) will be called on the module with that node. This loads any fields with the [KSPField] attribute automatically, and calls OnLoad(ConfigNode) with the same node to allow parsing of any custom data. KSP stores the part (and its modules) as what's called a prefab - any time the part actually needs to exist in the game, this prefab is copied. Instantiation in the Editor When adding a part the the editor, KSP will instantiate (copy) the part prefab. In order to do this, Unity serializes the entire part and then deserializes it as a new instance (see here for more information on serialization in Unity). This is often a source of grief with part modules because custom data frequently does not get serialized (brief note on this below, I will dive into more depth on this issue in a future post) Once all the editor setup is done, the part's Start method will call the module's OnStart method, then Unity will call the module's Start method. Life in the Editor OnUpdate will be called by the part and Update by Unity every visual frame. OnFixedUpdate and FixedUpdate the same every physics frame (even though there's no physics in the editor). Editor Copy The user may copy an existing part in the editor or change the symmetry mode. Either way, KSP makes a copy of the existing part. Instead of copying the prefab as before, KSP will instantiate the existing part instance. The same serialization rules apply. Editor Save When the craft is saved in the editor, Save is called on each part module to save its state. Save writes any KSPField with isPersistent = true to the saved node, saves data about events and action groups, and calles OnSave, which can be used to save any custom data Editor Death When the part is removed in the editor (or a new craft is loaded) the part and all its modules are destroyed completely. No data that wasn't already saved will survive. Creation in Flight This behaves very similar to creation in the editor. The part prefab is instantiated (again, by serializing and deserializing), Load is called with any saved data (which again calls OnLoad to do any custom loading), OnStart is called by the part, then Start by Unity once everything is set up. There's one odd case of this, and that is when dealing with the root part of a vessel already in flight. KSP does instantiate the part prefab (and by extension its modules), but then copies its fields to a new part with new modules. I'm not sure why this is done and it usually doesn't matter, but still something that can cause occasional issues. Life in Flight OnUpdate will be called by the part and Update by Unity every visual frame. FixedUpdate will be called every physics frame, and OnFixedUpdate will be called every physics frame once the part has been activated (i.e. staged). Flight Save Basically the same as in the editor, Save is called on each part module, which writes any KSPField with isPersistent = true to the saved node, saves data about events and action groups, and calles OnSave, which can be used to save any custom data Editor Death When the flight scene is exited, the craft goes out of physics range, or the part explodes, the part is destroyed completely, along with all of its modules. I've probably missed some stuff here, so feel free to ask questions etc.