FLIGHT MANUAL / 03 · START

Updates & rollback

Treat KSP updates, KMS updates, and save migrations as separate events. Change one layer at a time.

Before an update

  1. Exit KSP.
  2. Copy the entire save folder you intend to test.
  3. Record the current KMS version from .kms/installed.json.
  4. Retain the previous installer and KMS-Backups transaction.
  5. Compare the new installer SHA-256 with the authenticated Downloads page.

Upgrade

Run the newer installer over the same KSP root. Existing managed files are backed up before replacement. Beta.2 preserves unrelated mods, saves, craft, screenshots, and personal PluginData settings.

Rollback manually

  1. Exit KSP.
  2. Open the exact transaction folder shown in the install receipt.
  3. Copy its GameData subtree back over the KSP root.
  4. Remove only newly introduced files listed in the newer receipt and absent from the older receipt.
  5. Delete ModuleManager.ConfigCache and launch once to rebuild patches.
DO NOT ROLLBACK A LIVE SAVE BLINDLY

Parts or modules introduced by a newer version may be serialized into vessels. Test rollback against a copied save first.

KSP version changes

KMS beta targets KSP 1.12.5. Do not point the installer at another KSP version even if it appears to launch; assembly and data compatibility are not inferred from the version number alone.

Read KMS versions

Versions use semantic versioning with prerelease labels. Beta builds may change save-facing modules and must include migration notes. A channel controls audience; it does not change the bytes or version identity of an artifact.

When to rebuild caches

Delete ModuleManager.ConfigCache only when patch inputs or assemblies changed, or when a release note instructs you to. Preserve the old cache with diagnostics first. Visual shader caches and Burst caches follow their own fingerprints and should not be purged reflexively.