# Shipping patches

Once your patches work locally, you package them as a mod so other people can install them. A patch mod is the same kind of mod as any other Redux mod. It just happens to contain Lua patches instead of (or alongside) a compiled assembly.

## The minimum

A shippable patch mod is a folder with:

* a `swinfo.json` manifest, and
* one or more `.lua` patch files anywhere inside it.

The manifest identifies the mod, this is what ones looks like and makes for a good copy-able template.

```json
{
  "spec": "3.0",
  "mod_id": "BetterParts",
  "name": "Better Parts",
  "author": "Your Name",
  "description": "Tweaks a handful of stock parts.",
  "source": "https://github.com/yourname/better-parts",
  "version": "1.0.0",
  "version_check": "https://raw.githubusercontent.com/yourname/better-parts/main/swinfo.json",
  "ksp2_version": { "min": "0.2.8", "max": "*" },
  "dependencies": [
    { "id": "SpaceWarp2", "version": { "min": "2.0.0", "max": "*" } }
  ],
  "conflicts": []
}
```

* `**mod_id**` is your mod's id. It is what `ModId` resolves to in your scripts and what other mods use when they declare a dependency on yours. Keep it a simple identifier-style name like `BetterParts`: start with a letter, then letters, digits, and underscores only. Keep it stable across releases: changing it makes your mod look like a different mod to anything that depended on it. Mod ids are matched case-insensitively.
* `**name**`, `**author**`, `**description**`, `**source**` are display text shown to users.
* `**version**` is your mod's version, using semantic versioning. Bump it on each release. `version_check` optionally points at a hosted copy of this file so the game can tell users an update exists.
* `**spec**` is the manifest format version. Use `3.0` for new mods.
* `**ksp2_version**` is the game version range your mod supports. `"*"` means no upper bound.
* `**dependencies**` lists other mods that must be present, each with a version range. If your patches only make sense with another content mod installed, add it here, and also declare it on the patch with [`:Needs`](/doc/dependencies-and-ordering-werp1yYh7P).
* `**conflicts**` is the mirror of dependencies: mods yours must not run alongside.
* `**features**` is optional. It declares the [features](/doc/campaign-features-9YIewcIArR) of your mod in addition to the default feature. Players can then turn on parts of your mod for each campaign. Its keys are lowercase: `requires`, `conflicts`, `provides`, `recommended`.

Each mod has a default feature, `mod_id:mod_id`. When this feature is on in a campaign, the mod is on in that campaign. Your `dependencies` become the requirements of that feature. Your `conflicts` become its conflicts. Thus a campaign that has your mod on always has your dependencies on.

## A typical layout

```
BetterParts/
  swinfo.json
  patches/
    engines.lua
    tanks.lua
  lib/
    _shared.lua
  README.md
```

The `patches/` split is purely organizational. The underscore on `_shared.lua` keeps it from running as a patch on its own, so it can be a helper library that `engines.lua` and `tanks.lua` pull in with `require`. See [Sharing Lua with require](/doc/sharing-lua-with-require-hXbW2HK8Ep).

## Installing

Users install a patch mod the same way as any Redux mod: they place the mod folder into the game's `mods` folder. On the next launch, PatchManager discovers the `.lua` files inside it and runs them.

When a user installs a mod, the mod does not automatically go into campaigns. A new campaign has your mod on only in these conditions:

* The campaign pack lists one of your features.
* The player marked your mod under **Default Features** in the mods menu.
* The player turned your mod on with **Edit Pack**.

The next time an existing save loads, it offers the features of your mod to the player. Tell your users which of these steps to do, or ship a [campaign pack](/doc/campaign-packs-5HBzAytKyU) that turns your features on.

For a quick personal tweak that you are not distributing, you can skip the mod folder entirely and drop a single `.lua` file straight into the `mods` folder. See [file layout and discovery](/doc/file-layout-and-discovery-vYcsLN5rtw). For anything you hand to other people, ship a real mod folder so it has a stable id, a version, and room to grow.

## Declaring dependencies

If your patches only make sense when another mod is present (you patch a part that mod adds), or must not run alongside a mod they would conflict with, declare that on the patch itself with `:Needs` and `:Conflicts` rather than hoping load order works out. These methods count a mod only when it is installed and its default feature is on in the campaign. See [Dependencies and ordering](/doc/dependencies-and-ordering-werp1yYh7P) and [Cross-mod compatibility](/doc/cross-mod-compatibility-Kprr92mfVd).