Runtime and save migrations

For the exact current compatibility line, start with the generated version reference and API changelog.

Published Rift bundles are immutable. PixelRifts either continues to load their declared runtime/schema versions or rejects them with a compatibility diagnostic; publishing a newer draft never rewrites an old bundle.

RiftScript 1 to RiftScript 1.1

No migration is required. A source file beginning with riftscript 1; retains its v1 grammar, formatting, and compiled instructions. Keep that header when editing an established behavior unless you need a 1.1 feature.

To opt in, change the first line to riftscript 2;. You can then use typed let constants, subtraction, multiplication, deterministic division, ordered comparisons, !=, short-circuit &&/||, and pure typed creator functions. Changing only the header does not otherwise change the meaning of v1 expressions. Compile and test the draft before publishing because 1.1 may produce the additive arithmetic/comparison instruction repertoire described in the RiftScript guide.

Published versions are not recompiled from source. Their verified bytecode stays attached to the immutable version that was originally published.

RiftScript 1.1's entity API adds the call_value instruction and Tags component to the additive schema-v2 repertoire. Existing project data has neither and parses unchanged. New query bytecode must be deployed together with the editor, headless validator, browser runtime, and authoritative runtime; older services reject the unknown instruction rather than guessing its result.

Rift save state v2

Save state v2 contains platform-controlled checkpoint, seen-dialogue, inventory, and optional equipped weapon/armor/tool IDs. Older saves and durable retry records had checkpoint/dialogue/inventory fields either without an explicit version or as v1. They migrate deterministically to v2 with no equipment selected.

Unsupported future state versions fail closed. A stored checkpoint, dialogue ID, item, capacity, and quantity is still revalidated against the exact immutable Rift version before play begins. Save migration never executes creator code.

Per-project quotas

For one player and Rift project:

• one state document is at most 32 KiB;
• at most eight immutable-version saves may be active;
• their combined logical JSON is at most 128 KiB.

Reset progress for an old version to free its active slot and bytes. The retained reset generation does not count against the quota and prevents a delayed server write from restoring deleted progress.

The server derives the project that owns each immutable version. Client or service input cannot move a save into another project to evade a quota.

Manual named slots, creator-defined persistent variables, and creator-authored cross-version transformations are not part of save state v2.

Project collaboration migration

PostgreSQL migration 24 adds verified-account project collaborators, consent-based private transfer requests, and append-only collaboration audit records. It changes project authorization data only; editor documents, immutable bundles, and runtime state are unchanged.

Return mission grants

PostgreSQL migration 32 adds one-time weekly and monthly mission-grant evidence. A week starts Monday at 00:00 UTC; a month follows the UTC calendar. Progress counts distinct Daily Rift challenge days backed by platform-owned authoritative Daily mission grants, so replayed attempts and multiple attempts on one day cannot advance a target twice.

The browser can read fixed definitions and its authenticated progress, but it cannot submit progress, choose a period, change a threshold, or select a reward. This migration changes progression persistence only; published Rift bundles, saves, runtime state, protocol v13, and physics compatibility are unchanged.