Authors CurseForge

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

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

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.

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)

Actually, this is the upgrading process of the defunct AceLibrary. It has been abandoned because it was considered too complex and heavy.

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.

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.

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.

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.

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.

One question though about the internals: why bother with all that private stuff ? It just seems to make things more complicated than they should.

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]

Quote from Adirelle

Why did you embed BugGrabber if you also had to implement your own error handler ?