LibNameplate-1.0 keeps track of nameplates and has callbacks for when they appear/hide on screen. It has API to pull info from nameplates such as name, threat, ect. It also links GUIDs with nameplates allowing you to differentiate plates with the same name.
Here's a addon I've been working on w/ LibNameplate. I'll submit it once the lib gets approved.
Platebuffs preview
At 1:20 you can see the target dummy's nameplates all share the same name and look identical on the screen but the lib's able to tell which nameplate belongs to what dummy.
With the addon people especially warlocks will be able to see who has dots and who needs dots. More dots more dots!
i wonder if you could make educated guesses about guid connections via combat log events and subsequent health changes. like if guid X takes Y damage, then a nameplate with an unknown guid have Y less health next update, you can guess it was guid X...? aoe would have to be factored in i suppose.
i wonder if you could make educated guesses about guid connections via combat log events and subsequent health changes. like if guid X takes Y damage, then a nameplate with an unknown guid have Y less health next update, you can guess it was guid X...? aoe would have to be factored in i suppose.
The problem is you still have to establish a baseline. You might be able to do some weird magic like, track the total damage every GUID takes, include the name and level, then use the nameplates to find the maximum health by name/level and then use it to associate a GUID with a nameplate.
BTW you are using lots of locals (instead of library members). I don't know if it would play well with upgrading. All data stored in onShowHooks, onHideHooks, onUpdateHooks, plateGUIDs, enableMouseFrames, isOnScreen are likely to be lost on library upgrade. This could easily be fixed, e.g. :
lib.onShowHooks = lib.onShowHooks or {}
local onShowHooks = lib.onShowHooks
Moreover, you are not upgrading any nameplate script handlers. So if a new version of the library is loaded when the previous version already has registered some frames, these frames will still use the script handlers of the old version. And as you are hooking, you cannot SetScript again, so I would suggest to do something like this:
-- old ourOnShow
function lib.OnNameplateShow(self, ...)
--[[
ourOnShow code here
--]]
end
local function ourOnShow(...) return lib.OnNameplateShow(...) end
ourOnShow only calls library OnNameplateShow method, which can be upgraded at a later time.
i receive numerous (hundreds) erros in game, they look like this one:
1x LibNameplate-1.0-2:484: table index is nil
LibNameplate-1.0-2:520: in function <...bNameplate-1.0\LibNameplate-1.0\LibNameplate-1.0.lua:504>
LibNameplate-1.0-2:538: in function <...bNameplate-1.0\LibNameplate-1.0\LibNameplate-1.0.lua:527>
LibNameplate-1.0-2:602: in function <...bNameplate-1.0\LibNameplate-1.0\LibNameplate-1.0.lua:592>
(tail call): ?:
Locals:
frame = <unnamed> {
0 = <userdata>
lnpCheckForTarget = false
aloftData = <table> {}
lnpLastUpdate = 3.8970001861453
}
raidNum = 1
from = "UpdateNameplateInfo"
g
LibNameplate_MouseoverNameplate
Fires when user mouseover a nameplate.
Note, use this callback instead of requesting LibNP:GetNameplateByUnit("mouseover") during the UPDATE_MOUSEOVER_UNIT event.
Args
frame: Nameplate frame
But in the code I find this:
local callbackOnHide = "LibNameplate_RecycleNameplate"
local callbackOnShow = "LibNameplate_NewNameplate"
local callbackFoundGUID = "LibNameplate_FoundGUID"
local callbackOnTarget = "LibNameplate_TargetNameplate"
local callbackHealthChanged = "LibNameplate_HealthChange"
local callbackCombatChanged = "LibNameplate_CombatChange"
local callbackThreatChanged = "LibNameplate_ThreatChange"
And no support for LibNameplate_MouseoverNameplate. I missed something, or Callback page need upgrade?
It appears LibNameplate_MouseoverNameplate existed in pre v23 but was removed in v24 when I changed my event handling. I never used the callback myself so I didn't notice it went missing. I readded it back to v35, see if that one works for you.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
API: http://www.wowace.com/addons/libnameplate-1-0/pages/api/
Callbacks: http://www.wowace.com/addons/libnameplate-1-0/pages/callbacks/
LibNameplate-1.0 keeps track of nameplates and has callbacks for when they appear/hide on screen. It has API to pull info from nameplates such as name, threat, ect. It also links GUIDs with nameplates allowing you to differentiate plates with the same name.
Platebuffs preview
At 1:20 you can see the target dummy's nameplates all share the same name and look identical on the screen but the lib's able to tell which nameplate belongs to what dummy.
With the addon people especially warlocks will be able to see who has dots and who needs dots. More dots more dots!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe problem is you still have to establish a baseline. You might be able to do some weird magic like, track the total damage every GUID takes, include the name and level, then use the nameplates to find the maximum health by name/level and then use it to associate a GUID with a nameplate.
It's doable, but it's pretty messy to figure out.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumlocal frames = {WorldFrame:GetChildren()} --... local active = {}Please do not do this !
This can be handled without creating new tables every time you scan the WorldFrame children. For example:
http://paste.wowace.com/1820/
The same applies to IsNamePlateFrame.
BTW you are using lots of locals (instead of library members). I don't know if it would play well with upgrading. All data stored in onShowHooks, onHideHooks, onUpdateHooks, plateGUIDs, enableMouseFrames, isOnScreen are likely to be lost on library upgrade. This could easily be fixed, e.g. :
lib.onShowHooks = lib.onShowHooks or {} local onShowHooks = lib.onShowHooksMoreover, you are not upgrading any nameplate script handlers. So if a new version of the library is loaded when the previous version already has registered some frames, these frames will still use the script handlers of the old version. And as you are hooking, you cannot SetScript again, so I would suggest to do something like this:
-- old ourOnShow function lib.OnNameplateShow(self, ...) --[[ ourOnShow code here --]] end local function ourOnShow(...) return lib.OnNameplateShow(...) endourOnShow only calls library OnNameplateShow method, which can be upgraded at a later time.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1x LibNameplate-1.0-2:484: table index is nil LibNameplate-1.0-2:520: in function <...bNameplate-1.0\LibNameplate-1.0\LibNameplate-1.0.lua:504> LibNameplate-1.0-2:538: in function <...bNameplate-1.0\LibNameplate-1.0\LibNameplate-1.0.lua:527> LibNameplate-1.0-2:602: in function <...bNameplate-1.0\LibNameplate-1.0\LibNameplate-1.0.lua:592> (tail call): ?: Locals: frame = <unnamed> { 0 = <userdata> lnpCheckForTarget = false aloftData = <table> {} lnpLastUpdate = 3.8970001861453 } raidNum = 1 from = "UpdateNameplateInfo" gBut in the code I find this:
And no support for LibNameplate_MouseoverNameplate. I missed something, or Callback page need upgrade?
It appears LibNameplate_MouseoverNameplate existed in pre v23 but was removed in v24 when I changed my event handling. I never used the callback myself so I didn't notice it went missing. I readded it back to v35, see if that one works for you.