Originally Posted by dssd
[...] When you use socket item that tells C to prepare artifact data for that artifact. When it's ready it fires the "ARTIFACT_UPDATE" event which Blizzard's Lua code looks for. That's how it knows to load the addon if it isn't already and open the UI. I believe Rainrider wants to just have C prepare the data without opening the Lua UI. That's why I recommended unregistering Blizzard's code from "ARTIFACT_UPDATE" before asking C to load the data for an artifact.
@syncrow I believe it leaves it equipped but in an "unusable" state kind of like if an equipped item reaches 0 durability.
|
Tested with the macro:
lua Code:
/run local u,e,a=UIParent,"ARTIFACT_UPDATE",C_ArtifactUI;u:UnregisterEvent(e);SocketInventoryItem(16);for i,p in ipairs(a.GetPowers()) do print(GetSpellInfo((a.GetPowerInfo(p)))) end;a.Clear();u:RegisterEvent(e)
- You have to do C_ArtifactUI.Clear() when ready or else the artifact item remains in a locked state (item is grayed out and Shift+Right Clicking it no longer works)
- Once the ArtifactFrame has been opened, this no longer prevents the artifact UI from opening. You have to unregister "ARTIFACT_UPDATE" from ArtifactFrame as well (remember checking for nil here, as the ArtifactFrame exists only after Blizzard_ArtifactUI has been loaded)
You could use
GetInventoryItemQuality("player", INVSLOT_MAINHAND) == LE_ITEM_QUALITY_ARTIFACT and
GetInventoryItemEquippedUnusable("player", INVSLOT_MAINHAND) to check whether the right artifact is currently equipped.
Also using just SPELLS_CHANGED for tracking changes seems to be enough, at least for my purposes, but I haven't tested this extensively yet.