-- A player's action bar is theirs, and has to survive a logout to mean anything.
--
-- ToolbarLayout has carried this as a known gap since it was written: "IT IS NOT PERSISTED YET, and
-- that is a known gap rather than an oversight. A player-defined layout has to survive a logout to
-- mean anything, so this needs a table and a mapping the moment slots become editable." Slots became
-- editable on 17 August, when the author asked for a skills window to drag from. This is the table.
--
-- ONE ROW PER OCCUPIED SLOT, and empty slots are the absence of a row -- the same shape
-- character_skills uses for unlearned skills, and for the same reason: a bar with two buttons on it
-- costs two rows rather than ten.
--
-- WHICH MAKES "CUSTOMISED" AND "EMPTY" INDISTINGUISHABLE, and that distinction is load-bearing, so
-- it does NOT live here. The rule the author chose is that levelling never disturbs a bar you have
-- arranged, and the mechanical default applies only until you first touch it -- so the server has to
-- tell "a character who has never customised" from "a character who cleared every slot". A row count
-- of zero cannot say which. `characters.toolbar_set` carries that flag, and it is why this migration
-- touches two tables for one feature.
--
-- KIND IS STORED BECAUSE A SLOT IS NOT ONLY A SKILL. ToolbarAction has carried that distinction
-- since the bar was built, on the author's own point of 12 August: autoattack is not in skill_table,
-- has no beats and no unlock level, and belongs on the bar anyway. Storing the id alone would make
-- it impossible to tell `autoattack` the builtin from a skill that happened to be called that.
--
-- NO FOREIGN KEY ON THE ID, deliberately. A slot names a skill by the string skill_table uses, and
-- that table is transcribed C rather than a database table -- there is nothing to reference. An id
-- that stops resolving is dropped on load rather than refusing the character, which is the same
-- decision Character.UnresolvedItems makes for a missing item template and is right for the same
-- reason: a renamed skill must not make somebody unable to log in.

CREATE TABLE character_toolbar (
    character  TEXT    NOT NULL REFERENCES characters (name) ON DELETE CASCADE,
    -- 0-9. ToolbarLayout.Slots is ten because the hotkeys are 1-9 and 0.
    slot       INTEGER NOT NULL,
    -- A ToolbarActionKind: 1 skill, 2 builtin. 0 (none) is never written -- see the header.
    kind       INTEGER NOT NULL,
    -- The skill's name, or a builtin's id.
    id         TEXT    NOT NULL,

    PRIMARY KEY (character, slot)
);

-- Whether this character has ever arranged their own bar. See the header: a row count cannot answer
-- it, because a deliberately empty bar and an untouched one both have no rows.
--
-- DEFAULT 0 IS CORRECT FOR EVERY EXISTING ROW. Nobody has customised anything, because until this
-- migration nobody could.
ALTER TABLE characters ADD COLUMN toolbar_set INTEGER NOT NULL DEFAULT 0;
