Thread Tools Display Modes
08-22-12, 05:57 AM   #1
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
LibResInfo - resurrection info without comms

LibResInfo-1.0 detects resurrection spells being cast by group members and identifies who they are being cast on, and provides that information to addons through callbacks and API functions.

LibResInfo-1.0 was written to replace LibResComm-1.0, and works locally without the need for addon communication, so it is not necessary for anyone else in your group to have it installed. It is completely locale-independent.

Download:
SVN URL is usable for direct checkouts, in svn:externals properties, and in CurseForge .pkgmeta files.

Please direct all bug reports, suggestions, questions, and comments to the forum thread:

http://www.wowinterface.com/forums/s...ad.php?t=43933

Please do not use the comments section on the download page! File comments aren't searchable, can't be linked individually, and don't support threading.

Curent Status

This library should be considered an early beta release. It should be safe to start converting addons, but you should probably not publish "stable release" versions of addons using this library yet.

WoW 5.x only. No backwards compatibility with WoW 4.x is planned, as 5.x is going live in less than a week, and nobody will be developing addons for 4.x anyway.

No Mass Resurrection support yet. I'll be working on that this week.

No self-resurrect support yet. Support for pre-cast Soulstone is planned. Support for Reincarnation is under consideration, but requires some guesswork, since until you actually see a shaman resurrect themselves, there's no way to tell if the ability is on cooldown or not.

Callback API documentation:

http://wow.curseforge.com/addons/lib...api/callbacks/

Function API documentation:

http://wow.curseforge.com/addons/lib...api/functions/

Other notes

It is not possible to definitively detect when someone who joins the group is already casting a resurrection spell on someone who is already in the group, or someone who joins the group already has a resurrection spell being cast on them by someone who is already in the group. I think this is a pretty uncommon edge case, so for now it's not supported.

It is not possible to detect when someone who joins the group while dead already has a resurrection available to them.

It is not possible to detect when someone declines a resurrection manually.
__________________
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 : 08-27-12 at 07:07 PM.
  Reply With Quote
08-22-12, 06:47 AM   #2
Talyrius
An Onyxian Warder
 
Talyrius's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 363
(4) Does anyone care about knowing who cast the res spell after it's finished casting? (eg. before the target accepts it)
I can't think of any benefit to having this information, but I'm sure people will want it in spite of that.
  Reply With Quote
08-22-12, 07:24 AM   #3
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
Originally Posted by Talyrius View Post
I can't think of any benefit to having this information, but I'm sure people will want it in spite of that.
Even in SmartRes2, I don't care about whom the caster was when the spell cast is finished; I only care that the target has been cast upon and has or has not accepted. There is no point in SR2 to use the smart target to cast on someone already ressed but afk and not accepting. In short, the resser is not important, only the target at that point.

I'm keeping an eye on this, because if it proves a better solution, I can switch.

The only suggestion I would make is to have some form of IsUnitBeingRessed(unit) returning Boolean and caster. UnitHasIncomingResurrection() only has the Boolean. LibResComm has this API, and while I do not make use of it, I could see the value.
  Reply With Quote
08-22-12, 01:48 PM   #4
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Originally Posted by myrroddin View Post
The only suggestion I would make is to have some form of IsUnitBeingRessed(unit) returning Boolean and caster. UnitHasIncomingResurrection() only has the Boolean. LibResComm has this API, and while I do not make use of it, I could see the value.
Once I'm sure all the logic is working properly, and I've cleaned up the code to a state I consider acceptable for an actual release, then I'll add some API functions. I'll update the first post with the proposed callbacks and functions.

Also, the current idea is that all callbacks and API functions will pass/return GUIDs only, not unit IDs or names, but I'm very open to comments on what you'd like to see. I don't want to get too far into RosterLib territory, though I'm already keeping a map of GUID => unit ID, so I could pass that info.
__________________
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 : 08-22-12 at 02:07 PM.
  Reply With Quote
08-22-12, 06:15 PM   #5
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Changed my mind. Everything will return both the unitID and the GUID. Yes, it's trivially easy for addons to get the GUID from the unitID if they want it, but since the lib already has the GUID (everything is tracked by GUID internally) why not save a function call?

