• 0

    posted a message on Curse keyword substitution not applied for libraries

    Can't you put some pressure on them? This issue is quite annoying and shouldn't be that difficult to fix...

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Curse keyword substitution not applied for libraries

    Are these tickets private only? Or is there some place where we can see the progress on ongoing issues?

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Localization interface can allow or create mix line endings

    If you take the last release of HHTD, you'll notice that Localization.lua contains mixed line endings (/r/n and /n only).

     

    That doesn't seem to cause issues in WoW but that should not be possible. I never noticed that on the old system.

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Localization auto insert not always working

    I can confirm this with Decursive too (tested just now) ; for example in my latest alpha package the localisation substitution did not work file but it did in the previous alpha...

     

     

    Other issues :

    New alpha version I push on Github get packaged with the wrong file name (using the sha-1 hash instead of the last known tag). The version keywords are properly replaced though...

    I also noticed that the ZIP archives appear to be bigger than they used to.

     

    Edit: The missing localization problem appears to be a cache issue: the localization is added after and the zip is modified/replaced but if you download the ZIP before the localisation is done then some file cache gets in the way... (not necessarily on the client side)

    Posted in: WoW Sites Feedback
  • 0

    posted a message on 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.
    Posted in: Libraries
  • 0

    posted a message on 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).
    Posted in: Libraries
  • 0

    posted a message on LibNameplateRegistry-1.0
    I've made the change concerning hooks in the latest alpha.
    Posted in: Libraries
  • 0

    posted a message on Fixing the Interface Options Cancel button taint
    I agree, 1 library to fix taint issues seems the right thing to do. Even though what this library will fix will not necessarily be related to the add-ons embedding it, it will globally better the WoW environment for everyone (authors and players).
    Posted in: Lua Code Discussion
  • 0

    posted a message on Fixing the Interface Options Cancel button taint
    Well done! I gave up on this a few years ago. We did create a thread on Blizzard's bug reporting forum at the time but to no avail. I stopped adding my add-ons' settings to the interface option panel as a result...
    Posted in: Lua Code Discussion
  • 0

    posted a message on 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.


    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.
    Posted in: Libraries
  • 0

    posted a message on LibNameplateRegistry-1.0
    Quote from Adirelle

    One I found quite annoying though is the difference between the second argument of the LNR_ON_NEW_PLATE and LNR_ON_GUID_FOUND callbacks: the former passes nameplate data, the latter only the GUID. I was doing something like this :

    function addon:OnEnable()
    	--[[ ... ]]
    	self:LNR_RegisterCallback('LNR_ON_NEW_PLATE', 'NewPlate')
    	self:LNR_RegisterCallback('LNR_ON_GUID_FOUND', 'NewPlate')
    	--[[ ... ]]
    end
    
    --[[ ... ]]
    
    function addon:NewPlate(event, nameplate, data)
    	local unitFrame = data.GUID and unitFrames[data.GUID]
    	if unitFrame then
    		unitFrame:AttachToNameplate(nameplate)
    	end
    end


    So I had to add another handler.


    I made it this way mostly because the other plate associated data are not guaranteed to be accurate (except for data.name and data.GUID) when LNR_ON_GUID_FOUND fires (a plate's reaction could have changed for example since LNR_ON_NEW_PLATE fired).
    It's true that I could update data.reaction before firing but it seems like an overhead since this callback only fires when a GUID is found, it's not meant to track nameplate data changes.

    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.


    Quote from Adirelle

    What you do with LNR isn't that complex. It doesn't seems there is more than one timer for each task so you could just have a big OnUpdate handler with a front rate limiter and several tasks based on boolean tests. AceTimer-3.0 spawns (or recycles) an animation each time you call :Schedule*Timer.

    local timer = 0
    local sanityDivisor = 0
    LNR_Private.EventFrame:SetScript('OnUpdate', function(_, elapsed)
      -- Main throttle
      timer = timer - elapsed
      if timer > 0 then return end
      timer = 0.1
    
      -- Check sanity every 100th tick
      sanityDivisor = sanityDivisor  + 1
      if sanityDivisor == 100 then
        sanityDivisor = 0
        LNR_Private:CheckHookSanity()
      end
    
      -- Look for new plates
      LNR_Private:LookForNewPlates()
    
      -- Look for target plate
      if HasTarget then
        LNR_Private:CheckPlatesForTarget()
      end
    
      --[===[@debug@
      self:DebugTests()
      --@end-debug@]===]
    end)


    Hide EventFrame at creation, show it in :Enable and hide it in :Disable, et voilĂ  !

    And for the out-of-combat enabling, just register PLAYER_REGEN_ENABLED and call Enable when it fires.


    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 :(

    I'll make the switch when I have some time.

    Quote from Adirelle

    A bunch of upvalues would have worked too and the library tables were designed intended to pass important data from one instance of the library to another one.


    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...
    Posted in: Libraries
  • 0

    posted a message on LibNameplateRegistry-1.0
    Quote from Adirelle
    Ok, so, the API does what LibNamePlate-1.0 did, I just had to replace some names there and there. It seems to work a first glance, I have to test it further.


    nice :) what is your add-on by the way?

    Quote from Adirelle
    By the way, isn't there any way to get rid of the dependency to AceTimer-3.0 ? Most of the timers could be handled by a simple OnUpdate handler (eventually of a animation to control the execution rate) and one of them could just be done using an event handler.
    Quote from Torhal
    This is definitely something you should do; rarely is it a good thing to have one lib rely on another.


    I know, I hesitated seeing that no other library was doing this but I was too lazy to reinvent the wheel once more and make the library more complex and bug prone.
    AceTimer being a very common and simple library, it shouldn't be a problem anyway.


    One question though about the internals: why bother with all that private stuff ? It just seems to make things more complicated than they should.
    I think it's cleaner that way and it also limits the amount of strange bugs that could be caused by a bugged add-on that would find its way into the library and damage it. (I've seen this happen a few times and lost hours to find the cause)
    It's not that complicated once you get used to it, it makes the design clearer. At least for me.
    Posted in: Libraries
  • 0

    posted a message on LibNameplateRegistry-1.0
    great :) Tell me you need some API I haven't implemented.
    Posted in: Libraries
  • 0

    posted a message on LibNameplateRegistry-1.0
    I've implemented the API: GetPlateRegion(plateFrame, internalRegionNormalizedName)

    addon:GetPlateRegion(plateFrame, internalRegionNormalizedName)

    [FONT=helvetica](WIP current alpha only) Gets a platename's frame specific region using a normalized name.[/FONT]
    [FONT=helvetica]Use this API to get an easy and direct access to a specific sub-frame of any nameplate. This is useful if you want to access data for which LibNameplateRegistry provides no API (yet).[/FONT]
    [FONT=helvetica]The result is cached for each frame making subsequent identical calls very fast.[/FONT]
    [FONT=helvetica]The following regions are supported: 'name', 'statusBar', 'highlight', 'level', 'raidIcon', 'eliteIcon'.

    If you need to access a specific region which is not supported, please make a feature request using the ticket system.[/FONT]

    Parameters

    plateFramethe platename's root frameinternalRegionNormalizedNamea normalized name referring to a specific region

    Return value


    [FONT=helvetica]region or throws an error if asked an unsupported region's name.[/FONT]
    Posted in: Libraries
  • 0

    posted a message on Embedding BugGrabber ?
    Quote from Adirelle
    Why did you embed BugGrabber if you also had to implement your own error handler ?


    I implemented my error handler before BG could be embedded, it's actually because I asked that BG became embeddable, I thought it was better to have a shared library doing this than having every add-on doing it differently.

    Moreover BG's sanitized output is very useful. There was also a problem with locals output where it was very difficult to get the stack level right if several add-ons registered an error handler.

    So in the end a shared library was the only proper way of doing it reliably but only a small part of what I wanted was actually done: http://www.wowace.com/addons/bug-grabber/tickets/21-make-bug-grabber-a-library/

    Anyway, runtime error handling is very difficult to implement well, I think that BG should remain simple and just take care of forwarding the error if no registered add-on wants to take the blame. Each add-on needs to determine on its own if it's the cause of an error or not...
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.