- 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.
While the bloom is an unpredictable (early) heal that you probably won't see coming (depending on your time band). The hot portion that is dispelled is the unpredictable (early) 'loss' of a heal that you 'did' see coming. In other words the bloom heals more (earlier) than is indicated but the dispelled hot heals less than is indicated. Which makes it overall less of a problem. I think it really depends on the situation tho if you want to display these 'possible' (early) heals. -If you are trying to conserve mana you want to know about every possible heal effect so in the case they all land you don't cast any unnecessary heals. -If you are trying to make sure your target always stays alive (or topped up) you don't want to know about heals that 'might' not land in time (or at all).
The bloom might be unpredicted, but casts in general are unpredictable as since they can be interrupted or stopped I'd say that hots are more reliable than casts generally. Either way, it's considered a BOMB_HEALS bitType so if someone doesn't want to include it they can just use custom filtering.
[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>
I'm still not sure what's causing that error as it seems to be rare, all the GUIDs are compressed as far as I can tell. Try the version I just pushed to wowace, it will print out the compressed form of the GUID when it errors, might just be a bug in the compression code in general.
What do you mean by Nourish is ignored? Did a quick test and it looks to be working fine and it's taking total hots into account too.
Alright so just a little bit of an expansion on what needs to happen at this point:
1) Move everything to an internal database for calculating the base healing of a spell, this is for both 3.2.2 and dual purpose spells, should be done by next week or sooner.
2) Add Lifebloom bloom and Regrowth hot, done about the same time as #1
3) Quadruple check that the comm code is solid
5) Work on supporting Wild Growth and Prayer of Healing hots
4) Tag as beta
6) Tag as stable (After enough testing that I'm confident it won't break horribly, especially the comm.
About HoTs, all buffs are removed when entering/leaving arenas. I had stuck incoming HoTs that started before entering the arena and never stopped, until I cast the same HoT again (which triggered both start and stop). You might need to verify pending HoTs on P_E_W.
They are also removed when changing specs i think, at least some of them.
(When i change between retribution &heal,or between pve&pvp spec, my shields and blessings vanish.
Leaving an arena and respeccing fire the appropriate fade events, they don't need any special report. I changed it so on major zone type change it will wipe all pending heals and when leaving a group it wipes all pending heals except the ones the player casted on themselves and fires the necessary HealComm_HealStopped events with the interrupted flag as true.
Great work Shadowed. It still has everything I need for HealInc, and seems to do the calculations a lot cleaner.
For HealInc I'm building a table of all individual incomming heals on a target based on the events. The API is still missing such a function. But I gues it's easy enough to make to keep outside of the library.
I was wondering if you are planning on building in a version check for group members.
My bet is about protocol changes, ignoring the comms of outdated versions can save you more headaches than you would have by using their innacurate information
If you wanted to find out who has what, I would just keep a map of the GUIDs that fired the HealComm_HealStarted or watch CHAT_MSG_ADDON and create the map based off anyone who used the LHC40 prefix and label it as known LHC40 users. One fight will give you an accurate idea of which healers are using LHC. It's not really something I am going to add just for that though.
Not so much the exact version I find useful in the version check. But checking whether a healer has LHC installed.
Yes, whoever is sending [LHC40] as prefix is probably running it.(why should you fake it? ;) )
Catching lhc-commdata could be done within your addon or with the old fubar addon addonspamfu.
See latest version for more debug code, I added a local map so if fails to decompress a GUID it will (try to at least) output the original GUID, I'm starting to wonder if it might be a weird issue with NPCs or something along those lines.
Actually nevermind, the GUID issue should be fixed. Next push is going to have pretty much everything in it, I'm holding back on Wild Growth for the time being as I want to play around with it more still. Will give the version I commit a day or two to make sure there are no obvious bugs then will do a beta tag.
I`m using Grid 1 with libhealcomm-3.0, can I just install the wrapper +libhealcomm-4.0 to get more accurate incoming heal results? Or installing it will do nothing? Do other users need the 4.0 lib to work?
FuBar_AddonSpamFu also shows that 4.0 is sending 300% more data that 3.0 to whole guild.
Is there any option only to communicate only to teh raid/party ?
I`m using Grid 1 with libhealcomm-3.0, can I just install the wrapper +libhealcomm-4.0 to get more accurate incoming heal results? Or installing it will do nothing? Do other users need the 4.0 lib to work?
FuBar_AddonSpamFu also shows that 4.0 is sending 300% more data that 3.0 to whole guild.
Is there any option only to communicate only to teh raid/party ?
Sorry for my poor english.
No, the addon has to be specifically updated to use LHC-4.0 the wrapper is just a means of keeping LHC-3.0 data from being "lost" while upgrading it is not a means of making an addon that only uses LHC-3.0 work with the new LHC-4.0 data.
I don't know how AddonSpamFu is getting its numbers, but LHC-4.0 doesn't have any code to send to GUILD at all so I'm doubtful that it's actually LHC-4.0 that is sending the data to the GUILD.
Provided you have LHC-4.0 compatible unit frames, others need to install LHC-4.0 for you to receive accurate data. If they only have LHC-3.0, the LHC wrapper will convert LHC-3.0 data you receive to LHC-4.0 (so your LHC-4.0 compatible addons shows LHC-3.0 data), though you won't see more things than LHC-3.0 provides.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I'm still not sure what's causing that error as it seems to be rare, all the GUIDs are compressed as far as I can tell. Try the version I just pushed to wowace, it will print out the compressed form of the GUID when it errors, might just be a bug in the compression code in general.
What do you mean by Nourish is ignored? Did a quick test and it looks to be working fine and it's taking total hots into account too.
1) Move everything to an internal database for calculating the base healing of a spell, this is for both 3.2.2 and dual purpose spells, should be done by next week or sooner.
2) Add Lifebloom bloom and Regrowth hot, done about the same time as #1
3) Quadruple check that the comm code is solid
5) Work on supporting Wild Growth and Prayer of Healing hots
4) Tag as beta
6) Tag as stable (After enough testing that I'm confident it won't break horribly, especially the comm.
After I fixed my callback arguments, everything is working as expected.
(When i change between retribution &heal,or between pve&pvp spec, my shields and blessings vanish.
For HealInc I'm building a table of all individual incomming heals on a target based on the events. The API is still missing such a function. But I gues it's easy enough to make to keep outside of the library.
I was wondering if you are planning on building in a version check for group members.
There is no plans on adding version checking, if it becomes absolutely necessary later on I will.
You're right. I would need a function like that. Because your events unlike LHC-3.0 do not give the healSize.
Not so much the exact version I find useful in the version check. But checking whether a healer has LHC installed.
Yes, whoever is sending [LHC40] as prefix is probably running it.(why should you fake it? ;) )
Catching lhc-commdata could be done within your addon or with the old fubar addon addonspamfu.
FuBar_AddonSpamFu also shows that 4.0 is sending 300% more data that 3.0 to whole guild.
Is there any option only to communicate only to teh raid/party ?
Sorry for my poor english.
No, the addon has to be specifically updated to use LHC-4.0 the wrapper is just a means of keeping LHC-3.0 data from being "lost" while upgrading it is not a means of making an addon that only uses LHC-3.0 work with the new LHC-4.0 data.
I don't know how AddonSpamFu is getting its numbers, but LHC-4.0 doesn't have any code to send to GUILD at all so I'm doubtful that it's actually LHC-4.0 that is sending the data to the GUILD.
No, Grid authors have to upgrade Grid to use LHC-4.0 instead of LHC-3.0.
Nothing visible. You will be sending LHC-4.0 data though.
Provided you have LHC-4.0 compatible unit frames, others need to install LHC-4.0 for you to receive accurate data. If they only have LHC-3.0, the LHC wrapper will convert LHC-3.0 data you receive to LHC-4.0 (so your LHC-4.0 compatible addons shows LHC-3.0 data), though you won't see more things than LHC-3.0 provides.