API functions will accept either a unitID or a GUID.

Working on LibStub-ifying it at the moment. Will fix the bugs with people leaving the group after that, and then work on refactoring the messy/redundant parts, and then add the callbacks and API.
__________________
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
08-22-12, 06:28 PM   #6
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
It is early days yet for the code, but I'm wondering about spells. You have Raise Ally and Soulstone; what about Revive? In LibResComm I didn't put in Soulstone, Reincarnation, and the related cooldown spells because they have no cast times and share cooldowns. Or at least they did. Revive, on the other hand, does have a cast time.

Anyway, your thoughts, Phanx?
  Reply With Quote
11-04-12, 05:46 PM   #7
Magicalhats27
A Fallenroot Satyr
 
Magicalhats27's Avatar
Join Date: Nov 2012
Posts: 24
Worth it

Originally Posted by Phanx View Post
[b]communication, so it is not necessary for anyone else in your group to have it installed.
Thats great. Actually this fact alone makes it worth the download. Lots of time saved - Thanks
  Reply With Quote
01-14-13, 05:59 AM   #8
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
I'm finally at a point in the game where the daily quest grind is slowing down, and that means back to addon development. Phanx, do you prefer the pkgmeta from Curseforge/WoWAce to pull from the WoWInterface or Curseforge repository for this lib? I'm leaning to CF so you get author reward points, but wanted to check first.

On a side note, expect the WoWace forums' developer thread to get hit with questions, but not necessarily about LibResInfo
  Reply With Quote
01-14-13, 07:44 PM   #9
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Originally Posted by myrroddin View Post
Phanx, do you prefer the pkgmeta from Curseforge/WoWAce to pull from the WoWInterface or Curseforge repository for this lib? I'm leaning to CF so you get author reward points, but wanted to check first.
There is no CurseForge repository. Files on CurseForge are manually uploaded. Your .pkgmeta will need to specify the WoWI repository URL. If you want me to get points, specify "libresinfo" (the CurseForge project name) in the "tools-used" section of your .pkgmeta, just like you do for LibDataBroker, but for reasons that actually make sense.
__________________
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
01-15-13, 01:54 AM   #10
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
Originally Posted by Phanx View Post
just like you do for LibDataBroker, but for reasons that actually make sense.
For those wondering, LibDataBroker-1.1 does not have a .toc file, and thus is not a standalone library. And I agree, that decision was bizarre.

On topic, thank you Phanx.
  Reply With Quote
02-15-13, 10:39 PM   #11
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
[BUG] Redemption spellID has typo

I was testing things, and lo and behold, line 108 in LibResInfo has a typo: instead of the spellID for Redemption, the spellID for Frost Protection is used instead.

Change 7238 to 7328 and fixed.
  Reply With Quote
04-11-13, 02:45 PM   #12
Gronzig
A Murloc Raider
AddOn Author - Click to view addons
Join Date: Dec 2009
Posts: 7
I am getting an error in r43, line 307, from comparing a number to nil. I believe this line should be changed from
if resCasting[target] > 1 then
to
if resCasting[target] and resCasting[target] > 1 then
Also, it looks like line 319 should be changed from
resCasting[guid] > 0 then
to
if resCasting[guid] and resCasting[guid] > 1 then
  Reply With Quote
04-12-13, 07:54 PM   #13
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
That's really just a band-aid, but I'm probably going to go with it, because I just don't have time to go through the extensive in-raid testing required to figure out what the actual problem is. There's still going to be the same outdated, mismatching data in the cache. I'm pretty sure it's related to the current implementation of Mass Res support, and I'll probably just end up removing Mass Res support from the existing callbacks, and just fire a single callback for each Mass Res cast, instead of trying to keep track of which players are affected by every 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
05-27-13, 08:08 PM   #14
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
[5.3] compare number with nil

