I think 3 is adequate and appropriate. An addon like VisualHeal wouldn't even need polling, because it doesn't have a fixed size moving time frame (for example 3 seconds ahead). It always shows the healing incoming in a time frame that shrinks (extending between "now" and a fixed point in time in the future), so the amount incoming (in the time frame) only changes if new heals are started or existing heals are interrupted.
I think 3 is adequate and appropriate. An addon like VisualHeal wouldn't even need polling, because it doesn't have a fixed size moving time frame (for example 3 seconds ahead). It always shows the healing incoming in a time frame that shrinks (extending between "now" and a fixed point in time in the future), so the amount incoming (in the time frame) only changes if new heals are started or existing heals are interrupted.
Yea, I was going to do #3 but just realized it adds a bunch more extra work since you have to keep a list of frames that are LHC enabled, easier to force people to do a simple GetTime() throttle when the event fires rather than keeping track of enabled frames etc.
WoWAce seems to hate me and not noticing the publickey (or possibly macs do) so will commit later today, but all of the HoT managing code will be in, just need to start plugging in the formulas. After everything is tested and looks good I'll do a stable tag and it should be ready for stable use.
Wild Growth won't be supported with to start, it heals for relatively little and I need to work out how to handle it due to the fact that it heals differently each tick. Planned hots to support are Rejuvenation, Lifebloom, Riptide, Renew. Hots from casts like Regrowth, that Flash of Light + Sacred Shield thing and Earthliving will be added but they require more complex handling so I want the basic hots supported first.
Wild Growth won't be supported with to start, it heals for relatively little and I need to work out how to handle it due to the fact that it heals differently each tick.
I suppose the best way to temporary deal with it is to use the average heal tick for the time being.
Wouldn't the way to correctly deal with the mechanic be simular to how the lifebloom 'bloom' is done?
I was wondering are there any (long-term) plans to eventually support things like seed of life, trinket hots or disc shields? Or are those beyond the scope of this project?
The only trinket I can think of offhand that uses a HoT and would be used is Forethought Talisman, since it requires slightly different handling compared to normal hots (even the merged ones like Regrowth/Scared Shield + FOL) it's one of those "Maybe later, but not really a priority." At a certain point I don't want to be sending an absurd amount of data, nor do I want to bloat this since a lot of the code are things that are run often, supporting a single item that is a special case in both usage and handling isn't something I'm fond of doing.
I'm not familiar with Seed of Life, do you mean Living Seed? if you do, Living Seed wouldn't be supported since it's an on next attack thing not a direct absorb.
Absorbs are something I'm thinking about, but first I want to get all of the hots done and supported with, it mostly depends on Blizzard. It sounds like they are planning on adding support for seeing a shields absorbs so first I want to see how they are implementing that since I don't want a case where I get all of the shields working with LHC-4.0 and then they add an easy way of finding out.
Go double posts, however here is what needs to be done at this point:
Add Renew and Riptide should be done by Thursday. After that I need to check something on the PTR and I might have to change how a spells base healing is calculated due to tooltip changes, then Regrowth/Sacred Shield + FoL/Earthliving Weapon.
In a perfect world this will be done next Thursday and I can do another beta tag + get actual testing done, and after that it would be a stable tag and it would be ready for use in any addon.
I've just added LHC-4.0 support to my home-made oUF layout. It is easier to use than LHC-3.0 thanks to the GUID->unit map and the fact that :GetHealAmount returns players' heals.
However, using the latest alpha (r20090902235346), it seems my druid's HoTs are accounted only when cast on myself. They aren't accounted for other raid members. Cast or channeled spell are working properly.
I'm using a 3-second timeband and display is refreshed every 0.25 sec and on HealComm events, if that matters. (I was planning to use current spell casting to have a dynamic timeband, but I'm not sure it would be so useful).
BTW, granted I only want to display incoming heal and not actual ticks, should I register the HealComm_HealUpdated callback to update the display ?
Last but not least, it seems it ignores the HoT part of regrowth as well as the final tick of lifebloom but I think you already are aware of this.
It looks like I'll have to play around with the method of detecting duration left for hots the player casts on others, but I'll get that hot bug fixed.
What do you mean by you only want to show incoming heal and not actual ticks, you don't want to see hots in the incoming heal number? Just HealComm_HealUpdated should be fine you shouldn't need to do a 0.25s poll.
Regrowth HoT not being factored is something I'll work on later today, but I'm still debating how I want to handle Lifebloom bloom.
What do you mean by you only want to show incoming heal and not actual ticks, you don't want to see hots in the incoming heal number ? Just HealComm_HealUpdated should be fine you shouldn't need to do a 0.25s poll.
I did not see the part about application count changes and the like in the API. Moreover when a tick just happened there is a need to account for new ticks. So I'll continue listen for that event.
Actually I'm using oUF health ".frequentUpdates" feature that check for changes every 0.25s and update display if need be, instead of waiting for UNIT_HEALTH. And every time the health change, I have to refresh incoming heal.
The only trinket I can think of offhand that uses a HoT and would be used is Forethought Talisman, since it requires slightly different handling compared to normal hots (even the merged ones like Regrowth/Scared Shield + FOL) it's one of those "Maybe later, but not really a priority." At a certain point I don't want to be sending an absurd amount of data, nor do I want to bloat this since a lot of the code are things that are run often, supporting a single item that is a special case in both usage and handling isn't something I'm fond of doing.
Being relatively new to healing in wow I didn't stop to think this item is such a rare occurrence as it is. I've got to admit to being rather naive to this and the lib's inner workings as I'd imagined it just being another spell_id you could add to the generic hot list that would be monitored. :-[
I'm not familiar with Seed of Life, do you mean Living Seed? if you do, Living Seed wouldn't be supported since it's an on next attack thing not a direct absorb.
Yes, again I'm sorry, I do get this talent name wrong allot.
Again I'd imagined it as being handled as a simple incoming heal with a 15 second cast time that would land the moment the buff disappears on the target.
Absorbs are something I'm thinking about, but first I want to get all of the hots done and supported with, it mostly depends on Blizzard. It sounds like they are planning on adding support for seeing a shields absorbs so first I want to see how they are implementing that since I don't want a case where I get all of the shields working with LHC-4.0 and then they add an easy way of finding out.
Good to hear, again I was just wondering about the intended scope of this project.
I did some experimenting with the current version of SUF on GitHub.
Lifebloom and Rejuv show up very nicely and I'm finally able to get a good feel how much these spells actually heal for.
I've set the INCOMING_SECONDS to 40 as I'm interested if my current hots will put someone at 100% or not. (I imagine this has limited practical purpose for most people but I do appreciate this information very much)
What I noticed in my tests is that the predicted heal is slightly out of sync at the moment. When my LB or Rejuv ticks for the first time the estimated heal drops down 2 ticks (ie. my health increases by 1 tick, the incoming total hot drops by 2). The tick before the last hot tick corrects this as the incoming heal drops to 0 then quickly increases to 1 tick remaining. Notice that this is 'not' in any way related to the lifebloom final bloom.
I hope this helps in some way.
I did not see the part about application count changes and the like in the API. Moreover when a tick just happened there is a need to account for new ticks. So I'll continue listen for that event.
Actually I'm using oUF health ".frequentUpdates" feature that check for changes every 0.25s and update display if need be, instead of waiting for UNIT_HEALTH. And every time the health change, I have to refresh incoming heal.
If you're already listening for frequent updates, then it's not as big of a deal. Although I'm not sure how well the API call itself performs when called every 0.25s.
Being relatively new to healing in wow I didn't stop to think this item is such a rare occurrence as it is. I've got to admit to being rather naive to this and the lib's inner workings as I'd imagined it just being another spell_id you could add to the generic hot list that would be monitored. :-[
Yes, again I'm sorry, I do get this talent name wrong allot.
Again I'd imagined it as being handled as a simple incoming heal with a 15 second cast time that would land the moment the buff disappears on the target.
Good to hear, again I was just wondering about the intended scope of this project.
I did some experimenting with the current version of SUF on GitHub.
Lifebloom and Rejuv show up very nicely and I'm finally able to get a good feel how much these spells actually heal for.
I've set the INCOMING_SECONDS to 40 as I'm interested if my current hots will put someone at 100% or not. (I imagine this has limited practical purpose for most people but I do appreciate this information very much)
What I noticed in my tests is that the predicted heal is slightly out of sync at the moment. When my LB or Rejuv ticks for the first time the estimated heal drops down 2 ticks (ie. my health increases by 1 tick, the incoming total hot drops by 2). The tick before the last hot tick corrects this as the incoming heal drops to 0 then quickly increases to 1 tick remaining. Notice that this is 'not' in any way related to the lifebloom final bloom.
I hope this helps in some way.
After thinking about it I might just change the hot system to be fully based on aura gains rather than spell cast in the combat log, so it would be as easy as that but not sure if I want to see the trinket in, will think about it some more.
Living Seed works a little bit differently from what you're thinking, it lasts 15 seconds but it blooms when the player is next attacked they could be attacked in 1s or in 10s or not at all which is what makes it hard to add.
I'm still playing with the code for figuring out how many times a HoT/Channel will tick in the given time band, but if you set it to 40 seconds it might be an issue in how I'm showing the total ticks when the band is outside the HoT duration, I'll look into this.
If you're already listening for frequent updates, then it's not as big of a deal. Although I'm not sure how well the API call itself performs when called every 0.25s.
As I said, it should not be called every 0.25s unless the unit health varies a lot, which is likely to happen to tanks but not to the whole raid, IMO.
Living Seed works a little bit differently from what you're thinking, it lasts 15 seconds but it blooms when the player is next attacked they could be attacked in 1s or in 10s or not at all which is what makes it hard to add.
I understood the mechanics but I admit I didn't really think about the implications. I always compared it to someone casting a heal that could land any second (the moment the target is hit) and be canceled after 15 seconds.
Technical implementation aside it is not very useful showing an incoming heal that is 'always' accompanied by a random amount of damage.
Regardless please forgive my rambling.
I'm still playing with the code for figuring out how many times a HoT/Channel will tick in the given time band, but if you set it to 40 seconds it might be an issue in how I'm showing the total ticks when the band is outside the HoT duration, I'll look into this.
I'm specifically interested in all the incomming heals that the lib knows about. Is simply strenching the band beyond the max hot duration, like I did the correct way or is there another way or is this generally not supported?
Normally you would just pass nil as the band and it would get any incoming heal regardless of when it lands, but in your case and in real use it's possible to set a band that extends past when any heals are incoming. So while how you were trying to do it specifically isn't really intended, it's still a bug that it broke that way and it's fixed.
Some comm things I am going to go to support the remaining heal types:
For hots with a "bomb heal" component like Lifebloom, the end time of the bomb would be determined by when the hot ends, It'll use a new bit type called BOMB_HEALS as well.
If a special amount is passed per target then target1,target2,etc would turn into target1,amount1@amount2,target2,amount1@amount2 with amount being in order of left -> right how much it would tick for each time.
How do one use this instead of LibHealComm-3? Do the author of an addon has to support this in their addon to be able to use this?
The addon author has to plug LHC4 in his/her addon in place of LHC3. It requires a bit of work but given that LHC4 is easier to use, this is not that much work.
Edit: @Shadowed:
- do not forget that Lifebloom also heals when it is dispelled. Even it is unpredictable, you might want to do something of it (though it can't figure what :p).
- Nourish seems ignored with minor 8. I'll test the latest version later to verify hots and this.
Edit2: minor 11 fixes the HoT issue but still ignores Nourish.
[2009/09/04 11:25:07-6964-x6]: LibHealComm-4.0-11 (LibHealComm-4.0):59: bad argument #8 to 'format' (number expected, got no value)
LibHealComm-4.0-11 (LibHealComm-4.0):59: in function <Interface\AddOns\LibHealComm-4.0\LibHealComm-4.0.lua:56>
LibHealComm-4.0-11 (LibHealComm-4.0):1469: in function <Interface\AddOns\LibHealComm-4.0\LibHealComm-4.0.lua:1467>
LibHealComm-4.0-11 (LibHealComm-4.0):1494: in function <Interface\AddOns\LibHealComm-4.0\LibHealComm-4.0.lua:1487>
LibHealComm-4.0-11 (LibHealComm-4.0):1806: in function `?'
LibHealComm-4.0-11 (LibHealComm-4.0):2318: in function <Interface\AddOns\LibHealComm-4.0\LibHealComm-4.0.lua:2314>
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYea, I was going to do #3 but just realized it adds a bunch more extra work since you have to keep a list of frames that are LHC enabled, easier to force people to do a simple GetTime() throttle when the event fires rather than keeping track of enabled frames etc.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWild Growth won't be supported with to start, it heals for relatively little and I need to work out how to handle it due to the fact that it heals differently each tick. Planned hots to support are Rejuvenation, Lifebloom, Riptide, Renew. Hots from casts like Regrowth, that Flash of Light + Sacred Shield thing and Earthliving will be added but they require more complex handling so I want the basic hots supported first.
I suppose the best way to temporary deal with it is to use the average heal tick for the time being.
Wouldn't the way to correctly deal with the mechanic be simular to how the lifebloom 'bloom' is done?
I was wondering are there any (long-term) plans to eventually support things like seed of life, trinket hots or disc shields? Or are those beyond the scope of this project?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm not familiar with Seed of Life, do you mean Living Seed? if you do, Living Seed wouldn't be supported since it's an on next attack thing not a direct absorb.
Absorbs are something I'm thinking about, but first I want to get all of the hots done and supported with, it mostly depends on Blizzard. It sounds like they are planning on adding support for seeing a shields absorbs so first I want to see how they are implementing that since I don't want a case where I get all of the shields working with LHC-4.0 and then they add an easy way of finding out.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAdd Renew and Riptide should be done by Thursday. After that I need to check something on the PTR and I might have to change how a spells base healing is calculated due to tooltip changes, then Regrowth/Sacred Shield + FoL/Earthliving Weapon.
In a perfect world this will be done next Thursday and I can do another beta tag + get actual testing done, and after that it would be a stable tag and it would be ready for use in any addon.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHowever, using the latest alpha (r20090902235346), it seems my druid's HoTs are accounted only when cast on myself. They aren't accounted for other raid members. Cast or channeled spell are working properly.
I'm using a 3-second timeband and display is refreshed every 0.25 sec and on HealComm events, if that matters. (I was planning to use current spell casting to have a dynamic timeband, but I'm not sure it would be so useful).
BTW, granted I only want to display incoming heal and not actual ticks, should I register the HealComm_HealUpdated callback to update the display ?
Last but not least, it seems it ignores the HoT part of regrowth as well as the final tick of lifebloom but I think you already are aware of this.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat do you mean by you only want to show incoming heal and not actual ticks, you don't want to see hots in the incoming heal number? Just HealComm_HealUpdated should be fine you shouldn't need to do a 0.25s poll.
Regrowth HoT not being factored is something I'll work on later today, but I'm still debating how I want to handle Lifebloom bloom.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI did not see the part about application count changes and the like in the API. Moreover when a tick just happened there is a need to account for new ticks. So I'll continue listen for that event.
Actually I'm using oUF health ".frequentUpdates" feature that check for changes every 0.25s and update display if need be, instead of waiting for UNIT_HEALTH. And every time the health change, I have to refresh incoming heal.
Being relatively new to healing in wow I didn't stop to think this item is such a rare occurrence as it is. I've got to admit to being rather naive to this and the lib's inner workings as I'd imagined it just being another spell_id you could add to the generic hot list that would be monitored. :-[
Yes, again I'm sorry, I do get this talent name wrong allot.
Again I'd imagined it as being handled as a simple incoming heal with a 15 second cast time that would land the moment the buff disappears on the target.
Good to hear, again I was just wondering about the intended scope of this project.
I did some experimenting with the current version of SUF on GitHub.
Lifebloom and Rejuv show up very nicely and I'm finally able to get a good feel how much these spells actually heal for.
I've set the INCOMING_SECONDS to 40 as I'm interested if my current hots will put someone at 100% or not. (I imagine this has limited practical purpose for most people but I do appreciate this information very much)
What I noticed in my tests is that the predicted heal is slightly out of sync at the moment. When my LB or Rejuv ticks for the first time the estimated heal drops down 2 ticks (ie. my health increases by 1 tick, the incoming total hot drops by 2). The tick before the last hot tick corrects this as the incoming heal drops to 0 then quickly increases to 1 tick remaining. Notice that this is 'not' in any way related to the lifebloom final bloom.
I hope this helps in some way.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf you're already listening for frequent updates, then it's not as big of a deal. Although I'm not sure how well the API call itself performs when called every 0.25s.
After thinking about it I might just change the hot system to be fully based on aura gains rather than spell cast in the combat log, so it would be as easy as that but not sure if I want to see the trinket in, will think about it some more.
Living Seed works a little bit differently from what you're thinking, it lasts 15 seconds but it blooms when the player is next attacked they could be attacked in 1s or in 10s or not at all which is what makes it hard to add.
I'm still playing with the code for figuring out how many times a HoT/Channel will tick in the given time band, but if you set it to 40 seconds it might be an issue in how I'm showing the total ticks when the band is outside the HoT duration, I'll look into this.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAs I said, it should not be called every 0.25s unless the unit health varies a lot, which is likely to happen to tanks but not to the whole raid, IMO.
I understood the mechanics but I admit I didn't really think about the implications. I always compared it to someone casting a heal that could land any second (the moment the target is hit) and be canceled after 15 seconds.
Technical implementation aside it is not very useful showing an incoming heal that is 'always' accompanied by a random amount of damage.
Regardless please forgive my rambling.
I'm specifically interested in all the incomming heals that the lib knows about. Is simply strenching the band beyond the max hot duration, like I did the correct way or is there another way or is this generally not supported?
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFor hots with a "bomb heal" component like Lifebloom, the end time of the bomb would be determined by when the hot ends, It'll use a new bit type called BOMB_HEALS as well.
B:<extra>:<spellID>:<bombAmount>@target1,target2,etc:<amount>:<isMulti>:<tickInterval>:target1,target2,etc
I'm not sure how I want to do Wild Growth still, but I am thinking of this:
M:<extra>:<spellID>:amount1@amount2@amount3:<isMulti>:<tickInterval>:target1,target2,etc
If a special amount is passed per target then target1,target2,etc would turn into target1,amount1@amount2,target2,amount1@amount2 with amount being in order of left -> right how much it would tick for each time.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe addon author has to plug LHC4 in his/her addon in place of LHC3. It requires a bit of work but given that LHC4 is easier to use, this is not that much work.
Edit: @Shadowed:
- do not forget that Lifebloom also heals when it is dispelled. Even it is unpredictable, you might want to do something of it (though it can't figure what :p).
- Nourish seems ignored with minor 8. I'll test the latest version later to verify hots and this.
Edit2: minor 11 fixes the HoT issue but still ignores Nourish.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium