MythicKeystone_LibDataBroker

v.20260621.1 (2026-06-20)

Full Changelog Previous Releases

• Update the .toc files
• feat(mk): add Blizzard options panel
  Add a Settings panel (Options -> AddOns -> MythicKeystone, or /mkconfig) that
  consolidates MythicKeystone's previously scattered or implicit toggles, all
  persisted to MythicKeystoneDB:
  • show/hide the Alts, Group and Guild panels
  • show/hide the teleport buttons (shared with the in-frame toggle)
  • auto-slot the keystone when opening the Mythic+ UI
  • show/hide the Ready Check and Countdown buttons
    Uses Settings.RegisterAddOnSetting + Settings.CreateCheckbox. The modules expose
    small apply hooks (ApplyPanelVisibility, ApplyAutoKeystoneButtons,
    SetTeleportVisible) so changes take effect live. Strings localized (EN/FR/RU;
    DE/ZH English placeholders, consistent with the existing locale files).
• ci: guard the generated teleport table against drift
  Run generate_teleports.py --check on pushes/PRs that touch the MDN dungeon
  data, the generator, or the generated file, failing if TeleportData.lua is out
  of date so the single source of truth can't silently drift.
• feat(mk/teleport): generate the teleport table from MythicDungeonNotes data
  MythicKeystone hardcoded its own challengeMapID -> teleport spellID table,
  duplicating the spellportalid values already in the MythicDungeonNotes dungeon
  files. They could drift each season.
  Make the MDN dungeon definitions the single source: add challengeMapID next to
  each spellportalid, and add generate_teleports.py which reads those files and
  writes MythicKeystone/TeleportData.lua (ns.TeleportSpells). TeleportButtons.lua
  now consumes that table instead of its hardcoded one. deploy.py regenerates it as
  its first step. Output is identical to the previous hardcoded table (8 dungeons).
• ci(release): create the GitHub release up front to avoid a parallel-create race
  The four per-addon packager jobs run in parallel and each asks the BigWigs
  packager to create the GitHub release for the tag. When two jobs create it at
  the same instant, the losers fail with HTTP 422 "already_exists" (hit when all
  four addons changed and reached the GitHub step together).
  Add a create-release job that creates the release once (idempotently) before
  the packager jobs, which now depend on it and only ever update an existing
  release. No more create race regardless of how many addons release at once or
  whether the release was deleted/recreated.