I am getting the following whenever people cast Mass Resurrection. I know you wanted to possibly rewrite the MR callback, and hopefully this helps.
Lua Code:
  1. 26x Libs\LibResInfo-1.0\LibResInfo-1.0-11.lua:222: attempt to compare nil with number
  2. Libs\LibResInfo-1.0\LibResInfo-1.0-11.lua:222: in function "UnitIsCastingRes"
  3. SmartRes2\SmartRes2-Release 2.5.4.lua:477: in function "?"
  4. Ace3-Release-r1086\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:147: in function <Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
  5. <string>:"safecall Dispatcher[6]":4: in function <string>:"safecall Dispatcher[6]":4
  6. <in C code>
  7. <string>:"safecall Dispatcher[6]":13: in function "?"
  8. Ace3-Release-r1086\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:92: in function "Fire"
  9. Libs\LibResInfo-1.0\LibResInfo-1.0-11.lua:487: in function "?"
  10. Libs\LibResInfo-1.0\LibResInfo-1.0-11.lua:105: in function <Libs\LibResInfo-1.0\LibResInfo-1.0.lua:104>
  11.  
  12. Locals:
  13. nil
  Reply With Quote
05-27-13, 09:02 PM   #15
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
It's the same issue with Mass Res screwing up the cache because it doesn't actually fire events. I've been slowly writing a new version from scratch that handles caching better, and doesn't attempt to fire individual callbacks for all units that might be affected by Mass Res, but it's not done yet.

Anyway, I've added another bandaid for that error, so if you update your working copy you shouldn't get the error anymore.
__________________
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
06-27-13, 08:03 PM   #16
myrroddin
A Pyroguard Emberseer
 
myrroddin's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 1,240
Phanx, you have mentioned you are writing a new version, or at least modifying the existing code. If I can make a suggestion to the API, since I think the code already calculates this: expose both the current casterID and the first casterID for UnitHasIncomingRes.
Lua Code:
  1. local status, endTime, currentCasterID, currentCasterGUID, firstCasterID, firstCasterGUID = LibResInfo:UnitHasIncomingRes(unit)
  2. --[[
  3.     status is either "CASTING" or "PENDING"
  4.     endTime is the time the current caster's spell ends
  5.     currentCasterID and currentCasterGUID are the unitIDs or GUIDs for whomever is the current res caster on "unit"
  6.     firstCasterID and firstCasterGUID are the same as above, but for whomever's cast lands first
  7.     unit is "player", "target", "raid10", etc
  8. ]]--
This would make comparing isFirst's targetUnit to find out who is the first casterUnit on targetUnit much simpler.

The reason I ask is because I am running into the situation where SmartRes2's collision notification system is giving erroneous results if more than one caster is casting on the same unit, and even more erroneous results when there are more than one collision caster with more than one collision targets. Mass Resurrection's collision doesn't seem to be adversely affected.

My work in progress solution is building a table
Lua Code:
  1. local doingRessing = {}
  2. function MyAddOn:LibResInfo_ResCastStarted(targetUnit, targetGUID, casterUnit, casterGUID, endTime)
  3.     local _, _, _, isFirst = LibResInfo:UnitIsCastingRes(casterUnit)
  4.     if not doingRessing[casterUnit] then
  5.         if targetUnit then -- class spell. use isFirst for Mass Res since there is no targetUnit
  6.             doingRessing[casterUnit] = {
  7.                 targetID = targetUnit,
  8.                 isFirst = isFirst
  9.             }
  10.         end
  11.     end
  12.     -- if not isFirst and targetUnit then iterate through table to find out who IS first
  13.     -- send chat message to casterUnit with firstCasterID and targetUnit
  14. end
  15.  
  16. function MyAddOn:LibResInfo_ResCastFinished(targetUnit, targetGUID, casterUnit, casterGUID)
  17.     if doingRessing[casterUnit] then
  18.         doingRessing[casterUnit] = nil
  19.     end
  20. end
I am going on vacation for the weekend, and will not be able to apply this code and test until next week at the earliest. It is just a thought that if LRI calculates who is the first caster (target or not) in order to provide true/false for isFirst, then exposing both sides would be beneficial.
  Reply With Quote
08-02-16, 05:09 AM   #17
p3lim
A Pyroguard Emberseer
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,710
Sometimes when the target getting ressed is out of range, once the target accepts the res the icon of my element gets stuck (no callbacks or methods reporting incorrectly, most likely the former).

I've registered UNIT_HEALTH while the icon is shown in my element just in case, seems to work fine.
  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