Thread Tools Display Modes
12-12-13, 12:15 PM   #101
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
For other developers: Phanx and I are testing this latest build. I just sent her a PM with a few breaking bugs, but they are typos-of-death, rather than OMG end of the world stuff.

All in all, the new LRI works and looks good.

Just in case someone wanted to give this a whirl, or are currently using it.
  Reply With Quote
12-12-13, 07:06 PM   #102
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
I'm not really sure why you sent your bug report via PM, though... I'm going to start replying with my standard "no private support or tutoring" form letter.

ಠ_ಠ
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
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
12-14-13, 03:06 AM   #104
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
No target info means you're getting a callback about Mass Res, not a normal res.

I can get on the PTR, but that won't help much without a level 25 guild.
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
12-14-13, 03:41 AM   #105
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
I will try to retest to verify the line errors are correct, but so far the error refers to the caster, not the target. Unless either BugSack/Blizzard means "line 494 failed and is blaming 495"...

Either way, I should code on the safe side and pull the Mass Res chat code out of ResCastStarted and put it into MassResStarted. After all, ResCastStarted should always have a target, yes? Within the combat log limitations we know about, that is, which you have noted on LRI's page.
  Reply With Quote
12-14-13, 03:54 AM   #106
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
Wait, stop the presses! I suddenly had a flash of inspiration, and hopefully I am correct. The issue is indeed arguments to the callbacks, but the root cause is that code in SR2 which uses MassResStarted also points to ResCastStarted. Silly me, I missed it that the arguments are different.

That would only work if the first two arguments in ResCastStarted were casterID, casterGUID. Then they would match up with MassResStarted. Naturally, they are not.

I'll do some recoding to seperate the two, but it is late. You won't hear back until tomorrow at the earliest.

.... grumble, grumble, obvious oversight on my behalf, grumble, grumble...
  Reply With Quote
12-14-13, 06:44 AM   #107
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
You don't need to make a whole new function, just check the callback and shift the args as needed:
Code:
function DoSomethingWhenResStarted(callback, targetUnit, targetGUID, casterUnit, casterGUID, endTime)
     local isMass = callback == "LibResInfo_MassResStarted"
     if isMass then
          targetUnit, targetGUID, casterUnit, casterGUID, endTime = nil, nil, targetUnit, targetGUID, casterUnit
     end
     -- do stuff
It would probably make more sense for LRI to change the order of args to better facilitate a single handler function, but that would break backwards compatibility; currently, addons that don't add the new Mass Res callbacks should continue to work as-is.

Edit:
The MassResStarted callback was missing the endTime variable; that's been fixed in r67.
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.

Last edited by Phanx : 12-20-13 at 10:05 PM.
  Reply With Quote
12-17-13, 08:28 AM   #108
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
I'm using r67 –– thank you for the update. I know you still aren't on live servers right now, and being on the PTR requires a level 25 guild to test properly, so I thought to let you know that I am getting no BugSack errors thankfully. That said, when someone casts Mass Resurrection, no bars get displayed. I have not be (un)lucky enough to cast the spell myself.

I have added a debug print to see what is going on, and will provide the results as soon as I can. In the meantime, here is the related code, with cruft removed, in the order it appears in the addon. The debug print is ResCastStarted.
Code:
function SmartRes2:OnEnable()
	self:RegisterEvent("PLAYER_REGEN_DISABLED")
	self:RegisterEvent("PLAYER_REGEN_ENABLED")

	ResInfo.RegisterCallback(self, "LibResInfo_ResCastStarted")
	ResInfo.RegisterCallback(self, "LibResInfo_ResCastFinished", "DeleteBar")
	ResInfo.RegisterCallback(self, "LibResInfo_ResCastCancelled", "DeleteBar")

	ResInfo.RegisterCallback(self, "LibResInfo_MassResStarted", "LibResInfo_ResCastStarted")
	ResInfo.RegisterCallback(self, "LibResInfo_MassResFinished", "DeleteBar")
	ResInfo.RegisterCallback(self, "LibResInfo_MassResCancelled", "DeleteBar")

	ResInfo.RegisterCallback(self, "LibResInfo_ResPending", "ResTimeOutStarted")
	ResInfo.RegisterCallback(self, "LibResInfo_ResUsed", "ResTimeOutEnded")
	ResInfo.RegisterCallback(self, "LibResInfo_ResExpired", "ResTimeOutEnded")
