|
I realized the same thing as I was crawling into bed. I also realized that it would be more intuitive to have caster passed to ResCastStarted rather than target. However, if you are keeping all the arguments, then it becomes moot.
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?
What I mean is, lets say I want to know when Phanx's Accept button expires if Jixx resurrects her. Let's say Jixx's haste makes his Resurrection cast = 8.9 seconds, which means Phanx times out in 68.9 seconds –– at the start of Jixx's cast. Now, this isn't hard to figure out if LRI does not directly provide this information. All I need to know is Jixx's cast time and add it to 60.
Sounds good, although if all that above is true, then perhaps renaming UnitHasIncomingRes' endTime to expiryTime might be in order to lessen confusion.
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. I was thinking that is the case, but if I was wrong, that might explain a few results during my tests.
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.
Sometimes you want to examine the target for when an incoming cast ends, other times you want to examine the caster.
... In other news, I haven't theory-crafted this much since I wrote LibGuildBankComm, and it is nice to have the tête-à-tête.
|