These forums are in read-only mode. Please see this news post for more information.

New forums can be found here


Go Back   WowAce Forums > Addon Chat > Libraries
Libraries Threads for new libraries and mixins.

Reply
 
Thread Tools
Old 11-14-2013   #11
Adirelle
Legendary Member
 
Adirelle's Avatar
 
Join Date: Dec 2006
Posts: 2,403
Default Re: LibNameplateRegistry-1.0

Quote:
Originally Posted by Archarodim View Post
I'd also like to point out that using the same handler for both is not recommended as those two callbacks behave very differently:

One fires each time a nameplate's frame appears on screen and the other one only fires when new information (the GUID) is available about a nameplate which is already on screen and thus for which LNR_ON_NEW_PLATE fired.
The addon doesn't care about nameplates without GUID. Moreover, if the "unitFrame" is already attached to the same nameplate, :AttachToNameplate does nothing.

Quote:
Originally Posted by Archarodim View Post
You're right it's not that complex, thanks for the code snippet above (that removes me the laziness excuse^^). Anyway I'll regret the animation timer neatness which only executes code when they tick at the scheduled rate. Knowing that "timer = timer - elapsed; if timer > 0 then return end;" will be done 120 times (more or less) per second hurts my perfectionism side
You can do that too :

Code:
if not LNR_Private.Anim  then
  LNR_Private.Anim = LNR_Private.EventFrame:CreateAnimationGroup()
end
if not LNR_Private.Timer then
  LNR_Private.Timer = LNR_Private.Anim:CreateAnimation()
end

LNR_Private.Anim:SetLooping("REPEAT")
LNR_Private.Timer:SetDuration(0.1)

LNR_Private.Timer:SetScript('OnFinished', function()
  -- Copy previous handler there, without the throttle code
end)
Then call LNR_Private.Anim:Play() in :Enable and LNR_Private.Anim:Stop() in isable.

Quote:
Originally Posted by Archarodim View Post
That's what I tried to do at first but it became messy pretty quickly so I decided to do it using a known paradigm, it makes it easier to understand. (I'm very much into OO programming nowadays)
I also wanted to use a shutdown mechanism instead of passing everything to a newer version which would have to know and handle every other previous version particularities to upgrade cleanly. This private/public design simplify things in my opinion, each library version only has to know about itself...
Actually, this is the upgrading process of the defunct AceLibrary. It has been abandoned because it was considered too complex and heavy.
__________________
Author of AdiButtonAuras, AdiBags, Squire2 and several other addons.

Each time you hit your "copy" command with a block of code, think about a way to refactor it so it did what you want without using the "paste" command.
Adirelle is offline   Reply With Quote
Old 11-17-2013   #12
Archarodim
Member
 
Archarodim's Avatar
 
Join Date: Apr 2006
Posts: 37
Default Re: LibNameplateRegistry-1.0

I've removed AceTime-3.0. I found an unrelated race condition bug while testing the new timer implementation. So I decided to release a new version (0.6) before changing the hooking system.

Quote:
Actually, this is the upgrading process of the defunct AceLibrary. It has been abandoned because it was considered too complex and heavy.
I didn't know :/ Maybe I'll reach the same conclusions one day but for now I'm not convinced.
Archarodim is offline   Reply With Quote
Old 12-08-2013   #13
Archarodim
Member
 
Archarodim's Avatar
 
Join Date: Apr 2006
Posts: 37
Default Re: LibNameplateRegistry-1.0

I've made the change concerning hooks in the latest alpha.
Archarodim is offline   Reply With Quote
Old 12-09-2013   #14
Adirelle
Legendary Member
 
Adirelle's Avatar
 
Join Date: Dec 2006
Posts: 2,403
Default Re: LibNameplateRegistry-1.0

I just updated to the latest alpha. I'll do some tests.

My "testing" addon (AdiBuffPlate) creates frame for enemy to show useful (de)buffs. These frames are identified by the unit GUID. They are attached (e.g. reparented and reanchored) to a nameplate as soon as the nameplate GUID is found. And they should be detached and hidden as soon as the nameplate is recycled.

However, for some reason, that was not happening properly with only the LNB callbacks. I had to double-check if the nameplate GUID still matches my frame GUID (see there) and an OnHide handler (since my frames are parented to the nameplate, their OnHide handler is called when the nameplate is hidden). Please note this was happening with the old LibNameplate-1.0 too, so maybe I'm doing something wrong.
__________________
Author of AdiButtonAuras, AdiBags, Squire2 and several other addons.

Each time you hit your "copy" command with a block of code, think about a way to refactor it so it did what you want without using the "paste" command.
Adirelle is offline   Reply With Quote
Old 12-09-2013   #15
Archarodim
Member
 
Archarodim's Avatar
 
Join Date: Apr 2006
Posts: 37
Default Re: LibNameplateRegistry-1.0

This would mean that you miss some LNR_ON_RECYCLE_PLATE events. If LNR was not firing them, it would trigger its 'hook' sanity check and the library would shut down.

So in the end, since the library is not shutting down, this would mean that libCallBackHandler is not calling some of your callbacks which is quite unlikely.


I think that the problem comes from the way your unitProto.DoLayout() is called. As it's called from an onupdate handler it might get called right after a nameplate is hidden but before it's recycled. I'm not sure of the order in which handlers are called but this might happen.

How did you notice this issue? Have you found an easy way to reproduce it?
I've tried adding calls to error() into your add-on but through my tests I couldn't produce a non matching GUID nor a plate hidden before it is recycled (not counting your internal self:Hide() calls).
Archarodim is offline   Reply With Quote
Old 12-10-2013   #16
Adirelle
Legendary Member
 
Adirelle's Avatar
 
Join Date: Dec 2006
Posts: 2,403
Default Re: LibNameplateRegistry-1.0

Well, I have noticed some frames got hung in the middle of the screen, which was pretty strange. It seems to only happen in the middle of a raid encounter with a good number of adds. I cannot reproduce it. In the latest changes, the unit frames themselves register with LNR so they always check if everything is ok, whatever my common unitFrames table contains.
__________________
Author of AdiButtonAuras, AdiBags, Squire2 and several other addons.

Each time you hit your "copy" command with a block of code, think about a way to refactor it so it did what you want without using the "paste" command.
Adirelle is offline   Reply With Quote
Old 07-25-2016   #17
Archarodim
Member
 
Archarodim's Avatar
 
Join Date: Apr 2006
Posts: 37
Default Re: LibNameplateRegistry-1.0

I've updated LibNamePlateRegistry for WoW 7. While its main functionality (tracking nameplates and firing proper events on their creation and removal) is no longer required its API is still useful (especially :GetPlateByGUID(GUID) (which is now completely reliable) and :EachPlateByName() as well as its LNR_ON_TARGET_PLATE_ON_SCREEN callback).

The library is much simpler now (about 700 lines of code got removed). Several callbacks dealing with incompatibility detection with baddons have been removed since no longer required.

A new .unitToken member has been added to the plateData table provided by callbacks. This unitToken comes from the new Blizzard's NAME_PLATE_* events and as you know can be used as a standard unitID with WoW's API.

Last edited by Archarodim; 07-25-2016 at 06:43 AM.
Archarodim is offline   Reply With Quote
Reply

Tags
libnameplateregistry-1.0, nameplate, nameplates


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 04:48 AM.