end

function SmartRes2:LibResInfo_ResCastStarted(callback, targetID, targetGUID, casterID, casterGUID, endTime)
	-- map Mass Res callback
	local isMassRes = callback == "LibResComm_MassResStarted"
	if isMassRes then
		targetID, targetGUID, casterID, casterGUID, endTime = nil, nil, casterID, casterGUID, endTime
	end
	self:Debug(callback, targetID, UnitName(targetID), casterID, UnitName(casterID), "isMassRes", isMassRes)

	local _, hasTarget, _, isFirst = ResInfo:UnitIsCastingRes(casterID)
	local targetName, targetRealm = UnitName(targetID)
	local casterName, casterRealm = UnitName(casterID)
	local hasIncomingRes, _, origResser = ResInfo:UnitHasIncomingRes(targetID)
	 if origResser then origResser = UnitName(origResser) end

	-- self:Debug("single?", not not hasTarget, "first?", isFirst)

	if self.db.profile.visibleResBars then
		self:CreateResBar(casterID, endTime, targetID, isFirst, hasIncomingRes, not hasTarget)
	end
end

-- Important Note: Since the release of patch 3.2, certain fights in the game fire the
-- "PLAYER_REGEN_DISABLED" event continuously during combat causing any subsequent events
-- we might trigger as a result to also fire continuously. It is recommended therefore to
-- use a checking variable that is set to 'on/1/etc' when entering combat and back to
-- 'off/0/etc' only when exiting combat and then use this as the final determinant on
-- whether or not to action a subsequent event.
function SmartRes2:PLAYER_REGEN_DISABLED()
	-- don't confuse the variable below with being in combat - we use it to see if we've run
	-- the code below on entry into combat already so that we only run it once
	if not in_combat then
		-- disable callbacks during battle if we don't want to see battle resses
		if not self.db.profile.showBattleRes then
			ResInfo.UnregisterAllCallbacks(self)
		end
	end
	in_combat = true
end

function SmartRes2:PLAYER_REGEN_ENABLED()
	-- re-enable callbacks during battle if we don't want to see battle resses
	if not self.db.profile.showBattleRes then
		ResInfo.RegisterCallback(self, "LibResInfo_ResCastStarted")
		ResInfo.RegisterCallback(self, "LibResInfo_ResCastFinished", "DeleteBar")
		ResInfo.RegisterCallback(self, "LibResInfo_ResCastCancelled", "DeleteBar")
		ResInfo.RegisterCallback(self, "LibResInfo_MassResStarted", "LibResInfo_ResCastStarted")
		ResInfo.RegisterCallback(self, "LibResInfo_MassResFinished", "DeleteBar")
		ResInfo.RegisterCallback(self, "LibResInfo_MassResCancelled", "DeleteBar")
		ResInfo.RegisterCallback(self, "LibResInfo_ResPending", "ResTimeOutStarted")
		ResInfo.RegisterCallback(self, "LibResInfo_ResUsed", "ResTimeOutEnded")
		ResInfo.RegisterCallback(self, "LibResInfo_ResExpired", "ResTimeOutEnded")
	end
	in_combat = nil
end
  Reply With Quote
12-17-13, 08:41 AM   #109
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
I'll look at that in more detail tomorrow, but what debug messages are you seeing from LRI when someone casts Mass Res?
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
12-17-13, 08:48 AM   #110
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
I actually had LRI's debgging off during the raid. I will gladly enable it during a LFR, but not a guild run. Depending on when I wake up this evening, if I have time, I will run a PUG raid and get back to you. What debugging level would you prefer? /lri 3 ?

Oh, yes. I just added the debug print a few minutes ago, which is why I have nothing to report regarding it right now.
  Reply With Quote
12-17-13, 09:42 PM   #111
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
3 should be good.

Also, I can get on a trial account on live servers, you can invite me to a group, I can let some mobs kill me, and you can cast Mass Res on me. Let me know what time works for you, and which server I should get on; trial accounts can't use Battle.net AFAIK.
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
12-18-13, 08:03 AM   #112
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
I am on sometimes between 6-9:00 am PST Mon-Thurs, but more often 5-8:30 PM those same days. On weekends I stay on longer, and log in earlier because I don't have to work.

Starting next Monday, I will be away on holidays for a week, with almost zero internet access, at the very least, limited access. No gaming at all during that time.

I play on Llane-US, Alliance. If you see Myrroddin, Vanhoeffen, Jelia, or Badash, that will be me.
  Reply With Quote
12-19-13, 05:05 AM   #113
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
I've created a level 1 human on Llane, with the glorious random name of Sanesea. Trial accounts can't send whispers to anyone who didn't whisper them first, so you'll have to whisper me, or ping me on Skype if I'm not online (likely).
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
12-20-13, 09:17 PM   #114
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
The new version is complete. I've posted a "release" version to the download page, and updated the API docs on CurseForge. The following changes have been made; all should be backwards-compatible:

1. The callbacks for ResCastStarted/Cancelled/Finished no longer include Mass Resurrection.

2. There are now separate MassResStarted/Cancelled/Finished callbacks for Mass Resurrection. These callbacks will fire once for each cast, rather than once for each potential target. They do not include any target information. When they are received, if you need to know who they will affect, you can scan all group members for incoming resurrections using the LibResInfo:UnitHasIncomingResurrection API, which now returns "MASSRES" instead of "CASTING" for Mass Resurrection casts.

3. Pre-cast Soulstones are now supported. LibResInfo:UnitHasIncomingResurrection will return "SELFRES" instead of "PENDING" for units who can resurrect from a pre-cast Soulstone, and the ResPending callback will fire with an additional argument (boolean true) if the pending resurrection is from a pre-cast Soulstone.

4. The LibResInfo.RegisterAllCallbacks API now accepts a third argument (boolean true). If this argument is not set, then the API will not register for the new Mass Resurrection callbacks. This change was made to maintain compatibility with previous library versions, since the Mass Res callbacks do not pass the same arguments as the normal res callbacks (specifically, they do not pass target information as arg1 and arg2).

Looking for comments on the following:

5. Should I add callbacks to notify addons when a unit dies or resurrects (eg. by corpse running) during a Mass Res cast? Currently, unit frame addons that display each unit's res status must implement their own code to detect when a unit dies or resurrects and update their res status. LRI already detects these events internally, so it would be trivial to add callbacks for them.

6. Should I change the new Mass Res callbacks to pass 2x nil as arg2 and arg3 (where targetID and targetGUID are passed in other callbacks) so they can be more easily handled by the same function?
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
12-20-13, 10:04 PM   #115
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Okay, I've gone ahead and implemented #5, and will commit a new version pending testing. Here's how it will work:

When a unit dies, goes offline, or resurrects while Mass Res is casting, a "LibResInfo_UnitUpdate" callback will be fired. This new callback will not fire for units who (a) resurrected with a res already available, since in that case you will get a ResExpired callback instead; or (b) died or went offline with another single-target res being cast on them, since in that case you will get a ResCancelled callback instead. When using RegisterAllCallbacks, the UnitUpdate callback will only be registered if the includeMassRes arg is set. The arguments will be as follows:
  • targetID - string: the unitID of the unit who died, went offline, or resurrected
  • targetGUID - string: the GUID of the unit who died, went offline, or resurrected
When it fires, you will be able to call LibResInfo:UnitHasIncomingRes to get more details.
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
12-20-13, 11:24 PM   #116
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
I will update in a bit. Going for late breakfast. Anyway, I found something else with UnitHasIncomingRes, but haven't determined where the source issue lies. I did further testing with a friend, and found if you resurrected someone, but they did not accept (one minute timer running), and you cast again, you could indeed cast again instead of exiting out with a "PENDING" message. We made sure it was during the time stretch where the casualty did not suffer from res delay.

As I said, I haven't determined if the unintended behaviour is coming from LRI or SR2, but thought to give you a head's up.

Edit: wouldn't #6 above cause breaking code, forcing LRI-2.0?

Last edited by myrroddin : 12-20-13 at 11:26 PM. Reason: Answering questions above.
  Reply With Quote
12-21-13, 01:14 AM   #117
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Originally Posted by myrroddin View Post
I did further testing with a friend, and found if you resurrected someone, but they did not accept (one minute timer running), and you cast again, you could indeed cast again instead of exiting out with a "PENDING" message. We made sure it was during the time stretch where the casualty did not suffer from res delay.
What is LRI:UnitHasIncomingRes returning during this time?

Originally Posted by myrroddin View Post
Edit: wouldn't #6 above cause breaking code, forcing LRI-2.0?
Theoretically, yes, but the implementation is brand new. I can easily update oUF_Phanx again, I haven't pushed a relaese for Grid or PerfectRaid_ResInfo yet, you haven't pushed a release for SmartRes2 yet (unless you did it today), sRaidFrames hasn't been updated since March, and I don't know of any other addons using the lib.
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
02-22-14, 05:54 AM   #118
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
In the latest alpha of SmartRes, I have some experimental code to force casting on different units in LFR. For some odd reason, the smart code picks player a, then player b, then player c perfectly fine in flex and normal raiding, but LFR it was recasting on player a until he/she accepted the cast.

The experimental code is definitely a hack job, since it largely duplicates existing code with only minor changes. The good news is it seems to work, having just done five LFR tonight. The bad news is it causes bars to not fade once complete. And it also seems to break unrelated code that works fine, frozen bar or not.

If you want to talk more about this, please let me know. I can link to code and error reports if you wish.

LRI logging isn't giving me much, but I may not be using it correctly, or to best effect.
  Reply With Quote
02-22-14, 12:18 PM   #119
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Sure, send me a PM or message me on Skype. It doesn't really sound like an LRI bug, but to confirm, what does:

Code:
/dump LibStub("LibResInfo-1.0"):UnitHasIncomingRes("target")
...show while targeting the "stuck" player?
__________________
Retired author of too many addons.
Message me if you're interested in taking over one of my addons.
Don’t message me about addon bugs or programming questions.
  Reply With Quote
10-14-14, 11:50 AM   #120
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
I haven't got any error reports from beta or PTR users, and I can't get onto the 6.0.2 patch for a few days. I understand that guild levels are going away, but I don't know if they are gone with this patch, or if Blizzard changed their mind, or, or, or?

SmartRes2's code is changed slightly to use different events to track if the player knows Mass Resurrection, having ditched guild membership and level checks.

There was one bug in Mists where if MR was cast (good) followed by a first collision (red), it was all good, but if during that same cast a second or further collision was detected the bar correctly went red but the chat warning thought the original caster was nil. Like it forgot who the first caster was.

I do have the error report, but the line numbers won't match currently.

Further, I believe this is NOT a LibResInfo bug; rather it is a usage bug on how I detect and process original casters and collision casters. Everything works with class based spells and engineering devices.

I will see if I can get onto the game and get BugSack to catch the error again, with the new line numbers.
  Reply With Quote

WoWInterface » AddOns, Compilations, Macros » Released AddOns » LibResInfo - resurrection info without comms

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off