The post before yours (by Yoshimo) is the only testing result I've seen.
Frankly, though, is this library even really useful now that Blizzard added the incoming resurrection API? The main reason any addon I'm involved with still uses this library is that I've been too lazy to investigate the new API and rewrite them.
I didn't know about Blizzard's API, because my account has been expired since 4.1.x. I could look into it, as the "smart" feature of SmartRes2 may still be useful, even if the library isn't.
In any case, I'm glad Blizzard finally introduced said API; it has been needed forever.
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.
What's really missing? If you need to know who is casting a resurrection -- though I can't really think of any scenario where that information is actually useful, rather than just trivia that might be vaguely interesting to know about -- it wouldn't be too hard to figure it out yourself by watching various events and making some inferences.
I considered doing it in Grid's built-in Resurrect status module, but decided not to, since I couldn't think of any actual value in that information. It currently knows when multiple people are resurrecting the same target, and when someone has finished casting a res but the target hasn't accepted it yet.
Anyway, if you want to remove the hardcoded localization, just delete lines 39-100 in the lib file (all the ones that check GetLocale() and add strings to the L table). However, it's not necessarily safe, as only 1 of the 4 strings has been confirmed in 1 of the 11 game locales. If you want to test it the hard way, comment out lines 39-100, tag a beta, and see who complains.
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.
It doesn't say who the caster is, but there's nothing stopping you from keeping track of that information yourself. Keep one table indicating who is being resurrected. Keep a second table indicating who is casting resurrections, and their targets. When INCOMING_RESURRECT_CHANGED fires, scan the group and see who is now being resurrected, and then compare that list against the list from the last event to learn about new resurrections. Then scan the group to see who just started casting a resurrection spell; the UnitCastingInfo API will tell you what spell they are casting, when they started casting it, and when the cast will complete. You can easily infer the target. Watch the combat log to see when the spell cast successfully completes (eg. look for the resurrect event type), then start a timer to know when the pending resurrect will expire. Watch UNIT_HEALTH to find out when someone accepts a res.
... 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.
I'd argue that you don't actually need to know who the other 3 players are, or even that there are 3 of them; all you need to know is that the dead guy is already being resurrected. Resurrecting is not really time-critical, so if it takes 0.1 seconds longer for Sally to res Bob than for Ted, because she has more haste, who cares?
But, if you want to have that information, you can get it without any comms at all. It just takes a little more work. :)
Sorry to butt in, playing the healer occassionally (resto shaman is my 'principle' alt) I've found that I do care about who's casting rezz on who as well as collisions (who's rezz will land first)
Without that information you can easily end up having 2-3 rezzers starting and stoping together when they realize x is being rezzed by 'someone'.
On the other hand seeing "my rezz will land first, I continue", "my rezz will not land first, look for a new body" is quite helpful.
Having established that caster information is desirable for some players (I'm one of them) I don't see why not use comms vs a convoluted way that "requires a little (or a lot) more work".
You could argue that doing it in a comm-independent way doesn't require users to have a library installed but since we've found that the default interface doesn't provide the necessary information it comes down to a choice of addon anyway (with comms vs without)
Resto shaman has been my main since vanilla, and I've never cared who was ressing who, or when their res would land... if someone is already ressing X, I'm not going to bother starting a cast, even if mine would land 0.1 seconds earlier. Even if I happen to start casting on the same person at the same time as someone else, and nobody notices, well, what's really being lost? Even 10 seconds while sitting around recovering for a wipe doesn't really matter, and I don't think this happens often enough to dedicate screen space or system resources to preventing. :p
Anyway, the main reason I'm arguing against a comm library is that I'm no longer using it in any of my addons (including Grid) and I wouldn't be surprised to find that many other addons have also switched over to the native API. This makes addons that are still using the library less reliable (since they're getting data from fewer players) unless you force everyone in your group to install an addon they personally have no use for, which never makes anyone happy. In fact, if I were ever in a guild that required me to install LibResComm at this point in time, I'd probably write some code to send fake res data just to spite them. If there's a way to do something that doesn't depend on forcing addons on other people, you should generally do it that way.
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.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumon german client:
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorFrankly, though, is this library even really useful now that Blizzard added the incoming resurrection API? The main reason any addon I'm involved with still uses this library is that I've been too lazy to investigate the new API and rewrite them.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorIn any case, I'm glad Blizzard finally introduced said API; it has been needed forever.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think ive seen a problem where the smartress castbar wasnt canceled when aborting the rezz, but i need to re-check it.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatorhttp://www.wowace.com/addons/librescomm-1-0/
I considered doing it in Grid's built-in Resurrect status module, but decided not to, since I couldn't think of any actual value in that information. It currently knows when multiple people are resurrecting the same target, and when someone has finished casting a res but the target hasn't accepted it yet.
Anyway, if you want to remove the hardcoded localization, just delete lines 39-100 in the lib file (all the ones that check GetLocale() and add strings to the L table). However, it's not necessarily safe, as only 1 of the 4 strings has been confirmed in 1 of the 11 game locales. If you want to test it the hard way, comment out lines 39-100, tag a beta, and see who complains.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorTo 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.
It doesn't say who the caster is, but there's nothing stopping you from keeping track of that information yourself. Keep one table indicating who is being resurrected. Keep a second table indicating who is casting resurrections, and their targets. When INCOMING_RESURRECT_CHANGED fires, scan the group and see who is now being resurrected, and then compare that list against the list from the last event to learn about new resurrections. Then scan the group to see who just started casting a resurrection spell; the UnitCastingInfo API will tell you what spell they are casting, when they started casting it, and when the cast will complete. You can easily infer the target. Watch the combat log to see when the spell cast successfully completes (eg. look for the resurrect event type), then start a timer to know when the pending resurrect will expire. Watch UNIT_HEALTH to find out when someone accepts a res.
I'd argue that you don't actually need to know who the other 3 players are, or even that there are 3 of them; all you need to know is that the dead guy is already being resurrected. Resurrecting is not really time-critical, so if it takes 0.1 seconds longer for Sally to res Bob than for Ted, because she has more haste, who cares?
But, if you want to have that information, you can get it without any comms at all. It just takes a little more work. :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWithout that information you can easily end up having 2-3 rezzers starting and stoping together when they realize x is being rezzed by 'someone'.
On the other hand seeing "my rezz will land first, I continue", "my rezz will not land first, look for a new body" is quite helpful.
Having established that caster information is desirable for some players (I'm one of them) I don't see why not use comms vs a convoluted way that "requires a little (or a lot) more work".
You could argue that doing it in a comm-independent way doesn't require users to have a library installed but since we've found that the default interface doesn't provide the necessary information it comes down to a choice of addon anyway (with comms vs without)
Anyway, the main reason I'm arguing against a comm library is that I'm no longer using it in any of my addons (including Grid) and I wouldn't be surprised to find that many other addons have also switched over to the native API. This makes addons that are still using the library less reliable (since they're getting data from fewer players) unless you force everyone in your group to install an addon they personally have no use for, which never makes anyone happy. In fact, if I were ever in a guild that required me to install LibResComm at this point in time, I'd probably write some code to send fake res data just to spite them. If there's a way to do something that doesn't depend on forcing addons on other people, you should generally do it that way.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorIt might in a challenge mode dungeon! :)
Although could argue that wiping isn't the best tactic to get good times anyway :p
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatorhttp://www.wowace.com/addons/librescomm-1-0/pages/api-description/