LibResInfo - resurrection info without comms

[Phanx]

I'm not sure I understand the problem.

If you're checking out a local copy via SVN, it is 100% default SVN functionality that the checkout path uses the repository name (at least with TortoiseSVN; not sure about other clients). Checking out from WowAce may appear different because WowAce uses the project "slug" as the repository name (eg. "smartres2") instead of something with a numeric ID, but it's not actually different. You can change the path during checkout, or rename the folder afterward. Anyone doing SVN checkouts on a library in alpha development is probably savvy enough to figure out how to rename a folder.

(On a side note, if you're on a case-sensitive filesystem, a default checkout from WowAce using TortoiseSVN will be just as broken as a default checkout from WoWI, because the folder name "smartres2" won't match the TOC name "SmartRes2.toc".)

Also, the SVN repo for LRI has the svn:externals property set correctly, so it will include LibStub and CallbackHandler-1.0 in the checkout.

If you're embedding it in your CurseForge/WowAce addon via .pkgmeta, do the same:

externals:
    Libs/LibResInfo-1.0: svn://svn.wowinterface.com/LibResInfo-976/trunk

The only possible issue I can think of is that people downloading the -nolib package of your alpha version through the Curse Client won't get the library, but I don't really consider this a problem, since the library is not ready for release and should not be used in a release addon yet. Once it is ready for release, it will also be posted on CurseForge so the Curse Client will be able to get it.

[Phanx]

Fixed handling of res expirations.

Fixed handling of res invalidations by ghosting or disconnecting.

Fixed handling of players who leave the group while casting a res, having a res cast on them, or having a res available.

Fixed things so API functions return correct values immediately when callbacks fire.

Will post an official beta release on WoWI and CurseForge as soon as Dolby fixes this bug so I can push a release. In the meantime, /trunk or /tags/r12-beta will get you the current "stable" version.

[Phanx]

Released on WoWInterface and CurseForge. Please keep all reports, suggestions, questions, and other comments here in this thread. Thanks!

[Phanx]

Okay, I'm working on Mass Resurrection support, but I don't have access to the spell myself, so hopefully someone else can answer this:

Does Mass Resurrection only hit group members who were dead when it started casting? Or if someone dies mid-cast, will it hit them too?

[suicidalkatt]

Originally Posted by Phanx Okay, I'm working on Mass Resurrection support, but I don't have access to the spell myself, so hopefully someone else can answer this: Does Mass Resurrection only hit group members who were dead when it started casting? Or if someone dies mid-cast, will it hit them too?

I does still hit on players that die mid cast.

[Phanx]

Okay. So I need to detect when someone dies during a Mass Res cast, and send a callback indicating that they now have a res being cast on them.

Also, I'm changing the order of returns from the API (both callback and functions) to avoid having icky nil values in the middle of the stack when Mass Res is involved. The new order will always be caster, end time, target. If there's no end time, then just caster, target. If you call LRI:UnitIsCastingRes and there's no target, then it's a Mass Res. I already updated the API doc pages, and will commit the change shortly.

Edit: More questsions for someone with access to Mass Res -- does INCOMING_RESURRECT_CHANGED fire for players who die during a Mass Res cast? Does UnitHasIncomingResurrection return true for them? If you change the debug level in LibResInfo to 2 or higher, you'll get a message in your chat frame when the event fires telling you who it fired for, and whether the API thinks they have an incoming res. You can move the messages to ChatFrame3 or something if you don't want them spamming ChatFrame1.

[suicidalkatt]

Originally Posted by Phanx Okay. So I need to detect when someone dies during a Mass Res cast, and send a callback indicating that they now have a res being cast on them. Also, I'm changing the order of returns from the API (both callback and functions) to avoid having icky nil values in the middle of the stack when Mass Res is involved. The new order will always be caster, end time, target. If there's no end time, then just caster, target. If you call LRI:UnitIsCastingRes and there's no target, then it's a Mass Res. I already updated the API doc pages, and will commit the change shortly. Edit: More questsions for someone with access to Mass Res -- does INCOMING_RESURRECT_CHANGED fire for players who die during a Mass Res cast? Does UnitHasIncomingResurrection return true for them? If you change the debug level in LibResInfo to 2 or higher, you'll get a message in your chat frame when the event fires telling you who it fired for, and whether the API thinks they have an incoming res. You can move the messages to ChatFrame3 or something if you don't want them spamming ChatFrame1.

I'll have to check a bit later for that, although isn't INCOMING_RESURRECT_CHANGED only for when the cast of a spell begins? When mass rez goes off it's just an aoe from the caster on anyone in range.

[Phanx]

