I added complete to the _ResEnd callback, which is Boolean. It is true if the resurrection cast is completed, false if the cast is stopped, interrupted, or has failed. This is a non-breaking change designed to allow addons to clear resser data more accurately.
ResComm_ResEnd(event, resser, target, [B][COLOR=Red]complete[/COLOR][/B])
-- Fired when a resurrection cast ended. This can either mean it has failed or completed.
-- Use [I]ResComm_Ressed[/I] to check if someone actually ressed. [I]complete[/I] is true if the cast finished.
The only API I could find for resurrection spells is UnitHasIncomingResurrection(unit) which is not documented fully on WoWPedia, and not at all on WoWProgramming. One would think the API is self-explanatory, however. All it provides is a true/false (1/nil ?) for the unit, and doesn't say who the caster is. Or it might, I don't know as it isn't documented.
To answer your question, Phanx, think of SmartRes2 and other res monitors: they need to know caster, cast time, and target to display on the bars. If you don't care about who the resser is, that's fine, as you said you didn't need that. However, SR2 does care because it has the duplicate res warning, and just telling people that Bob is being ressed 4 times doesn't mean much unless you also say that Bob is being ressed by Sally, Joe, Ted, and Moira, and which cast will land first.
In order to get that information, you need to hook UNIT_SPELLCAST_SENT, which is for the player or a unit controlled by the player. Yes, I know you know this, and no, I'm not trying to be sarcastic or facetious. Once you have the info, you need to comm it to other people or they won't have any idea whom you are casting on, especially if you target via mousedown.
What I am getting at is there is still value in this library. If there wasn't, then sure, let it slide and rewrite any addons that may use it with Blizzard APIs instead.
For Grid, I understand why the caster is not important, and only the target matters. Different addon, different purpose. 'Tis all good.
I just updated this for Mists, as, pointed out earlier, Blizzard's API is still lacking. Also, I think it is safe to remove the localization, but after a year and a half away, I will need a refresher on what can be removed or replaced.
If it works, then the ticket can be closed. Just asking before I close the ticket. On a side note, the only way I have been able to get a release tag is name it starting with "v", but I would prefer to use DathRarhek's naming, which started with "r", just like the alphas.
I would imagine it is a setting in the repository, but what?
And wouldn't you know it, someone has reported another issue, this time with the worldframemousedown.
2x LibResComm-1.0-90072:320: bad argument #1 to 'match' (string expected, got nil)
LibResComm-1.0-90072:320: in function `worldFrameOnMouseDown'
LibResComm-1.0-90072:374: in function <...ibs\LibResComm-1.0\LibResComm-1.0\LibResComm-1.0.lua:373>
<in C code>: ?
I know the cause, I think. The L variable isn't picking up CORPSE_TOOLTIP outside of the enUS.
I have an informal request. I don't know what constraints you're operating under, so this may not be feasible, but: could "release" tags be delayed until somebody (you or whoever) has had a chance to login with the alpha code and test it for syntax errors and whatnot?
From now on, yes. I was a bit constrained because my guild, even though I am not currently active, was asking for updates. I was kind of under the gun, as it were.
Normally, yeah, I would, and will from now on, gets alphas up for testing, and leave them there for a while.
I would like to apologize for all the snafus. I am truly sorry.