1.8 KiB
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.