KPatchwork

KPatchwork makes mods compatible with each other through small, conditional data patches.

What it does

Packs can change recipes or add assets only when a specific combination of mods is loaded. For example, a SatisfactoryPlus + RSS pack can change recipes so they use SatisfactoryPlus items.

Each pack should focus on one compatibility case and keep its changes in readable YAML files.

Working on KPatchwork

KPatchwork is developed in the public repository:

https://github.com/Satisfactory-KMods/KPatchwork

Anyone can contribute a compatibility pack through a pull request. Changes that stay inside the author's own pack are linted, packaged, and may be merged automatically by CI. A successful merge automatically creates and deploys a new release.

The main contribution area is DataForge/:

DataForge/
  <category>/
    <pack-name>/
      pack.yml
      *.yml

To add or update a pack:

1. Create or edit the pack directory under DataForge/.
2. Keep pack.yml complete and list every maintainer in its contributer field.
3. Put the actual data changes in focused YAML files next to pack.yml.
4. Explain which mod combination the pack supports.
5. Run the repository lint before opening the pull request:

uv run --locked Lint/lint_packs.py --root DataForge

Changes to shared tooling, CI, or the KPatchwork plugin metadata should be kept separate from pack content where possible and require maintainer review.

Layout

KPatchwork.uplugin
DataForge/
  **/
    <pack-name>/
      pack.yml
      *.yml

Each pack lives below DataForge/. Its pack.yml must contain one or more contributor GitHub logins in the intentionally stable field contributer:

ref: MyPack
name: My Pack
version: 1.0.0
contributer:
  - github-user
  - another-user
enabled: true

Every pack is linted in CI. Pull requests that only change packs owned by the pull-request author may auto-merge after CI passes. Changes to another contributor's pack, plugin metadata, or repository configuration require an explicit maintainer approval. Changes to the contributer field always require explicit maintainer approval, including changes that add the pull-request author.

CI creates a release ZIP containing KPatchwork.uplugin, DataForge/, and Config/ (excluding Config/Alpakit.ini) and generates CHANGELOG.md from the commit range. Main releases receive <year>.<quarter>.<CI-build-number>, create a GitHub Release with the ZIP and changelog, and upload through ficsit-CLI.

Contributing

Direct pushes to main are disabled. Create a branch, make changes, and open a pull request. See CONTRIBUTING.md.