LibResInfo - resurrection info without comms

Phanx · 08-22-12, 05:57 AM

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.

Talyrius · 08-22-12, 06:47 AM

(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.

myrroddin · 08-22-12, 07:24 AM

Originally Posted by Talyrius

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.

Phanx · 08-22-12, 01:48 PM

Originally Posted by myrroddin

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.

Phanx · 08-22-12, 06:15 PM

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.

myrroddin · 08-22-12, 06:28 PM

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?

Phanx · 08-22-12, 08:05 PM

Originally Posted by myrroddin

... I'm wondering about spells. You have Raise Ally and Soulstone; what about Revive?

Code:

local resSpells = {
	2008,   -- Ancestral Spirit (shaman)
	61999,  -- Raise Ally (death knight)
	20484,  -- Rebirth (druid)
	7238,   -- Redemption (paladin)
	2006,   -- Resurrection (priest)
	115178, -- Resuscitate (monk)
	50769,  -- Revive (druid)
	982,    -- Revive Pet (hunter)
	20707,  -- Soulstone (warlock)
}

As far as I know, that's every res spell that (a) has a cast time, and (b) is cast by one player on another.

I do plan to add support for Soulstone (the traditional kind that's cast on you before you die) and Reincarnation, similar to LibResComm_CanRes, but I want to get the basic stuff ironed out first.

**Seerah** · 08-22-12, 08:25 PM

Both kinds of jumper cables and mass rez?

Phanx · 08-22-12, 10:12 PM

Are jumper cables still a thing?

I added both of them just now, but I haven't actually seen a jumper cable since the Level 60 days, so it's definitely untested. If you happen to have a jumper cable or know someone who does, testing and reporting back with the results would be great.

**Seerah** · 08-22-12, 10:25 PM

I've seen them used in LFD on lower dungeons.

myrroddin · 08-23-12, 12:52 AM

I've seen the Gnomish Army Knife and Jumper Cables (both kinds) in both random dungeons and guild runs, as far as level 80+ in patch 4.1, where I quit at the time. I think they are novelty items, but people still use them, especially players whose class is not a healer. Many Rogues and Hunters were firing those off whenever they could.

For LibResComm, because it uses a comm system, and the Engineering devices have a fail chance, I never added them, even when asked. I support them manually in SmartRes2 under "non CTRA casts." For your lib, however, I would put them in, but that's me.

Phanx · 08-23-12, 01:58 AM

Well, failures are easy enough to detect, though I'll have to find someone to test so I can get the exact sequence of events and combat log data to handle them properly. Added the Gnomish Army Knife spell also.

Ketho · 08-23-12, 02:40 AM

No midgets (and/or pandas) have been harmed in the making of this library?

Phanx · 08-23-12, 02:50 AM

Sorry, I forgot about the obligatory midget slaying. I'll get right on that.

myrroddin · 08-23-12, 06:50 AM

The first word on the page http://wow.curseforge.com/addons/lib...api/callbacks/ just might confuse people.

Looking very good thus far.

myrroddin · 08-23-12, 06:56 AM

Oh, I forgot. Due to testing, Defibrillate has multiple translations, each different depending on game locale. I found this out the hard way that you need the spell ID for all three versions.

Lua Code:

[(GetSpellInfo(8342))] = true, --Defibrillate (Goblin Jumper Cables)
[(GetSpellInfo(22999))] = true, -- Defibrillate (Goblin Jumper Cables XL)
[(GetSpellInfo(54732))] = true -- Defibillate (Gnomish Army Knife)

Phanx · 08-23-12, 05:29 PM

All of those are already included. See the first post for a link to the SVN browser where you can get the current version.

myrroddin · 08-23-12, 09:44 PM

I checked out the repo, since the code paste is gone. I haven't tried forking SmartRes2 to use LibResInfo yet, but I might, time permitting. I am sure you know about this, but just in case. Line 400 reads

Lua Code:

function f:UNIT_SPELLCAST_STOPevent, (unit, spellName, _, _, spellID)

Shouldn't that read this instead?

Lua Code:

function f:UNIT_SPELLCAST_STOP(event, unit, spellName, _, _, spellID)

Phanx · 08-23-12, 11:20 PM

Parenthesis, you are drunk.

myrroddin · 08-24-12, 06:30 AM

I have never used WowI's repo system; therefore I don't know if this is by design, so I thought to point this out. When checking out the repo, it wanted to default the name of the folder to LibResInfo-976, which means nobody can pull the lib from, say, the pkgmeta on Curseforge or WowAce. We'd have to check out LRI, rename the folder, and hard embed.

In other words, because the folder is named something other than the toc file, it won't load as is. Can this be changed, or do we have to wait for you to commit to http://wow.curseforge.com/addons/libresinfo/ ?

EDIT: will checking out svn://svn.wowinterface.com/LibResInfo-976/trunk/ work?

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode