Campaign Pack – Unity editor tools

[EwyBoy]

Campaign Packs could become the clean way to bundle a “way to play” without forcing every mod to own the whole game setup.

A pack can point at a galaxy, tech tree set, mission set, and science set, while extensions let other mods add or remove content without having to copy the whole thing. So one mod could add a planet pack, another could add missions for it, another could rebalance the tech tree, and they can all layer onto the same campaign setup instead of creating a bunch of incompatible forks.

For players, this could just become a simple choice when starting a save: stock-style Redux campaign, KSP1-inspired progression, a planet-pack campaign, a hard-mode career, a science-only setup, etc.

For modders, the main benefit is that they can make focused content. They do not need to rebuild a full campaign definition just to add five missions or a few tech nodes. They can create a small extension that targets an existing pack or set, and the system resolves the final playable campaign from all the pieces.

---

Summary

This PR adds an editor-authoring-only campaign pack data model and Unity Editor workflow. The goal is to let us iterate on the data shape without touching runtime campaign loading yet.

For now, .asset files are the source of truth while modders are building and testing. Once the structure settles, we can bake these assets out to JSON for runtime and Patch Manager integration.

Authoring Model

The current model is split into a few separate authoring assets:

• CampaignPack

  • The player-facing campaign definition.
  • Points at a galaxy definition.
  • Optionally points at a tech tree set, mission set, and science set.

• TechTreeSet

  • Whitelist/list of tech node IDs.

• MissionSet

  • Whitelist/list of mission IDs.

• ScienceSet

  • Experiment IDs, science region IDs, and discoverable IDs.

• CampaignPackExtension

  • Lets another mod add/remove content from an existing pack or set without needing to clone the whole thing.

Why This Is Split Up

The main reason for splitting the model this way is to avoid tying planet packs, missions, tech trees, and science content too tightly together.

A campaign can reuse the same galaxy while swapping in a different mission set or tech tree. Other mods can also extend existing packs/sets instead of creating a whole matrix of duplicate campaign definitions.

Editor Workflow

For testing and iteration, this PR adds Unity Editor UI around the new model:

• Asset creation menu items under Assets/Redux SDK
• Custom inspectors with autocomplete-ish fields
• Validation warnings/errors
• Campaign Packs browser window under Modding/Campaign Packs/Browser
• Effective content preview for base pack + extensions - removals
• JSON bake buttons so we can inspect the eventual runtime artifact shape

Resolver Behavior

The resolver currently applies content in this order:

1. Start with the base pack’s referenced sets.
2. Apply matching extensions/additions.
3. Apply removals last.

This means removals win if something is both added and removed.

Validation

Validation currently checks for things like:

• Missing IDs
• Duplicate IDs
• Unknown references
• Extensions that do not target anything
• Add/remove conflicts

---

This does not hook into actual campaign loading yet.
But I got a PR for the PatchManager to be able to load the addressable baked files here: KSP2Community/PatchManager#50

This PR is only the high-level authoring model and editor workflow so we can experiment with the structure, see how modders would interact with it, and avoid locking ourselves into runtime behavior too early.