# 2. Authoring a Content Pack Part of [[Modding with Addressables]]. Prev: [[1. Mods as Additional Catalogs]]. Next: [[3. LoadContentCatalogAsync]]. You can build a pack two official-adjacent ways. Both still use [[6. Content Builds Updates and CI]]. ## 2.1 Same project, later content build Keep the game code in one project. Add a **remote** Addressables group for pack assets, give them a label (`cosmetics`), and produce a **content build** whose catalog you will host or copy next to a later player. This is the "DLC-style pack from the same studio" path. The Addressables series already covers profiles, remote paths, and content updates. This series adds: the **player already shipped** must **load that catalog additively** (part 3), not only the catalog it was baked with. ## 2.2 Second compatible project (official multi-project) Official 2.9.1 [Load content from multiple projects](https://docs.unity3d.com/Packages/[email protected]/manual/MultiProject.html): - Each project uses the **same Unity Editor version** and the **same Addressables package version**. - One project is the **source** (the player you ship). Official typical split: the source holds **code** and little content, plus at least a bootstrap scene (and any scenes that must be local). - **Secondary** projects hold **content** and little code. They need **remote Addressable groups** and **Build Remote Catalog** enabled. - Official warning: **local** data built into a secondary project **cannot** be loaded in the source application's player. Workflow, official: 1. Build remote content for all secondary projects. 2. Build Addressables content for the source project. 3. Enter Play mode or build the source player. 4. In the source project, `LoadContentCatalogAsync` the other projects' remote catalogs. 5. Proceed as normal: addresses from those catalogs can load. Official advice: keep a **minimal local** set in the source so the application can still run if the pack catalog is missing. ## 2.3 Built-in resource bundle names Official: Addressables builds a Unity **built-in resource** AssetBundle for each player-data build. Loading packs from secondary projects can load **several** of those. If they share a name, Unity errors with a message about an AssetBundle that cannot be loaded because another with the same files is already loaded. Official fix: set a different **Built In Bundle Naming Prefix** on `AddressableAssetSettings` in each project. ## 2.4 Shared types If a prefab in the pack uses `CosmeticAttach`, that class must exist in the **source player** (same assembly, same serialization). A script that exists only in the secondary Editor project will not come along in a remote content build in a useful way. Put shared runtime types in the source (or in a shared assembly both compile), not only in the pack project. ## 2.5 Exercise Create a remote group `cosmetics` with one labeled prefab that uses an existing player component (even a `Transform` + a MeshRenderer is enough). Produce a content build ([[6. Content Builds Updates and CI]]). Note the catalog file path and whether a `.hash` file sits beside it (part 3). ## Sources - https://docs.unity3d.com/Packages/[email protected]/manual/MultiProject.html - [[6. Content Builds Updates and CI]]