-- Movement points: the third permanent, and the one that was quietly being thrown away.
--
-- ROM's `ch->pcdata->perm_move`, written alongside perm_hit and perm_mana by advance_level
-- (update.c:211-213) and saved with them. This port had the first two and not the third.
--
-- WHAT THAT COST. Levelling adds a movement roll to MaxStamina, but with nowhere to bank it the
-- number lived only in memory: ApplyBasePools runs on EVERY LOAD and re-derived MaxStamina from the
-- class table, so the accumulation was wiped at each logout and the character came back with the
-- flat class value. The roll floors at 6 and almost always lands there, so a level-20 character was
-- silently losing about 114 movement -- earned over nineteen levels, gone at the loading screen,
-- with nothing anywhere to say so. Hit points and mana were safe only because each had a permanent
-- to derive from; this is the same fault their absence caused, found in the one pool that never got
-- the fix.
--
-- THIS IS A COLUMN, NOT A DATA REPAIR, and the distinction is the whole reason it is this short.
-- The test-mode server WIPES ITS DATABASE AT STARTUP, so there is no stored character that predates
-- this column and nothing to migrate FROM. What the file has to do is make the column exist when the
-- schema is rebuilt from nothing, which is all it does. An earlier draft of this migration carried a
-- backfill rule and a fallback in C# to protect characters saved before it -- guarding a case the
-- build makes unreachable. Both are gone.
--
-- DEFAULT 0 IS THEREFORE NOT A SENTINEL anybody has to interpret. Creation sets PermMove to 100
-- (ROM's clear_char, db.c:2689) before a character is ever written, so a stored zero would mean a
-- character that was never created. ApplyBasePools keeps a floor for it and expects never to use it.

ALTER TABLE characters ADD COLUMN perm_move INTEGER NOT NULL DEFAULT 0;
