Dependencies, conflicts, and ordering

Prefab patches use the same coordination model as Patch Manager text patches. Most patches should stay in the default pass and default ordering bucket.

Patch IDs

The full patch ID is mod-id:patch-name. Visual authoring takes the mod ID from the selected Mod asset. C# and Lua authoring take it from the calling mod.

Use the short patch name for another patch in your own mod. Use the full ID for a patch owned by another mod.

Requirements and conflicts

Needs Mods means the patch only runs when every listed mod is on in the campaign. Use it when you target a prefab, component, or Addressable supplied by another mod.

Conflicts Mods removes the patch when any listed mod is on in the campaign.

A mod is on in a campaign when it is installed and its default feature is on in the feature set of the campaign.

Needs Patches means the listed patches must also be active. It is required when you target an object or component introduced by another patch.

Conflicts Patches prevents two specific patches from applying together.

These conditions are recorded in pm_summary.log when they remove a patch.

Features

Every prefab patch applies only in campaigns where the default feature of its owning mod is on. Two lists in the metadata add more conditions:

  • Required Features: all of these features must be on.

  • Excluded Features: all of these features must be off.

A bare id is a feature of the owning mod. The fields autocomplete feature ids. In code, the same lists are :Feature / :NoFeature in Lua and Feature / NoFeature in C#.

If the features of a patch are off in a campaign, the plan of that campaign does not include the patch.

Passes and buckets

Passes run in this order:

  1. Early

  2. Default

  3. Late

Inside each pass, buckets run in this order:

  1. First

  2. Default

  3. Last

A normal mod patch should use Default / Default. Early, Late, First, and Last are broad controls intended for cases where precise relationships are not enough.

Relative ordering

Before Patches and After Patches order against specific patch IDs.

Before Mods and After Mods order against every patch owned by the listed mods.

Relative ordering only works when both patches are in the same pass and bucket. A relationship cannot override the pass/bucket order.

Avoiding cycles

Prefer one direct relationship against the patch that matters. Broad before/after-mod rules are easier to turn into cycles.

A practical recipe:

  • editing another mod's content: add Needs Mods

  • applying only in campaigns where another mod or feature is on: add that feature to Required Features

  • targeting another patch's added object: add Needs Patches

  • overwriting one known patch: stay in the same bucket and use After Patches

  • incompatible implementation: use a conflict instead of relying on load order

If ordering forms a cycle, the plan for that prefab is rejected rather than applied partially.