# 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](/doc/campaign-features-9YIewcIArR). 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](/doc/typed-modules-nMMO0SZ6ac) 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](/doc/generic-json-api-fqEwMuvrGb) 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](/doc/targeting-assets-8eefHSmg4w) 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](/doc/caching-and-invalidation-QifFi4oev9) 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](/doc/parts-TLgScEaMqZ) pages cover that nesting when you get there.