HomeDecor

v12.0.126 (2026-07-01)

Full Changelog Previous Releases

• Update .pkgmeta
• Update HomeDecor.toc
• Update .pkgmeta
  remove herebedragon - krowi - acedbicon
• Merge pull request #5 from Royaleint/feature-libmapsuite-migration
  Replace HereBeDragons/Pins, Krowi_WorldMapButtons, LibDBIcon-1.0 with LibMapSuite-1.0
• chore(libmapsuite): trim redundant comments
  Several comments restated the same explanation in multiple places
  (caller-provided-frame handling repeated four times in
  WorldMapButtons.lua's Configure; the SetParent/frame-level gotcha
  explained fully in both CreatePin and Reposition). Consolidated each
  into a single comment at its first occurrence and shortened the
  remaining WHY comments to one line where the fuller version added
  no new information.
  Co-Authored-By: Royaleint and Claude Code
• fix(libmapsuite): reparent pin to canvas before setting frame level
  Debug instrumentation confirmed the actual mechanism: every zone-map
  pin logged frame level 4, exactly canvasLevel(3)+1 -- WoW's default
  level a frame gets when parented to a frame with no level set. This
  proved CreatePin's SetFrameLevel(2023) call was being silently
  overwritten by a WoW client behavior: SetParent() resets a frame's
  level to (newParent:GetFrameLevel() + 1) unless the level is
  re-applied afterward.
  CreatePin set the pin's strata/level while the caller-provided pool
  frame was still parented to WorldMapFrame (not the canvas); the
  reparent to canvas then happened moments later inside Reposition,
  wiping the level back down below Blizzard's own map art.
  Fixed by reparenting the pin to canvas in CreatePin itself, before
  strata/level are set, so the later Reposition check
  (GetParent() ~= canvas) is a no-op and the level sticks. Also removes
  the temporary diagnostic prints added to isolate this.
  Co-Authored-By: Royaleint and Claude Code
• fix(libmapsuite): stop Reposition from reverting pin frame level
  CreatePin sets an absolute frame level (2023, matching Blizzard's own
  Area POI pins) so world-map pins render above the map's terrain and
  decoration layers instead of underneath them. But Reposition -- called
  immediately after CreatePin, and again on every map show/zoom/pan --
  had its own separate SetFrameLevel call using the old canvas-relative
  formula (canvas level + 100, ~103). That silently reset the pin back
  to the broken low level a moment after CreatePin set it correctly,
  which is why the previous frame-level fix had no visible effect.
  Frame level is now set once, absolutely, in CreatePin only.
  Co-Authored-By: Royaleint and Claude Code
• Fix zone-map vendor pins rendering behind map art (invisible)
  World-map pin frame level was computed relative to the canvas's own
  frame level (~3 + 100 = ~103) at HIGH strata. Blizzard's own map pins
  (Area POI, Event POI) sit at MEDIUM strata with an absolute frame level
  around 2023/2737. At zone zoom, our pins ended up far below Blizzard's
  own terrain/decoration/POI layers -- correctly positioned, sized, and
  "shown", but rendered underneath everything, hence invisible. Continent
  view happened to have little/nothing at those low levels, which is why
  badges looked fine while zone vendor pins did not.
  Matched Homestead's MapPinProvider.lua, which already uses the same
  MEDIUM strata / absolute 2023 frame level for exactly this reason
  (shares Blizzard's own Area POI level so neither dominates the other).
  Confirmed via live debug instrumentation during Gate 2 testing: pin
  was shown, parented, correctly positioned/sized at every zoom level
  tested, ruling out the position/scale math before landing on frame
  level as the actual cause.
  Co-Authored-By: Royaleint and Claude Code
• Fix badge icon stomping and remove dead zone-map pin fallback
  ApplyAppearance() re-textured any pin.icon it found unconditionally,
  including caller-provided frames that already had their own icon
  texture set (HomeDecor's badge pins use an .icon field, unlike vendor
  pins which use .tex) -- badges rendered a question-mark placeholder
  instead of their real texture. Guard the same way Configure() already
  guards world-map buttons: only manage the icon when the library owns
  the frame or the caller opts in via data.icon.
  HomeDecor's own AddWorldMapPin wrapper also carried a leftover
  "is this map supported" check inherited from HereBeDragons-Pins' old
  static per-zone coordinate database -- a concept LibMapSuite's live
  C_Map-based coordinate translation doesn't need. When it returned
  false, it fell back to WorldMapFrame:AcquirePin() fed a non-template
  custom frame, which silently produced nothing -- zero vendor pins on
  any zone map. Removed the gate; always call the library directly,
  matching the already-working badge code path.
  Found during in-game Gate 2 testing (steps 5 and 6).
  Co-Authored-By: Royaleint and Claude Code
• Fix world-map pins rendering far smaller than intended
  WorldMapFrame's canvas runs at a much smaller effective scale than the
  screen (part of the continuous zoom/pan system). A pin frame parented to
  it with SetScale(1) inherits that reduced effective scale and renders
  tiny relative to its actual SetSize. Counter-scale by
  UIParent:GetEffectiveScale() / canvas:GetEffectiveScale(), matching the
  same fix Homestead's MapPinProvider already uses for the identical
  canvas-scale mismatch, and divide the SetPoint offsets by that scale so
  position stays correct.
  Found during in-game Gate 2 testing of the HomeDecor migration off
  HereBeDragons-Pins.
  Co-Authored-By: Royaleint and Claude Code
• Replace HereBeDragons/Pins, Krowi_WorldMapButtons, LibDBIcon-1.0 with LibMapSuite-1.0
  Vendors LibMapSuite-1.0 (a single embeddable map/minimap library) in place
  of three separate third-party libraries, and rewrites the three consumer
  areas (world/minimap vendor pins, the world-map button rail, and the
  minimap launcher button) against its API.
  Patches LibMapSuite-1.0's world-map button Configure() so a caller-provided
  frame keeps its own icon texture and click/hover scripts (hooked rather than
  overwritten), matching the convention its pin code already used. Without
  this fix the button's icon and click handling would have been silently
  replaced with library defaults.
  Co-Authored-By: Royaleint and Claude Code