Getting artifact perks data
 

I would like to get info about which artifact perks are currently active. So far I have the following code:


However this only works when the ArtifactUI is open and I can't figure out how to open it programmatically. Would appreciate some help on that.

As a temporary workaround, you can cache your results. Update your cache any time the Artifact UI is open, or appropriate events fire.

I need the data for a spell dependency list. Like for marksmanship hunters Windburst applies Deadeye (or Vulnurable) when Mark of the Windrunner is selected. However both IsSpellKnown and IsPlayerSpell return false for Mark of the Windrunner and there is no spell added to the spell book. I can't rely on the user opening the artifact UI but I haven't found another way to get that information.

You can open the artifact UI by requesting to socket the artifact through a call like SocketContainerItem or SocketInventoryItem. At that point you should be able to request artifact data.

This is an interesting idea!

On second thought, it is probably not nice to open the artifact UI without a user interaction as it could close other UI panels. And I'll have to rescan in case the user changes their spec and equips another artifact. I really hope they'll make the whole C_ArtifactUI API usable without the artifact UI being visible.

Here is an example on how it could be used:

Yeah, you can also just suppress the artifact UI from opening at all by doing something like unregistering the artifact open event from UIParent and then re-registering after you're done with your info.

The problem with the artifact api being available all the time is that a player could have up to 4 artifacts (druids), that's why you have to specify which one you want data on by using the socket function.

I'm confused, can you not just call LoadAddOn for the load-on-demand Blizzard Addon in question? (Blizzard_ArtifactUI)

@Simca you can load the addon, but the C_ArtifactUI API returns just nils while the ArtifactFrame is not open. Or I'm too short sighted to get it.

@dssd yes, but only one artifact can be active at a time per design. And the API could provide just that info.

@syncrow HasArtifactEquipped() returns true even if the player has respecced but hasn't changed weapons yet, meaning your code gets potentially wrong information.

You'll change weapon automatically when you respec?! Or am I wrong?

Loading an addon out of context doesn't magicly give access to API data and will often times cause errors.



The game tries to swap weapons when you change spec. It'll even unequip your current one if you don't have the artifact for the new spec. Sometimes it bugs out and fails this though.

@Simca Almost the opposite of that is what Rainrider wants I believe. 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:

1. 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)
2. 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.

You can still view the Artifact Perk UI by shift + right click for any artifact that may be in your bags. The artifact API will use whatever artifact is currently 'open', even if it is in your bags.

Pity the API didn't use specID.

Edit:
As this is something I've needed for my own project, I messed around and wrote a quick libstub library for caching artifact information (including those in your bags). Used some of the code above as a base (credit to your macro Rainrider). Data updates is handled by the library, you only need to call the data functions.

This is my first library (woo!) so code could probably be done better. Let me know if you have any issues with it: http://www.wowinterface.com/download...facts-1.0.html

Nice job ! :)
Will check it out for my ArtifactBar in DuffedUI for the tooltip.

Once "Blizzard_ArtifactUI" is loaded, SocketInventoryItem(16) forces the UI to show the ArtifactFrame.

• So you should use this gathering method only before the ArtifactUI was loaded
• Afterwards its better to update your library whenever the ArtifactFrame is shown / updated while shown to avoid closing other frames...

That's basically what I do. I have 3 primary internal functions for gathering. RefreshEquipped(), RefreshBags() handle initial gathering/search functions which has the above check (or similar) and C_ArtifactUI.Clear(). They then call RefreshPowers() function which assumes C_ArtifactUI is populated (it does a small check) and does the actual data population. This is all called during login (PLAYER_ENTERING_WORLD)

During regular gameplay, I call RefreshPowers() and that only occurs during ARTIFACT_UPDATE.

I was originally going to have a force update function, but I don't think that is necessary. Debating on writing a communication portion for sending trait information to other players, however that may be better suited for the addon itself rather than the library.

Small update to the library. Minor optimisations (aka removed the double caching on first load etc), couple of minor changes to the error logic. More importantly added a new public function for number of powers purchased (which is now cached) which saves overhead.

I now class it as feature complete and looks to be working without issue.

Please let me know if you break it. Gathering artifact power to test it during gameplay is rather time consuming :)

The way you uploaded it, it won't load at all (no ToC file).

You need a way to tell users when data changed. You could use CallbackHandler for this.

Your RefreshEquipped() and RefreshBags() are double dipping as SocketInventoryItem and SocketContainerItem will issue ARTIFACT_UPDATE and your event handler will call RefreshPowers() again.

As long as you call RefreshEquipped() and RefreshBags() only at PLAYER_ENTERING_WORLD (PEW) you could spare the checks for ArtifactFrame. Your first call to SocketInventoryItem will load the ArtifactUI and from then on you actually open and close ArtifactFrame for every artifact in the player's inventory. This is probably not a problem as the user won't have any open UI panels during PEW. If you change this (by adding a forced update), you will have to consider that the ArtifactFrame listens for ARTIFACT_UPDATE as well.

GetPowerPurchased actually returns the number of purchased traits. Maybe GetNumTraitsPurchased would be a better name. Same goes for GetPowers and the like. I know you follow Blizzard's own naming here, but they probably coded that before the UI wording was set in place and didn't care to update the API to reflect that. Also prepending Lib to your addon name would be nice, but this is just my personal taste.

As for features, you could also provide the knowledge level and multiplier as those are only available when the ArtifactFrame is shown. They are shared between artifacts. The API for them is C_ArtifactUI.GetArtifactKnowledgeLevel() and C_ArtifactUI.GetArtifactKnowledgeMultiplier().

Nice feedback. First library I've written, so a small learning curve - but everything helps :)

The library will work fine if it's embedded and your addon is reacting to events to pull data. I can make it standalone enabled and implement CallBackHandler to fire a cache update event, which will make this a little more friendly for UI display updates.

Feature wise, this was more intended towards caching just the traits. However thinking on it, it might be better to simply expand it to cache more of the data provided by C_ArtifactUI API (saves future requests). I'll need to look at the API listing again and see how best to manage what options there are. I don't want the library to take up too much UI time if I can help it. A fair bit of the functions will likely not be needed.

Naming wise was to keep it the somewhat similar to Blizzard's, as this partially turns the library into a cached alias for C_ArtifactUI, which is why I've opted to return information in the same format. I did totally do a goof on PowersPurchased (should have used GetTotalPurchasedRanks) :P

This was the case on the first release and should be fixed in the 1.1 version. I basically shifted f:RegisterEvent('ARTIFACT_UPDATE') into the PEW event code, and then unregistered the PEW event to avoid rescanning whenever you hit a load screen.

--
One thing I've been debating on is if I should add bank inventory scanning - I'm leaning towards yes, regardless of how unlikely it is for an unscanned artifact to be equipped and used prior to caching that specific artifact. However this is entirely dependant if I can code it such that it doesn't intrude on the user - part of the issue is you can't 'socket' an item whilst it's in the bank.

Thanks again. Will keep the update discussion in this thread as I progress :)

edit:
Initially I was going to keep this in, but after playing around with bag scanning after closing the bank it's far simpler to simply register/unregister both the UI and my controller for ARTIFACT_UPDATE during the scan. This avoids multiple triggers and it's fast enough.

The only issue is that if you have the artifact frame open, then close the bank - the artifact frame will close due to the data caching. I'd rather not have the library do this, but there's no other way to cache a new artifact. Something to muse over.