Can't you put some pressure on them? This issue is quite annoying and shouldn't be that difficult to fix...
- Curse Premium
Member for 16 years, 11 months, and 16 days
Last active Sat, Feb, 25 2023 11:52:58
- 0 Followers
- 41 Total Posts
- 0 Thanks
Feb 26, 2017archarodim posted a message on Curse keyword substitution not applied for librariesPosted in: WoW Sites Feedback
0archarodim posted a message on Curse keyword substitution not applied for librariesPosted in: WoW Sites Feedback
Are these tickets private only? Or is there some place where we can see the progress on ongoing issues?
0archarodim posted a message on Localization interface can allow or create mix line endingsPosted in: WoW Sites Feedback
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.
0archarodim posted a message on Localization auto insert not always workingPosted in: WoW Sites Feedback
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)
0I'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).Posted in: Libraries
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.
0This 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.Posted in: Libraries
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).
0I've made the change concerning hooks in the latest alpha.Posted in: Libraries
0archarodim posted a message on Fixing the Interface Options Cancel button taintI 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
0archarodim posted a message on Fixing the Interface Options Cancel button taintWell 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
0I'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.Posted in: Libraries
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.
0Posted in: Libraries
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.
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.
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...
0Posted in: Libraries
nice :) what is your add-on by the way?
Quote from TorhalThis 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.
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)
One question though about the internals: why bother with all that private stuff ? It just seems to make things more complicated than they should.
It's not that complicated once you get used to it, it makes the design clearer. At least for me.
0great :) Tell me you need some API I haven't implemented.Posted in: Libraries
0I've implemented the API: GetPlateRegion(plateFrame, internalRegionNormalizedName)Posted in: Libraries
[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]
plateFramethe platename's root frameinternalRegionNormalizedNamea normalized name referring to a specific region
[FONT=helvetica]region or throws an error if asked an unsupported region's name.[/FONT]
0archarodim posted a message on Embedding BugGrabber ?Posted in: Lua Code Discussion
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...
- To post a comment, please login or register a new account.