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.

{
  "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.

  • **conflicts** is the mirror of dependencies: mods yours must not run alongside.

  • **features** is optional. It declares the features 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.

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 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. 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 and Cross-mod compatibility.