Why is NORESSED needed so badly? NORESSED is used for when the accept resurrection or use ankh/ss has been declined. The times it is used is very small, because who declines a res? I'll implent it tho.
I can add those two functions. It would require registering for UNIT_HEALTH tho. And what you won't be able to do is listen for UNIT_DEATH and then expect those two functions to return the correct message right away, because you have to deal with latency. That's why I decided to go with callbackhandler events in the first place.
Yes, they time out. Someone has to be afk for it to happen. It?s a border case tho and hardly breaking the usability of the lib. I?ll add it as soon as I get back to my game box.
You?re right about not needing UNIT_HEALTH. I?m still wondering what use you have for those two functions?
You'd be surprised how often NORESSED is sent (afk, res is bugged, user misclicks), it happens a lot, and it's _very_ useful - why NOT implement it? I could finally get rid of having to depend on oRA2 for res messages.
I guess I can live without the two functions and make my own based on the events fired.
Does this library distinguish between the in-combat and out-of-combat Druid rez spells? Might be nice for automatic rez accept addons like Automaton that currently don't accept a rez from a Druid because it can't tell the difference.
Addons actually can tell the difference, without needing to use LibResComm or any other kind of communication. I just haven't committed the necessary changes to Automaton because I don't use it anymore, but basically, when the resurrection request event fires, it passes the name of the person casting the resurrection. Currently Automaton (using code I added) scans through your raid/party to find that person's class, and if they're a druid, doesn't auto-accept. The change that would need to be made would be to also check whether that person is in combat. Since this is all practically instant, it's reasonable to assume that if the person is a druid and is in combat, it's an in-combat resurrection. I use this in my personal "do stuff automatically" addon, and it works fine.
Would be cool to get that functionality in Automaton then. Also, on a related note: I noticed the Automaton module to automatically accept invites from guild members was broken on the PTR such that it would not accept the invite but would also not show the popup that would allow manual acceptance.
Well, Automaton is now using a Git repo, and I'm not installing a Git client just to fix an addon I don't use. I'll post the required code changes in a ticket on the project page; please direct further discussion on this topic to the ticket's comments, since this isn't really on-topic for this thread. :)
I created a thread in the code discussion forums, and got some useful feedback and suggestions. The issue at hand is that sometimes LRC picks up casts from group members, and sometimes it doesn't. I'm trying to see if the common link is LRC itself (ie, the lib is installed because some user has oRA3, for example).
When raiding the other day, one Priest (with SmartRes2 including LibResComm-1.0) and one Paladin (with no addons using LibResComm-1.0) started ressing the same target, and the Priest player did not see the Paladin's cast, even though they were standing right next to each other.
I find this odd behaviour, as wouldn't the lib use Blizzard events such as Unit_SpellCast_xxx, in which case it shouldn't matter if one person had LRC, and 39 people in a raid did not, the one should see all casts?
On the other hand, I was doing one of the Icecrown-5 instances, was dead and on the ghost gryphon flying back, when SR2's res bar popped because the Shaman was casting on the tank. The Shaman was inside the instance, I was very clearly outside the instance, so range is not an issue.
My question is, why the inconsistent behaviour, if LRC uses Blizzard spellcast events?
On a side note, it might be a good idea to update the API page to acknowledge that IsUnitBeingRessed returns unit and resser, not just unit.
The answer lies in the code : LRC uses the Blizzard events to monitor player's casting only. It expects other group members to have LRC too and thus it ignores all spellcast events from other characters. It would be possible to monitor other res but there is no way to know the target for sure, which is why LRC exists in the first place.
Back to your example, if a priest with LRC and a paladin without IRC were both ressing the same target, a modified LRC could tell that both are ressing someone but not the target of the paladin.
I wonder if it would be worth it to update LibResComm-1.0 to catch all spells, by any player?
The point of LibResComm-1.0 is to share accurate information about your resurrections with your group. It does for resurrections what LibHealComm does for heals. There's no reason to bloat LibHealComm by having it announce when other people start casting healing spells, and there's no reason to bloat LibResComm by having it announce when other people start casting resurrection spells, for exactly the same reasons.
It's not possible to get accurate information about heal amounts or resurrection targets for spells cast by other people by watching local events, and there's no benefit in having a library announce those spellcasts over having your own addon detect and announce them, or over simply having cast bars show those spellcasts.
I think I speak for more than just myself when I say that it's would not be useful at all to see "Priest X is casting Resurrection!" without being able to see who he's casting it on.