There was an obvious mistake in the Paladin class module, so it didn't work for any locale for Paladins, that is fixed in the attached "release".
Thanks, it's working now.
But I have another little feature request:
Can you please add some sort of seperator between the current HP and the estimated HP in the PitBull bar, like it's in the VisualHeal bar? Because it's very confusing if the target suddenly has more HP but the heal hasn't completed yet.
Can you make LibHealComm work with CastComm data? That way you would get data from Grid and sRaidFrame users - and I could move away from CastComm :)
Unfortunately CastComm does not send information about heal size, and the event processing has some weak spots. First, it doesn't listen to UNIT_SPELLCAST_STOP, which means that it will not detect this sequence as a spell casting that stops:
Cast time spell being interrupted by shield bash:
SENT
START
STOP
STOP
or this:
Cast time spell being interrupted by Earth Shock:
SENT
START
DELAYED
STOP
STOP
Furthermore, it clears the last spell name sent, when the UNIT_SPELLCAST_INTERRUPTED is received, which means that the following (real-world) sequence fails, because the START for the second spell will be rejected because the INTERRUPTED event for the first spell is received after the SENT for the second spell:
SENT
START
STOP
SENT
INTERRUPTED
STOP
START
SENT
INTERRUPTED
STOP
START
SUCCEEDED
STOP
Furthermore, CastComm was designed to broadcast all spellcast-activity for all groups members, which is completely overkill for the purpose. VisualHeal only transmits when healing spells are started or stopped. These were some of the thoughts that led to the decision to let LibHealComm-3.0 do it's communication by itself in its own format, free of these defects, and not forced to compensate for receiving events from an unreliable source.
With that being said, I'd be happy to help you integrate LibHealComm-3.0 into sRaidFrames if you want to, it can happily coexist with CastComm, no problem.
Quote from cremor »
Thanks, it's working now.
But I have another little feature request:
Can you please add some sort of seperator between the current HP and the estimated HP in the PitBull bar, like it's in the VisualHeal bar? Because it's very confusing if the target suddenly has more HP but the heal hasn't completed yet.
I'll add sparks between the bars when i get a chance, thanks the feedback!
Any chance for said integration into Grid? :P I'd love to ditch CastComm myself, but the healing notification on group members in Grid is quite useful.
I'm optimistic that hacking GridStatusIncomingHeals or GridStatusIncomingHealth to use HealComm-2.0 is a realistic posibility. In a perfect world, I would want a Grid status indicator which shows something like "1.2k|3k", where the first number is other heals, the second number is my heal, and the text is colored based on how much overhealing my heal would do.
Any chance for said integration into Grid? :P I'd love to ditch CastComm myself, but the healing notification on group members in Grid is quite useful.
Quote from wesleydungan »
I'm optimistic that hacking GridStatusIncomingHeals or GridStatusIncomingHealth to use HealComm-2.0 is a realistic posibility. In a perfect world, I would want a Grid status indicator which shows something like "1.2k|3k", where the first number is other heals, the second number is my heal, and the text is colored based on how much overhealing my heal would do.
I haven't had a look at how Grid works, but apparently it is quite modular, so shouldn't be much of a problem to put LibHealComm-3.0 (not HealComm-2.0) to good use there. However, in the "perfect world" the incoming heals will show on the frames also when you're not healing yourself - that's what it does in PitBull now. If this is by means of a bar or a text I couldn't say - not that familiar with Grid. But I'll have a look at it when I've got text and sparks added to the PitBull version.
Thanks, it's working now.
But I have another little feature request:
Can you please add some sort of seperator between the current HP and the estimated HP in the PitBull bar, like it's in the VisualHeal bar? Because it's very confusing if the target suddenly has more HP but the heal hasn't completed yet.
I've added the sparks between the bars now - not tested very well though, but seems to work :)
I have thrown together a Grid status indicator that works with VisualHeal-Ace3-4. For anyone that wants to play around with it, copy the attached file into the VisualHeal directory and append GridStatusVisualHeal.lua to the end of VisualHeal.toc after PitBull_VisualHeal.lua. Make sure you have Grid installed as well. Then, from the Grid config menu, specify the locations where you want the VisualHeal status indicator to appear - Center Text and Health Bar are good locations.
Units receiving heals, which the player isn't healing, will display the new health deficit which will exist after all incoming heals land. If the deficit is positive, then the unit has incoming overheals. When the VisualHeal status is displayed on the Health Bar, the bar reflects the unit's post-heal health level.
If the player is healing a unit, the text will again display the new health deficit which will exist after all incoming heals and the player's heal lands. The color of this text will change from green to red depending on how much of the player's heal will be wasted. The text displayed for an overheal just shows the player's overheal amount and not the total overheal incoming on the unit.
xbeeps, if you want to include this code with VisualHeal, then by all means, go for it. As you will see, I borrowed heavily from your PitBull code.
I also have a Grid status indicator addon which works with HealComm-2.0, but it doesn't account for heal modifiers on targets. (I'm very glad to see that a get() method for heal modifiers was included in LibHealComm-3.0.) If there is interest, and xbeeps doesn't object, I would be happy to post a zip file with this code as well.
Furthermore, CastComm was designed to broadcast all spellcast-activity for all groups members, which is completely overkill for the purpose. VisualHeal only transmits when healing spells are started or stopped. These were some of the thoughts that led to the decision to let LibHealComm-3.0 do it's communication by itself in its own format, free of these defects, and not forced to compensate for receiving events from an unreliable source.
Yes, CastComm is overkill and spammy, which is why I want it out - but Grid uses it, and the majority of people use Grid, so can't just remove it.
Would it not be possible to intercept CastComm data and simply make basic assumptions based on the data you get (as grid and sRaidFrames already does). That way you could get a lot more data from a lot more people, while not 100% accurate it would improve the adoption of your lib.
xbeeps, if you want to include this code with VisualHeal, then by all means, go for it. As you will see, I borrowed heavily from your PitBull code.
I also have a Grid status indicator addon which works with HealComm-2.0, but it doesn't account for heal modifiers on targets. (I'm very glad to see that a get() method for heal modifiers was included in LibHealComm-3.0.) If there is interest, and xbeeps doesn't object, I would be happy to post a zip file with this code as well.
Very nice work i must say! :)
I'll include it right away. Regarding HealComm-2.0, i was hoping to phase that out completely, and quickly.
Quote from Peragor »
I added VisualHeal (Ace3) detection in GridStatusHealer. It also supports Ace2 version.
Very nice too :)
Quote from Saroz »
Yes, CastComm is overkill and spammy, which is why I want it out - but Grid uses it, and the majority of people use Grid, so can't just remove it.
Would it not be possible to intercept CastComm data and simply make basic assumptions based on the data you get (as grid and sRaidFrames already does). That way you could get a lot more data from a lot more people, while not 100% accurate it would improve the adoption of your lib.
I'm afraid the lack of heal size is too limiting, and it means that each library instance (each client) needs to include "guessing code" for every healer class. Right now there is an accurate module for each healer class, and only the one that matches the player's class is loaded. I simply don't want to use guess-work for this as the heal sizes will be way off in most practical cases. Besides, it's not that hard to enforce certain mods in a guild, so if you want accurate heal synchronisation between healers, you'll need to make sure that all healers have LibHealComm-3.0 and some addon that can show the data it presents (VisualHeal).
I'm trying to convince other healers to use VH, but part of the difficulty is that these updates are only available on the forums. I assume this is because Ace3 is still in beta?
I'm trying to convince other healers to use VH, but part of the difficulty is that these updates are only available on the forums. I assume this is because Ace3 is still in beta?
Yes, but I'll try to get VisualHeal transfered to trunk as soon as possible. If neccessary before Ace3 i released. I don't even know what the plan is for Ace3, but i read something about late christmas present, although noone said christmas this year or last year. LibHealComm-3.0 on the other hand does not have any external ties to Ace3 (LibStub and CallbackHandler are hard-embedded), so it wouldn't hurt to move it there soon.
I have no objections to replace CastComm by LibHealComm-3.0 in future versions of Grid - in fact I'd appreciate if someone did so.
Maybe Pastamancer doesn't want it for a good reason (I remember he had problems with HealComm-2), but I do think it makes sense to have as many addons as possible use the same heal comm library. So if anyone has some spare time, why not just branch Grid, replace CastComm by LibHealComm-3, get Pasta to take a look at it and then merge it with the trunk?
I have no objections to replace CastComm by LibHealComm-3.0 in future versions of Grid - in fact I'd appreciate if someone did so.
Maybe Pastamancer doesn't want it for a good reason (I remember he had problems with HealComm-2), but I do think it makes sense to have as many addons as possible use the same heal comm library. So if anyone has some spare time, why not just branch Grid, replace CastComm by LibHealComm-3, get Pasta to take a look at it and then merge it with the trunk?
HealComm-2.0 was quite limited in functionality, mainly because there was only an event to signal the start of spell casting, so you'd have to use polling (in OnUpdate handler) to determine when the heal would stop, because Blizzard for some reason only generates the UNIT_SPELLCAST_STOP event sometimes for other players in the raid/party.
This is not the case for LibHealComm-3.0, where you have callbacks for all significant events (start, delayed, stop), so you only have to do updating when something actually happens asyncronously. Support for the missing spells that have multiple targets is also coming (just committed the framework for that, including full support for Binding Heal). Also, LibHealComm-3.0 is significantly slimmer and easier to integrate. Unlike HealComm-2.0, the only external dependencies are LibGratuity-3.0 and LibBabble-Spell-3.0 which themselves do not have any external dependencies. So you can say goodbye to AceEvent-2.0, AceLibrary, AceLocale-2.2, Babble-Spell-2.2, AceOO-2.0, Gratuity-2.0 and Roster-2.1.
Finally, I'm also investigating the feasibility of adding the ability to track HoT's so that LibHealComm-3.0 will be a complete heal tracking library. It's only possible to relibably track HoT's locally for your own HoT's so some communication is needed, and I think LibHealComm-3.0 is the appropriate place to put this functionality.
Im glad you guys are talking about making this compatible with Grid. I dont use any healing helper add ons, but need to know what incomming heals are. Many of my guildies use Grid, so if those work together, Id be able to use my set up yet still see the incomming heals like in Grid. VisualHeal is exactly what I need, something that tells me what I want to know, but not a big bulky UI element on my screen.
I have no objections to replace CastComm by LibHealComm-3.0 in future versions of Grid - in fact I'd appreciate if someone did so.
Maybe Pastamancer doesn't want it for a good reason (I remember he had problems with HealComm-2), but I do think it makes sense to have as many addons as possible use the same heal comm library. So if anyone has some spare time, why not just branch Grid, replace CastComm by LibHealComm-3, get Pasta to take a look at it and then merge it with the trunk?
I didn't want to encumber users with the additional overhead of a full-blown heal-tracking library. Neither squishy or detox had full heal-tracking, so I kept it out of Grid.
I looked through HealComm-3.0 in branches briefly and it doesn't seem to handle Prayer of Healing yet. Until HealComm-3.0 is finished, I don't think it should replace CastComm in Grid. Thanks for the information on cases that CastComm doesn't handle, I'll look into fixing that.
Currently, CastComm and HealComm3 seem to generate about the same amount of traffic on my Shammy. I have yet to use any addon besides Grid that uses CastComm, and it's really noisy on my Mage (whereas HealComm3 isn't even loaded). Unless someone has additional uses for a generic casting library, I'd really like to see a switch done.
Currently, CastComm and HealComm3 seem to generate about the same amount of traffic on my Shammy. I have yet to use any addon besides Grid that uses CastComm, and it's really noisy on my Mage (whereas HealComm3 isn't even loaded). Unless someone has additional uses for a generic casting library, I'd really like to see a switch done.
CastComm is by nature/design significantly more chatty than LibHealComm-3.0:
1) LibHealComm-3.0 transmits two messages for each heal (start and stop) while LibCastComm transmits the individual events. For most spell casts there is no difference here though (the exception is when there are delays caused by damage).
2) LibHealComm-3.0 is only actively transmitting if the player is a healing class. This alone accounts for a reduction of ~50-70% (because only ~30% of your raid will be healers).
3) LibHealComm-3.0 only transmit if the spell being cast is a healing spell. All kinds of spells are transmittet with CastComm, including those non-heal spells cast by healers and non-healers alike (this is a very long list if you start counting!).
Quote from Pastamancer »
I looked through HealComm-3.0 in branches briefly and it doesn't seem to handle Prayer of Healing yet. Until HealComm-3.0 is finished, I don't think it should replace CastComm in Grid.
Agree, LibHealComm-3.0 is still in branches, and will remain there until:
1) It has support for Binding Heal and Prayer of Healing (and maybe Circle of Healing, but that may come free with support for Circle of Healing, only it might be impossible to determine the exact targets of the heal, just as is the case with Chain Heal)
2) I'm confident that the state-machine is robust, communication is error free, and the library is incapable of generating errors.
I'll be sure to let you know, when i move it to trunk.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThanks, it's working now.
But I have another little feature request:
Can you please add some sort of seperator between the current HP and the estimated HP in the PitBull bar, like it's in the VisualHeal bar? Because it's very confusing if the target suddenly has more HP but the heal hasn't completed yet.
Unfortunately CastComm does not send information about heal size, and the event processing has some weak spots. First, it doesn't listen to UNIT_SPELLCAST_STOP, which means that it will not detect this sequence as a spell casting that stops:
Cast time spell being interrupted by shield bash:
SENT
START
STOP
STOP
or this:
Cast time spell being interrupted by Earth Shock:
SENT
START
DELAYED
STOP
STOP
Furthermore, it clears the last spell name sent, when the UNIT_SPELLCAST_INTERRUPTED is received, which means that the following (real-world) sequence fails, because the START for the second spell will be rejected because the INTERRUPTED event for the first spell is received after the SENT for the second spell:
SENT
START
STOP
SENT
INTERRUPTED
STOP
START
SENT
INTERRUPTED
STOP
START
SUCCEEDED
STOP
Furthermore, CastComm was designed to broadcast all spellcast-activity for all groups members, which is completely overkill for the purpose. VisualHeal only transmits when healing spells are started or stopped. These were some of the thoughts that led to the decision to let LibHealComm-3.0 do it's communication by itself in its own format, free of these defects, and not forced to compensate for receiving events from an unreliable source.
With that being said, I'd be happy to help you integrate LibHealComm-3.0 into sRaidFrames if you want to, it can happily coexist with CastComm, no problem.
I'll add sparks between the bars when i get a chance, thanks the feedback!
I haven't had a look at how Grid works, but apparently it is quite modular, so shouldn't be much of a problem to put LibHealComm-3.0 (not HealComm-2.0) to good use there. However, in the "perfect world" the incoming heals will show on the frames also when you're not healing yourself - that's what it does in PitBull now. If this is by means of a bar or a text I couldn't say - not that familiar with Grid. But I'll have a look at it when I've got text and sparks added to the PitBull version.
I've added the sparks between the bars now - not tested very well though, but seems to work :)
Units receiving heals, which the player isn't healing, will display the new health deficit which will exist after all incoming heals land. If the deficit is positive, then the unit has incoming overheals. When the VisualHeal status is displayed on the Health Bar, the bar reflects the unit's post-heal health level.
If the player is healing a unit, the text will again display the new health deficit which will exist after all incoming heals and the player's heal lands. The color of this text will change from green to red depending on how much of the player's heal will be wasted. The text displayed for an overheal just shows the player's overheal amount and not the total overheal incoming on the unit.
xbeeps, if you want to include this code with VisualHeal, then by all means, go for it. As you will see, I borrowed heavily from your PitBull code.
I also have a Grid status indicator addon which works with HealComm-2.0, but it doesn't account for heal modifiers on targets. (I'm very glad to see that a get() method for heal modifiers was included in LibHealComm-3.0.) If there is interest, and xbeeps doesn't object, I would be happy to post a zip file with this code as well.
Would it not be possible to intercept CastComm data and simply make basic assumptions based on the data you get (as grid and sRaidFrames already does). That way you could get a lot more data from a lot more people, while not 100% accurate it would improve the adoption of your lib.
Very nice work i must say! :)
I'll include it right away. Regarding HealComm-2.0, i was hoping to phase that out completely, and quickly.
Very nice too :)
I'm afraid the lack of heal size is too limiting, and it means that each library instance (each client) needs to include "guessing code" for every healer class. Right now there is an accurate module for each healer class, and only the one that matches the player's class is loaded. I simply don't want to use guess-work for this as the heal sizes will be way off in most practical cases. Besides, it's not that hard to enforce certain mods in a guild, so if you want accurate heal synchronisation between healers, you'll need to make sure that all healers have LibHealComm-3.0 and some addon that can show the data it presents (VisualHeal).
I'm trying to convince other healers to use VH, but part of the difficulty is that these updates are only available on the forums. I assume this is because Ace3 is still in beta?
Yes, but I'll try to get VisualHeal transfered to trunk as soon as possible. If neccessary before Ace3 i released. I don't even know what the plan is for Ace3, but i read something about late christmas present, although noone said christmas this year or last year. LibHealComm-3.0 on the other hand does not have any external ties to Ace3 (LibStub and CallbackHandler are hard-embedded), so it wouldn't hurt to move it there soon.
Maybe Pastamancer doesn't want it for a good reason (I remember he had problems with HealComm-2), but I do think it makes sense to have as many addons as possible use the same heal comm library. So if anyone has some spare time, why not just branch Grid, replace CastComm by LibHealComm-3, get Pasta to take a look at it and then merge it with the trunk?
HealComm-2.0 was quite limited in functionality, mainly because there was only an event to signal the start of spell casting, so you'd have to use polling (in OnUpdate handler) to determine when the heal would stop, because Blizzard for some reason only generates the UNIT_SPELLCAST_STOP event sometimes for other players in the raid/party.
This is not the case for LibHealComm-3.0, where you have callbacks for all significant events (start, delayed, stop), so you only have to do updating when something actually happens asyncronously. Support for the missing spells that have multiple targets is also coming (just committed the framework for that, including full support for Binding Heal). Also, LibHealComm-3.0 is significantly slimmer and easier to integrate. Unlike HealComm-2.0, the only external dependencies are LibGratuity-3.0 and LibBabble-Spell-3.0 which themselves do not have any external dependencies. So you can say goodbye to AceEvent-2.0, AceLibrary, AceLocale-2.2, Babble-Spell-2.2, AceOO-2.0, Gratuity-2.0 and Roster-2.1.
Finally, I'm also investigating the feasibility of adding the ability to track HoT's so that LibHealComm-3.0 will be a complete heal tracking library. It's only possible to relibably track HoT's locally for your own HoT's so some communication is needed, and I think LibHealComm-3.0 is the appropriate place to put this functionality.
Thanks, I hope they become compatible soon.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI didn't want to encumber users with the additional overhead of a full-blown heal-tracking library. Neither squishy or detox had full heal-tracking, so I kept it out of Grid.
I looked through HealComm-3.0 in branches briefly and it doesn't seem to handle Prayer of Healing yet. Until HealComm-3.0 is finished, I don't think it should replace CastComm in Grid. Thanks for the information on cases that CastComm doesn't handle, I'll look into fixing that.
I do want to reduce the amount of addon channel spam that Grid/CastComm generates, and a healing-specific library to replace CastComm would certainly do that. Before I started on CastComm, I wrote //grid.13th-floor.org/svn/trunk/Healcomm/Healcomm.lua"" target="" data-ensure-absolute>this but got talked into a general-purpose cast library by JoshBorke.
CastComm is by nature/design significantly more chatty than LibHealComm-3.0:
1) LibHealComm-3.0 transmits two messages for each heal (start and stop) while LibCastComm transmits the individual events. For most spell casts there is no difference here though (the exception is when there are delays caused by damage).
2) LibHealComm-3.0 is only actively transmitting if the player is a healing class. This alone accounts for a reduction of ~50-70% (because only ~30% of your raid will be healers).
3) LibHealComm-3.0 only transmit if the spell being cast is a healing spell. All kinds of spells are transmittet with CastComm, including those non-heal spells cast by healers and non-healers alike (this is a very long list if you start counting!).
Agree, LibHealComm-3.0 is still in branches, and will remain there until:
1) It has support for Binding Heal and Prayer of Healing (and maybe Circle of Healing, but that may come free with support for Circle of Healing, only it might be impossible to determine the exact targets of the heal, just as is the case with Chain Heal)
2) I'm confident that the state-machine is robust, communication is error free, and the library is incapable of generating errors.
I'll be sure to let you know, when i move it to trunk.
If one uses Grid exclusively to heal, is there any point in trying VisualHeal right now, or should we just hold off until things settle down?