# 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](/doc/campaign-features-9YIewcIArR) 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.