LibResComm keeps track of resurrection and soulstones in a group. It broadcasts this using the CTRA res protocol that CTRA and oRA2 use too. It will not send messages when either of those are active.
BUGS:
- The endTime for resurrections casted by players that use oRA2 will not be accurate. This is because oRA2 sends its comm message on SPELLCAST_SENT and not SPELLCAST_START
- Resurrections that are succesfull will not trigger ResComm_ResEnd() for CTRA users. This is because CTRA only sends it on SPELLCAST_STOP.
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?
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.
I noticed on your example page that you have the callback on
function MyAddon:OnEnable()
However, I do not want it there, if possible. I would prefer it to be elsewhere, since my OnEnable/OnDisable try to register and unregister all events, respectively.
Of course, I would have no problems doing as your example if I could unregister all LibResComm events during the OnDisable()
If you are curious, I am rewriting from scratch SmartRes to use LibResComm and Ace3. Therefore, I would like to avoid using much of the existing code in SmartRes.
You know how it is: clean up, speed up, optimize, etc.
Basically, I'd like LibResComm to distinguish between the various types of "soulstone" effects so that addons using it can distinguish between them too. :)
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?
No.
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.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
API description: http://www.wowace.com/projects/librescomm-1-0/pages/api-description/
Requires: LibStub CallbackHandler
LibResComm keeps track of resurrection and soulstones in a group. It broadcasts this using the CTRA res protocol that CTRA and oRA2 use too. It will not send messages when either of those are active.
BUGS:
- The endTime for resurrections casted by players that use oRA2 will not be accurate. This is because oRA2 sends its comm message on SPELLCAST_SENT and not SPELLCAST_START
- Resurrections that are succesfull will not trigger ResComm_ResEnd() for CTRA users. This is because CTRA only sends it on SPELLCAST_STOP.
:HasRecovery(unit) - Unit has SS or ank option
:CanResurrect(unit) - Use has popup from a res (ResComm_Ressed)
Is combat res implemented?
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.
Rebirth is implemented.
You wouldn't need to register UNIT_HEALTH, simply register when the popup box disappear (NORESSED)
You?re right about not needing UNIT_HEALTH. I?m still wondering what use you have for those two functions?
I guess I can live without the two functions and make my own based on the events fired.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThere's 4 of them starting around line 276 in r39.
Posting the change for ["RESURRECT"] as an example.
The same change is needed for the other 3 (NO_SICKNES, NO_TIMER and DEATH)
local res = StaticPopupDialogs["RESURRECT"].OnShow StaticPopupDialogs["RESURRECT"].OnShow = function(self) lib:popupFuncRessed() res(self) endThis is for the WotLK beta/ 3.0.2 (and soon to be live) PTR.
Also hopefully did a correct fix of the WorldFrame hook.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatorfunction MyAddon:OnEnable()
However, I do not want it there, if possible. I would prefer it to be elsewhere, since my OnEnable/OnDisable try to register and unregister all events, respectively.
Of course, I would have no problems doing as your example if I could unregister all LibResComm events during the OnDisable()
If you are curious, I am rewriting from scratch SmartRes to use LibResComm and Ace3. Therefore, I would like to avoid using much of the existing code in SmartRes.
You know how it is: clean up, speed up, optimize, etc.
Myrroddin.
http://www.wowace.com/projects/librescomm-1-0/tickets/2-distinguish-between-soulstone-types/
Basically, I'd like LibResComm to distinguish between the various types of "soulstone" effects so that addons using it can distinguish between them too. :)
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorWhen 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.
target, resser = ResComm:IsUnitBeingRessed(target, resser)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBack 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.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorOr should I proceed with writing a function to catch other casts, knowing that it may cause conflicts?
No.
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.