Skip to content

Loadout Manager: new module for automatic gear and talent swaps - #2001

Open
dfrisone wants to merge 2 commits into
EllesmereGaming:mainfrom
dfrisone:feat/loadout-manager
Open

Loadout Manager: new module for automatic gear and talent swaps#2001
dfrisone wants to merge 2 commits into
EllesmereGaming:mainfrom
dfrisone:feat/loadout-manager

Conversation

@dfrisone

@dfrisone dfrisone commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Adds EllesmereUILoadoutManager, a new module that applies Blizzard Equipment Manager gear sets and saved talent loadouts automatically when you enter an instance context, resolved per specialization.

Resolution order, first match wins, with the current spec's assignment checked before the All Specs layer:

instance + difficulty -> instance -> specific type (Mythic+, Timewalking, Delve) -> general type -> Open World (on exit)

Written by Tza. He has no GitHub account, so I am opening this on his behalf. Credit for the module is his; any mistakes in how it was reapplied are mine.

On the reapplication

Tza submitted a full-suite zip cut from the v9.1.6 tag, which main had since moved well past. 32 of the 34 files that differed from main were byte-identical to v9.1.6, so they were not his edits at all, just the older base showing through. Merging that tree would have reverted work across Chat, CooldownManager, Bags, UnitFrames, RaidFrames, DamageMeters, Minimap, Quickdraw and four locale files.

This branch is only his six files, applied to current main. In particular the four registration lines are applied to the current EllesmereUI.lua rather than copied from his older copy, since upstream had changed that file in the meantime. The CHANGELOG.md in his zip is packager output and is not included. His files were LF; converted to CRLF to match the repo.

The diff to existing files is 5 added lines and no deletions.

How was it tested?

Not yet tested in game. This is a code review pass plus a clean reapplication; it should not merge before someone runs it.

What I did verify: all three new files compile under Lua 5.1 (luac -p), the locale gate is clean (.tools/extract-locale-keys.sh leaves _keys.txt byte-identical), and the diff to existing files is exactly the five registration lines.

Worth reviewers' attention, since I only read this code rather than ran it:

  • the talent path's sequencing around CONFIG_COMMIT_FAILED and cast interruption
  • behaviour on leaving an instance, where the world pseudo-type applies
  • first swap after a /reload while a request is mid-flight

Two open questions for the author

  1. EUI_LoadoutManager_Options.lua has an empty DualRow right slot at lines 211 and 252. Only the last row of a section may do that. Asked Tza to confirm both are section-final.
  2. announce defaults to true, so once enabled it prints to chat on every swap. Reads deliberate, and silent swaps are arguably worse, but flagging it as a decision rather than an accident.

Note on the style checker

check_style.py reports comment-budget errors at line 2 of both new files. These are false positives and no action is needed. The header block starts on line 2 because line 1 is the EUI_CLIENT_BLOCKED gate, which puts it outside the 30-line header budget and into the 8-line block budget. Every file in the repo trips this; EUI_Fonts_Options.lua and EllesmereUIQuickdraw.lua report the same thing at 18 and 44 lines. This commit used --no-verify for that reason rather than editing a contributor's headers to satisfy a broken rule. The checker is a local dev tool and is not run by CI.

Checklist

  • New settings default OFF (no behavior change without opt-in) -- enabled = false; enabling is what registers the events, so an update never starts swapping gear
  • Zero cost while disabled: no events registered, no polling, no hooks doing work, no frames built -- the event frame is created lazily on first need, and every event is registered only while something requires it
  • Cheap while enabled: event-driven (no polling, no timer-based logic, no per-frame allocations) -- no OnUpdate; the three C_Timer.After(0) calls coalesce event bursts rather than wait on client state; player events use RegisterUnitEvent
  • No writes onto Blizzard-owned frames (weak-table pattern used); HookScript/hooksecurefunc only, never SetScript on Blizzard frames -- the module owns its own frame
  • Tested in-game on live; no version gates or pre-Midnight APIs added -- not yet tested in game, see above

Applies Blizzard Equipment Manager sets and saved talent loadouts on entering
an instance context, resolved per specialization. Resolution runs instance plus
difficulty, then instance, then specific type, then general type, then open
world on exit, with the current spec checked before the All Specs layer.

Written by Tza, who has no GitHub account; this is his 9.6 build reapplied onto
current main and opened on his behalf. His build was cut from the v9.1.6 tag,
which main has since moved 16 commits past, so taking that tree as-is would
have reverted work across nine other modules. Only his six files are here, and
the four registration lines are applied to the current EllesmereUI.lua rather
than copied from his older one.

Off by default: enabling it is what registers the events, so an update never
starts swapping anyone's gear.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant