FLIGHT MANUAL / 02 · START
Installer & verification
The beta.4 installer carries its release payload inside the executable and treats every update as a verified transaction.
One authenticated download
Beta Access delivers one Windows x64 executable. There is no second bundle to locate, no CKAN workflow, and no code-signing certificate.
Because this closed beta is intentionally unsigned, Windows may show an unknown-publisher warning. Confirm the filename and compare the SHA-256 value shown on Downloads before running it.
Embedded payload and official dependencies
The executable embeds a schema-versioned KMS payload. Its manifest declares every KMS file by path, byte length, and SHA-256 digest.
Large or redistribution-restricted mod families are downloaded only from pinned HTTPS locations operated by their upstream projects. Every archive is accepted only when its SHA-256 matches the release manifest. Required failures stop the transaction; optional performance or visual packages report a warning and continue.
Embedded: kms-manifest.json + GameData/KodyKSPSuite/...
Automatic: official HTTPS package + pinned SHA-256Storage behavior
Download cache, staging, transaction backups, and the receipt are created beside the selected KSP copy. The installer does not use the C: drive for the large mod cache when KSP is on another drive.
A valid cached archive is reused by its content hash. Interrupted downloads resume when the server supports ranges.
Installation transaction
- Validate the selected KSP root and exact 64-bit KSP 1.12.5 build.
- Refuse the operation if that selected KSP process is running.
- Verify the embedded manifest and all embedded bytes.
- Acquire and verify pinned official dependencies into .kms-cache.
- Extract dependencies and then apply the KMS compatibility overlay in a transaction-specific staging folder.
- Back up every existing destination file into KMS-Backups.
- Commit staged files and write .kms/installed.json.
- If commit or receipt creation fails, restore replacements and remove files newly created by the failed transaction.
Player-data preservation
The payload never targets saves, craft, screenshots, flags, or game preferences. Existing PluginData content and personal settings.cfg/displayInfo.cfg files are preserved when a managed component supplies defaults.
KMS upgrades the selected copy in place. Keep a separate clean KSP archive as your immutable recovery source.
Receipts and provenance
The install receipt records the suite version, UTC install time, absolute KSP root, installed file manifest, acquired component versions and hashes, and backup location. It is the authoritative inventory for diagnostics and future upgrades.
Wizard flow
- Welcome explains scope and the unsigned-beta trust model.
- KSP Installation discovers or browses to the target and validates it.
- Review summarizes the embedded file count, required and optional downloads, storage drive, and preservation behavior.
- Install shows phase, progress, warnings, and a detailed event log.
- Ready to Fly offers Launch KSP and Open Docs without starting either automatically.
Failure behavior
Validation failures stop before staging. Download or staging failures leave the game untouched. Commit failures trigger rollback of both replaced and newly created files.
Do not launch immediately after a failed transaction. Preserve the event log and confirm that rollback completed first.
Volumetric Clouds
KMS never bypasses a paywall or mirrors Blackrack Volumetric Clouds. Beta.2 supports the verified Classic Spectra/EVE/Scatterer path; a legitimately acquired volumetric package remains a separate private-development option.