LibResInfo - resurrection info without comms

[Phanx]

Originally Posted by myrroddin 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:

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:

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.

[myrroddin]

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.

[myrroddin]

Would it break things in my local copy if I rearranged the callback arguments to your proposed standard arguments? Just wondering about the debug or APIs.

[Phanx]

I went ahead and committed the changes. I'd still like to do some testing; I'll be online later tonight from 10 or 11 PM PST onward. Updating the documentation pages now.

[myrroddin]

I would say all the testing was a success. You can safely tag a release for tomorrow's 5.2 patch, if you haven't already done so, or had such plans.

Once again, thank you for all the help, testing, recoding, and copious deaths!

[Phanx]

Everything should be stable now, and the documentation matches the actual functionality, so feel free to tag releases and whatnot.

[Gronzig]

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

[Phanx]

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.