View Single Post
12-14-13, 02:43 AM   #103
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
I apologize Phanx. I forgot about not PMing you with error reports. Sorry!

Anyway, here are the bug reports, in the proper place. I have a (probably wrong) theory about the causes, which I will discuss after the jump. This is with the latest LibResInfo from the repository.
Code:
5x SmartRes2\SmartRes2-@[email protected]:495: Usage: UnitName("unit")
<in C code>
SmartRes2\SmartRes2-@[email protected]:495: in function "?"
libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:147: in function <libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[3]":4: in function <string>:"safecall Dispatcher[3]":4
<in C code>
<string>:"safecall Dispatcher[3]":13: in function "?"
libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:92: in function "Fire"
SmartRes2-@project-version@\Libs\LibResInfo-1.0\LibResInfo-1.0-16.lua:442: in function "?"
SmartRes2-@project-version@\Libs\LibResInfo-1.0\LibResInfo-1.0-16.lua:125: in function <SmartRes2\Libs\LibResInfo-1.0\LibResInfo-1.0.lua:124>

Locals:
nil
Code:
5x SmartRes2\SmartRes2-@[email protected]:613: Usage: UnitName("unit")
<in C code>
SmartRes2\SmartRes2-@[email protected]:613: in function "?"
libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:147: in function <libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[3]":4: in function <string>:"safecall Dispatcher[3]":4
<in C code>
<string>:"safecall Dispatcher[3]":13: in function "?"
libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:92: in function "Fire"
SmartRes2-@project-version@\Libs\LibResInfo-1.0\LibResInfo-1.0-16.lua:462: in function "?"
SmartRes2-@project-version@\Libs\LibResInfo-1.0\LibResInfo-1.0-16.lua:125: in function <SmartRes2\Libs\LibResInfo-1.0\LibResInfo-1.0.lua:124>

Locals:
nil
My theory: initially I thought it was because Blizzard changed GetGuildRosterInfo first return from simply name to name-realm, but LRI doesn't use GGRI.

Then I thought maybe LRI's arguments were rearranged, but that isn't the case.

But then I saw these, and wonder if I'm missing something, or whether there was always a nil in the callbacks. And if there was, why is it in different places?
Code:
-- line 330 (not firing casterID?)
callbacks:Fire("LibResInfo_ResCastCancelled", unitFromGUID[target], target, nil, caster)

-- line 350 (not firing targetID?)
callbacks:Fire("LibResInfo_ResCastCancelled", nil, target, unitFromGUID[caster], caster)

-- line 359 (not firing targetID?)
callbacks:Fire("LibResInfo_ResExpired", nil, target)
The gaping problem with my theory is that none of the nil entries are in ResCastStarted. So they explain the second error, but not the first.

If you want me to pop onto the PTR, assuming it is active, let me know.
  Reply With Quote