RCLootCouncil - wowaudit

It's always great when I see people creating new modules to RCLootCouncil, so kudos on that :)

There's however two issues that bugs me.

Unnecessary update call

RCLootCouncil_wowaudit/Modules/lootFrame.lua

Line 23 in 9978ba6

frame:Update()

You don't need to call the update function when creating the hook - in fact it does nothing without providing an item, which took some digging to figure out why that was happening. It's a minor inconvenience that I thought I might as well mention.
Comms prefixes
I recently had reports of comms being delayed, and I've tracked it down to your module. Addon comms are throttled to 1 message (255 bytes) per second, per prefix, with up to 10 messages being "pooled". https://warcraft.wiki.gg/wiki/API_C_ChatInfo.SendAddonMessage#Message%20throttling.
I've carefully optimized all comms on the RCLootCouncil.PREFIXES.MAIN prefix to work reasonable well within this limit - and adding your comms on top of that is not optimal. Luckily the solution is as simple as using your own prefix, which is really easy with the way I setup comms, for example the shorthand way:

local Comms = RCLootCouncil.Require "Services.Comms"
Comms:Send {
  prefix = "YOUR_PREFIX",
  target = "group",
  command = "wishlist_data",
  data = {...data}
}
Comms:Subscribe("YOUR_PREFIX", "wishlist_data", receiverFunc)

Alternatively you can store your own "sender" function for a more permanent solution, for example in Modules/shareData.lua:

function wowauditShareData:OnInitialize()
  RCwowaudit.Send = Comms:GetSender "YOUR_PREFIX" -- This also automatically registers the prefix

  self:RegisterMessage("RCMLAddItem", "OnMessageReceived")
  -- Using `BulkSubscribe` for zzz
  Comms:BulkSubscribe("YOUR_PREFIX", {
	wishlist_data = function(data, sender)
		self:OnWishlistDataReceived(unpack(data))
	end,
	request_wishlist_data = function(data, sender)
		self:OnWishlistDataRequested(unpack(data))
	end
  })
end

Then you just switch out addon:Send() with RCwowaudit:Send().

The only caveat is this is not backwards compatible.

Thanks a lot for the feedback and detailed solution!

I tried getting rid of the update call, but without it the information set in HookEntryUpdate is not displayed, so it looks like it is in fact doing something (perhaps in an unintended way?). I took inspiration from a similar implementation in an old EPGP module, they did the same thing there: https://github.com/SafeteeWoW/RCLootCouncil_EPGP/blob/731f04b82e1f5da5da402f6bbdc3d7b637b3d69a/Modules/LootFrame.lua#L26C2-L26C18
I implemented your suggestion here: #3. I assume there's an underlying limit imposed by the game that even prefixes won't solve? Otherwise the solution would be to use a different prefix for each message type?

Just tested it in game, and you're semi correct. You're creating a post hook, i.e. your code is running after RCLootFrame.EntryManager:GetEntry() finishes executing. The issue is at that point Entry:Update() has already been called, and won't be called again until new items are added, user clicks a button, or the frame is reused, i.e. your function isn't called. Calling Entry:Update() will call your function, with the side effect of calling the original function without item.
The solution is to just call your function at hook time, e.g.:

function wowauditLootFrame:HookGetEntry(_, item)
    if not hookRunning then
        hookRunning = true
        local frame = RCLootFrame.EntryManager:GetEntry(item)
        if not self:IsHooked(frame, "Update") then
            self:SecureHook(frame, "Update", "HookEntryUpdate")
            self:HookEntryUpdate(frame)
        end
    end
    hookRunning = false
end

That way you get your data in at the original call where the hook isn't registered yet, and the hook will take care of any future calls.

The other important limit is bandwidth, which ChatThrottleLib sets at 800 bytes/s shared by all addons using it. Creating a prefix for each message is a "valid" solution (MRT rotates like 5 prefixes) - I just really doubt Blizzard likes that if everyone starts doing it. I happened to create 3 prefixes for administrative purposes before they implemented the message/prefix limit, mostly to ensure a) version checks don't interfere with normal comms and b) setting lower priority on sync stuff. I'll send you an addon that can help you investigate addon comms.

You may want to reconsider your prefix - "wowauditMain" is 12 bytes which is added to each message, eating into the 255 byte limit per message. I imagine wishlist data can grow to encompass multiple messages, so 12 bytes each message can add up. That's the reason why I use "RCLCx", as it's the shortest unique and identifiable string I could come up with.

Share to