Files

10 lines
1.8 KiB
Markdown

# Progression and persistence
The server's `how_progression` SQL row is authoritative and keyed by `citizenid`. `getProgression` reads it or inserts a default row. This resource does not contain the original `CREATE TABLE` DDL; inspect the live database/schema source before migration. Do not replace these values with Qbox metadata.
Live columns referenced: `citizenid`, `unknown_introduced`, `crowbar_stage`, `crowbar_rep`, `mack_stage`, `mack_rep`, `tina_stage`, `tina_rep`, `story_stage`, `vinny_fence_unlocked`, `vinny_fence_day`, `vinny_fence_count`. The last three are added via `MySQL.ready` ALTERs. Contact REP is independent; Total REP is derived elsewhere, not stored here. Stage numbers represent availability/completion, while active objectives live only in server memory.
UNKNOWN's successful first SMS sets introduction and at least Crowbar stage 1. Crowbar missions advance expected stages 1→2→3→4→5→6 and grant 5 REP each. Speaking to Mack during Crowbar 4 sets Mack stage at least 1. Easy Rider advances Mack 1→2, grants 5 REP and $300 to eligible participants. Vinny's delayed post-mission SMS separately sets `vinny_fence_unlocked`; it is not inferred from Mack stage. Fence day/count enforce three per game day. Login sync sends a projection of the row to the client to restore Crowbar, Mack and Vinny world access; transient mission state is not reconstructed at login today.
`/prog` is a development command, not a durable phase store. Plain Crowbar/Mack/Tina stages update SQL; `/prog reset` clears the row and inventory to a development baseline. Crowbar `X.Y` shortcuts invoke live mission paths but do not yet rebuild arbitrary phase state. Keep stage and phase APIs separate when modularizing. Preserve column types/defaults and read/write order until a migration is justified and tested.