-- The character's kingdom, stored rather than worked out from their race.
--
-- ROM keeps this as `sh_int side` on char_data and writes it to the pfile as its own key
-- (save.c:203, read back at 1392). It is written in exactly two places: the creation menu, where
-- the player picks 1/2/3 (comm.c:2377), and `set side` (act_wiz.c:3656). Race is a separate axis.
--
-- This port had no column for it. Every load ran ApplyRaceTraits, which reassigned the kingdom from
-- the race table -- and because creation filters the race list by the kingdom just chosen, race and
-- side always agreed, so deriving gave the right answer for every character that can currently
-- exist. What it also did was make the disagreement ROM permits impossible to represent: any future
-- `set side`, any race change, and any race whose own kingdom is None would be silently rewritten at
-- the next login rather than reported.
--
-- The values are ROM's, unchanged: 0 = Tier (SIDE_WEST), 1 = Kael (SIDE_EAST), 2 = Undermountain
-- (SIDE_EVIL). AoW.Rules.Kingdom already uses the same numbers.
--
-- DEFAULT -1 IS A SENTINEL, NOT A KINGDOM. It is AoW.Rules.Kingdom.None, which ROM has no equivalent
-- for -- side 0 there is a real side, so ROM cannot express "not known yet" and does not need to.
-- Every row that existed before this migration gets it, and the load path treats it as "derive from
-- the race this once, then keep what you derived". The backfill is deliberately NOT written as SQL:
-- the race-to-kingdom mapping lives in RaceTable, it covers some fifty races, and duplicating it
-- here as a CASE would be a second copy free to drift from the first. Doing it in C# uses the one
-- authoritative table, and the derived value is written out by the next ordinary save.
--
-- So this migration is a no-op for behaviour on the day it runs: every existing character resolves
-- to exactly the kingdom they had yesterday. What changes is that from then on the answer is stored.
ALTER TABLE characters ADD COLUMN side INTEGER NOT NULL DEFAULT -1;
