Just so I understand, endTime from UnitHasIncomingRes is when that person's Accept timer runs out (60 seconds), and not the cast time of the caster's resurrection spell?Whereas UnitIsCastingRes' endTime is the cast time of the spell (10 or less seconds)? If that is the case, then I wonder, does LRI add the cast time to 60 in order to get the true time out?

No. The values (including endTime) provided by UnitHasIncomingRes refer to whichever resurrection will be available to the specified unit first. If they already have a pending resurrection, then endTime gives you the time that resurrection will expire. If they do not already have a pending resurrection, but at least one resurrection spell is being cast on them (including Mass Res), then endTime gives you the time that the first of those spells will finish casting. You don't need to do any math.

In your example, while Jixx is still casting Resurrection, endTime refers to the time his cast bar will hit full and the spell will actually be cast. After Jixx has cast Resurrection and Phanx has an accept/cancel dialog box on her screen, endTime refers to the time that dialog box will disappear and Phanx will no longer be able to accept the resurrection.

Originally Posted by myrroddin

... perhaps renaming UnitHasIncomingRes' endTime to expiryTime might be in order to lessen confusion.

You can name the variable whatever you want in your code. The documentation will continue to call it endTime because it can refer to either the end time of a spell cast, or the expiry time of a resurrection offer. That's why the first value returned by UnitHasIncomingRes is a string telling you whether the other values are related to a spell cast or a resurrection offer. At the most basic level, the idea is that you can perform a simple boolean check on the return from UnitHasIncomingRes to find out if you need to cast a res on the unit:

Code:

if LibResInfo:UnitHasIncomingRes(unit) then
-- don't bother, someone else's res will get to them first
else
-- they still need a res
end

Originally Posted by myrroddin

The other way to look at it, just to add confusion, is that UnitHasIncomingRes's endTime is not 60 + cast time seconds, and is just end time of the caster's resurrection.

Why would it be 60 + cast time seconds? If the res spell is still being cast, then endTime is the end time of the spell cast.

Here is the basic process:

Code:

function lib:UnitHasIncomingRes(unit)
if the unit can click "accept" to take a res that was already cast, then:
return "PENDING", time the res will stop being available
elseif *one* res spell is being cast on the unit, then
return "CASTING", time the spell will finish casting, info about the unit casting the spell
elseif *more than one* res spell is being cast on the unit, then
determine which spell will finish casting first, and
return "CASTING", time *that* spell will finish casting, info about the unit casting *that* spell
end
end

Originally Posted by myrroddin

Personally, I would have endTime in both UnitHasIncomingRes and UnitIsCastingRes = cast time, and make a note on the API page that authors should add 60 to get the Accept expiration time. My reasoning is that authors tend to want the cast time not the expiry time, which I pointed out is simple addition anyway.

Again, you are either not reading the documentation, or not reading the documentation. If the spell has already finished casting, then there is no cast time to provide, because there is no spell being cast.

Also, UnitHasIncomingRes and UnitIsCastingRes are different functions that provide information about different things.

UnitHasIncomingRes tells you about the res the specified unit will be able to take first. If they already have a res waiting to be accepted, then it tells you about that res. If they don't have a res waiting to be accepted, then it tells you about the first res spell that will finish casting on them.

UnitIsCastingRes tells you about the res spell being cast by the specified unit, even if the target of that spell already has a res ready to accept and 20 other people are already casting res spells on the same target.

Read the documenation and stop over-thinking it. It works exactly the way the documentation says it works. You don't need to blindly print the callback args and try to figure out what they mean on your own, because they mean exactly what the documentation says they mean.

Alright, got it. I had a mental chuckle, but I got it. Now to wait until you either change the APIs and callbacks, or update the documentation to match the code. *Rubs hands together gleefully* Can't wait! ... Well, I can, and will, but you know what I meant.

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.

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.

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.

currentCasterID and currentCasterGUID are the unitIDs or GUIDs for whomever is the current res caster on "unit"

firstCasterID and firstCasterGUID are the same as above, but for whomever's cast lands first

unit is "player", "target", "raid10", etc

]]--

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.

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.

I don't plan to add this to the API, but you should be able keep track of it yourself with minimum effort by either:

(1) storing the endTime value in a variable, and comparing it against incoming callbacks -- if the endTime supplied by the callback is a larger value (later time) then the callback res is not the first on the target, and you shouldn't overwrite your variable.

(2) calling LRI:UnitHasIncomingRes(targetGUID) when you get a callback -- if the caster info from the API doesn't match the caster info from the callback, then the callback res is not the first on the target.

Phanx, I am wondering about the update status to the Mass Resurrection code. I still see the occasional error regarding line 211. Last time we talked, you suggested that you were going to rewrite LibResInfo to have separate callbacks for Mass Resurrection. Is there updated news?

I have seen some odd behaviour ever since patch 5.4.1 hit. The debug prints are showing up, and I did not enable them. I tried the slash commands "lri debug 0" and "lri debug"; it says that is invalid output. I figure this is something simple, possibly something I did that I don't remember doing, but I can't spot the fix.

Also, I would like to do some more testing, as I keep getting nil errors periodically. I think it has something to do with Mass Resurrection, but occasionally see it for normal class spells. Granted, there are some times when the Combat Log, and therefore LibResInfo, cannot get information, but it would be nice to track down what and where, if only to "catch" it. BugSack gets a bit annoying with its "Uh Oh"!

Debugging is turned on automatically when you're running LRI as a standalone library. You should be embedding it in your addon instead. Also, the command to set the debugging level is just "/lri N", not "/lri debug N"; use "/lri 0" to turn it off.

I have a new version ready for more extensive testing; check out revision 60 or later from SVN. There are a number of "under the hood" changes that should help avoid data desynchronization, and the following significant changes:

(1) There is now support for pre-cast Soulstones.

lib:UnitHasIncomingRes(unit) will now return "SELFRES" as its first value if the unit has a Soulstone available, and the LibResInfo_ResPending callback will now pass a fourth argument (boolean true) if the pending resurrection is a Soulstone.

lib:UnitHasIncomingRes(unit) will now return "MASSRES" instead of "CASTING" as its first value if the first res that will land on the unit is from Mass Res.

The new Mass Res callbacks/API have not been tested at all since I'm limited to PTR testing (my live account is not currently active) and don't have a PTR guild. If you have access to a character with Mass Res on the PTR and can help me test, please PM me your BattleTag and when you're available so we can set up a time. I'm generally able to get on the PTR between 10 PM and 2 AM Pacific time (GMT-8).

Developers, if you want to install r60 or later as a standalone addon for testing, please let me know if you run across any odd behavior. Debugging messages are automatically enabled and sent to ChatFrame3 when the lib is installed standalone. Use "/lri 3" to change the debugging level (0=off, 5=spam) or "/lri ChatFrame1" to change the output frame.

Edit:
Also, the last version has been tagged at r58. If you need to make a release with your addon over on CurseForge, change your .pkgmeta file to point to /tags/r58/LibResInfo-1.0 instead of /trunk/LibResInfo-1.0/LibResInfo-1.0 (yes, that is one fewer "LibResInfo-1.0" folders, not a typo).

*Edit: wouldn't the pkgmeta's tag: latest work rather than specifying a directory path? Or, because the repo is here, will that not work?

It should work, or tag: r58, though you will have to change the path either way, since the tags path does not include the top-level LibResInfo-1.0 folder... that was an oversight on my part, but I'm not going to bother changing it since if you're already changing to point to tag: latest it's not really more work to change the path too.

(Really, I wish WoWI would just fix the regex in their packager so I don't need that extra folder in /trunk )