Originally Posted by suicidalkatt I'll have to check a bit later for that, although isn't INCOMING_RESURRECT_CHANGED only for when the cast of a spell begins? When mass rez goes off it's just an aoe from the caster on anyone in range.

Yes, but ideally, this will happen:

1. Player A starts casting Mass Res.
2. IRC fires for Player B, who is dead, because a resurrection is casting that will affect them.
3. Player C dies.
4. IRC fires for Player C, who is now dead, because a resurrection is casting that will affect them.
5. Player B finishes casting Mass Res.
6. IRC fires for both Player B and Player C, because a resurrection relevant to them is no longer casting.

If INCOMING_RESURRECT_CHANGED doesn't fire this way, it will mean I need to add a bunch of extra code to keep track of dead units myself.

[Phanx]

Changed in r22:

LRI:UnitHasIncomingRes(unit) now returns "CASTING" or "PENDING" as the first value, instead of the boolean true, to make it easier to determine whether the unit's res is pending (meaning, they have a dialog on their screen waiting for them to accept) or casting. Shouldn't require any changes in supporting code.

[suicidalkatt]

Originally Posted by Phanx If INCOMING_RESURRECT_CHANGED doesn't fire this way, it will mean I need to add a bunch of extra code to keep track of dead units myself.

INCOMING_RESURRECT_CHANGED didn't even fire from Mass Resurrection. Any other normal casted rez worked fine.

Seems like you'll have to track spell cast and have fun with it that way. Also checking for the debuff for that spell.

[Phanx]

Yeah, I just wrapped up over an hour of testing (thanks Talyrius!) and discovered that. Annoying, but not unexpected.

I just released r23 with support for Mass Resurrection. Also, if anyone was porting addons yet, please note that the order of callback arguments and function returns has changed. Check the docs on CurseForge for current details. I don't anticipate any more such changes.

[Phanx]

Everything seems to be stable and working correctly, so feel free to start porting addons over from LibResComm. Post here if you need help making the transition!

[myrroddin]

I guess I will have to get Ackis to use the Scroll of Resurrection on me, just so I can do more coding.

[Phanx]

Coding is the only reason I keep paying my $15 a month.

[Gronzig]

Insignificant issue found while preening my FrameXML.log:

The TOC references LibStub and CallBackHandler, but the libs are not included in the zip.

[myrroddin]

Also, speaking of LibStub and CallbackHandler: you might want to not specify versions of either, and always use the latest versions. Your choice of latest alpha or release; I have never noticed problems with alpha builds with them.

svn://svn.wowace.com/wow/libstub/mainline/trunk
svn://svn.wowace.com/wow/callbackhandler/mainline/trunk/CallbackHandler-1.0

[Phanx]

Originally Posted by Gronzig The TOC references LibStub and CallBackHandler, but the libs are not included in the zip.

Originally Posted by myrroddin you might want to not specify versions of either, and always use the latest versions.

I don't plan on addressing either of these, as I don't consider them problems.

Nobody should never be running a standalone copy of the library; it should be embedded in and loaded with an addon, and that addon is responsible for also including copies of LibStub and CallbackHandler.

Advanced users who choose to run their addons with libraries disembedded should also have standalone copies of LibStub and CallbackHandler; if they don't, it's absolutely not my problem. Such users are also going to have 500000 FrameXML.log errors anyway, so I don't consider that my problem either. The TOC exists solely for my convenience, and LibStub and CallbackHandler are referenced in it because I have unversionsed copies of them in my local LibResInfo folder so they are not cluttering up my already full AddOns folder. If you choose to use it, you're on your own.

If you're using the library in an addon, you should be embedding it in the addon.

[Gronzig]

I guess it would only cause a problem if an addon used LibResInfo which did NOT use LibStub. LibResInfo is relying on someone else loading it. Probably not even possible. It's not like I don't already have (I counted) 120 copies of LibStub.lua in my AddOns folder. I'm just That Guy who complains about error messages in log files.

[Phanx]

Addons embedding LibResInfo also need to embed LibStub and CallbackHandler. That's how every embeddable library works. An addon that uses AceAddon, AceDB, AceOptions, AceEvent, AceGUI, AceConfig, and AceTimer doesn't include 7 copies of LibStub (one inside each embedded lib); it just includes one (one alongside the other libs). Embeddable libraries should never be including their own dependencies, or you'll end up with an enormous number of duplicate files in a single addon. Authors using libraries simply need to pay attention and make sure they include everything their addon and the libraries it uses need.

[Gethe]

A new Hunter exotic pet, the Quilen, has a battle res.

[126393]   = GetSpellInfo(126393),   -- Eternal Guardian (hunter pet)