tooling: batch pck → m2p migration script with per-pack validation #1

New Issue

jann · 2026-04-15T11:46:57+02:00

jann commented

2026-04-15 11:46:57 +02:00

Today I mass-migrated the remaining 68 legacy .pck groups from the canonical client runtime into .m2p format in a single bash loop. It worked (68/68 build OK, 68/68 m2pack verify OK, client boots all 110 m2p cleanly), but it was done entirely in terminal history — no script, no per-pack gate, no record of which packs produced which content issues.

This is fine as a one-off, but the migration workflow documented in docs/migration.md ('Practical migration loop') describes a per-pack gate with validation:

Pick one legacy pack group.

Rebuild it as .m2p.

Verify it.

Diff it against the source tree.

Boot the client with runtime keys.

Run the runtime scenario gate.

Validate asset loads in logs and in-game.

Move to the next pack group.

Mine skipped steps 4, 6, 7. For a production cutover that's not OK.

What needs to exist

A scripts/migrate_pck_group.py (or similar) that given:

a source asset dir (e.g. m2dev-client/assets/<Name>)
a master key + signing key
a legacy .pck for comparison

produces the .m2p, runs m2pack verify, runs m2pack diff against the source, and runs the runtime gate (validate_runtime_gate.py). Fail-fast if anything regresses the known-issues baseline.

A second script scripts/migrate_all_pck.py that drives the above over a whole runtime tree with a progress log and a JSON report (per-pack pass/fail, entry counts, size before/after).

Today's ad-hoc loop for reference:

for line in /tmp/migration-map.txt; do
  stem=$(echo "$line" | cut -d' ' -f1)
  asset=$(echo "$line" | cut -d' ' -f3)
  m2pack build --input "$ASSETS/$asset" --output "$OUT/${stem}.m2p" \\
    --key master.key --sign-secret-key signing.key --key-id 1 --json
done

68 packs converted in ~2 minutes wall clock, total .m2p size ~753 MB vs .pck at ~1059 MB (-29%).

None of the 68 have been runtime-validated yet — client boots and Python init completes, but no in-game walkthrough or scenario coverage was exercised. That part needs to happen before this can be trusted for a production release.

Today I mass-migrated the remaining 68 legacy `.pck` groups from the canonical client runtime into `.m2p` format in a single bash loop. It worked (68/68 build OK, 68/68 `m2pack verify` OK, client boots all 110 m2p cleanly), but it was done entirely in terminal history — no script, no per-pack gate, no record of which packs produced which content issues. This is fine as a one-off, but the migration workflow documented in `docs/migration.md` ('Practical migration loop') describes a per-pack gate with validation: > 1. Pick one legacy pack group. > 2. Rebuild it as `.m2p`. > 3. Verify it. > 4. Diff it against the source tree. > 5. Boot the client with runtime keys. > 6. Run the runtime scenario gate. > 7. Validate asset loads in logs and in-game. > 8. Move to the next pack group. Mine skipped steps 4, 6, 7. For a production cutover that's not OK. ## What needs to exist A `scripts/migrate_pck_group.py` (or similar) that given: - a source asset dir (e.g. `m2dev-client/assets/<Name>`) - a master key + signing key - a legacy `.pck` for comparison produces the `.m2p`, runs `m2pack verify`, runs `m2pack diff` against the source, and runs the runtime gate (`validate_runtime_gate.py`). Fail-fast if anything regresses the known-issues baseline. A second script `scripts/migrate_all_pck.py` that drives the above over a whole runtime tree with a progress log and a JSON report (per-pack pass/fail, entry counts, size before/after). Today's ad-hoc loop for reference: ```bash for line in /tmp/migration-map.txt; do stem=$(echo "$line" | cut -d' ' -f1) asset=$(echo "$line" | cut -d' ' -f3) m2pack build --input "$ASSETS/$asset" --output "$OUT/${stem}.m2p" \\ --key master.key --sign-secret-key signing.key --key-id 1 --json done ``` 68 packs converted in ~2 minutes wall clock, total `.m2p` size ~753 MB vs `.pck` at ~1059 MB (-29%). None of the 68 have been runtime-validated yet — client boots and Python init completes, but no in-game walkthrough or scenario coverage was exercised. That part needs to happen before this can be trusted for a production release.

jann referenced this issue

2026-04-15 13:00:17 +02:00

runtime-key.json schema mismatch: m2pack CLI output vs launcher RuntimeKey model #3

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: metin-server/m2pack-secure#1