How the game's content is organized

Before you can target a patch, it helps to know how the game stores the things you are patching. This page is the small mental model that makes the rest of the docs click. You do not need to memorize anything here, you just need the vocabulary.

Assets

The game keeps most of its content as data, loaded through Unity's Addressables system. Each separate piece of content is an asset: one part is an asset, one celestial body is an asset, one resource, one mission, one tech-tree node. An asset is a JSON record describing that one thing. PatchManager runs your patches against assets as they load.

The assets that load depend on the campaign. Each campaign has a set of campaign features. Content belongs to features:

  • The Redux parts belong to Ksp2Redux:Parts.

  • The Redux bodies belong to Ksp2Redux:Galaxy.

  • The Redux visual changes, for example cloud layers and engine plumes, belong to Ksp2Redux:Visuals.

  • The Redux gameplay changes, for example the time warp altitude limits on airless bodies, belong to Ksp2Redux:Gameplay.

  • The content of a mod belongs to that mod.

A campaign loads only the content that its features allow. It runs only the patches that its features allow.

Addresses (the ids you target)

Every asset has a globally unique address, a string that identifies it. This is the id you pass to :Named. The EVA Kerbal's address is eva_kerbal. The Mun's is Mun. A tech node's is tNode_2v_rockets_01. When a page says "the asset's id" or "the asset's name," it means this address.

You may be able to guess these, however you should not. They are internal ids, not the display names you see in game, so the next question is always "how do I find the real address of the thing I want to patch?"

Labels (the groups assets load in)

Assets are tagged with labels that group related assets so they load together. Every part shares one label, every celestial body shares another, and so on. A patch is registered against a label and then narrowed to specific assets by address:

  • The typed modules pick the label for you. PM.Parts is the parts label, PM.Planets is the bodies label, so you never type it.

  • The generic JSON API takes the label as a string, like PM.JSON:Patch("game_mode", ...), for content with no typed module.

So the two-step mental model for targeting is: a patch covers a label (a whole group), and :Named narrows it to particular addresses within that group. That is all targeting assets is.

Finding a real address

The reliable way to learn an asset's address is to look at what the game actually loaded. After the game runs one time, PatchManager writes the final state of each asset into a folder called pm_cache. It writes one .zip for each label, for each feature set that it patched for. For example, parts are under the parts_data label. In the archive, each asset is a file with its address as the name.

To find the id of a part, open the parts_data archive and read the file names. That gives you a complete list of real ids to target. The same trick shows you an asset's full contents, which is how you learn what fields a kind of content has. Inspecting the cache shows how to find the archive for a label.

One more thing: assets can be nested

An address points at one asset, and that is flat: one part, one address. But the asset's contents can be a tree. A part, for example, holds modules, and those modules hold data entries, which is why you will later see paths like part.Module_Engine.Data_Engine.someField. The addressing stays simple (one id per part), only the data inside is layered. The Parts pages cover that nesting when you get there.