It takes less code than you would think, I wrote it all first before posting this so I was sure it would work. It's only ~100 lines and that's including comments/debug/etc. There is still a limit to how quickly the player can press a button and a successful cast triggers UNIT_SPELLCAST_SENT basically within the same frame update.
And what about Fel Armor, which is now acting like a HoT according to the combat log. It's possible for a player to log in already having this buff and your library would never hook a spell being cast for it.
And what about Fel Armor, which is now acting like a HoT according to the combat log. It's possible for a player to log in already having this buff and your library would never hook a spell being cast for it.
Is there anyone who happens to have a 80 Priest or 80 Shaman who wouldn't mind double checking some of the healing data in a day or two? I can make sure they don't have parse errors and get it relatively accurate from DrDamage, but someone who can verify that the averages are accurate would be helpful.
Nothing, I'm using the formulas and general information on talents/glyphs/etc from DrDamage since Gagorian doesn't mind me stealing them. So while I can get the info fairly accurate, it still needs a Priest and a Shaman to actually double check and make sure the numbers are sane.
I have both an 80 resto shaman and an 80 holy/disc priest - I haven't found the numbers I get from DrDamage to be off by much, at least not enough to matter in the world of 40k HP tanks and 20k HP clothies.
I've updated the first page with more information on comm format and events.
My reasoning on only passing endTime/targets instead of amount and such is I don't see it being necessary, people show it as overall healing whether on the person who is being healed or by the person healing. Since spellID is being sent it wouldn't be a big deal to also pass that, I just can't think of a practical use for it.
I have both an 80 resto shaman and an 80 holy/disc priest - I haven't found the numbers I get from DrDamage to be off by much, at least not enough to matter in the world of 40k HP tanks and 20k HP clothies.
Thanks, I should have something that could use testing by tomorrow or possibly night.
I have both an 80 resto shaman and an 80 holy/disc priest - I haven't found the numbers I get from DrDamage to be off by much, at least not enough to matter in the world of 40k HP tanks and 20k HP clothies.
Still need to do Shaman data but I got the Priest data in, can be downloaded: http://www.wowace.com/addons/libpendingheals-1-0/ all you need to do is cast a spell and check the heal it prints to the average in DrDamage (In the case of Penance the per-tick average) since it sounds like you have it already installed.
Was able to test on a 65 Priest and everything looks accurate, but Penance seems to be off by around 50-100 healing not too sure why.
I love the code innovation. SpellCast->GUID will be useful in other contexts.
There will be another library that will intercept healing data from LibHealComm-3.0 and convert it more to the LibPendingHeals-1.0 event format, it will not send healing data though. Basically, people who update to LibPendingHeals-1.0 will still get data from LibHealComm-3.0 and LibPendingHeals-1.0, but they will only send data out to other LibPendingHeals-1.0 users.
I don't love this though. Essentially you plan to parasite on LHC traffic for your benefit but give nothing in return... kinda lame attitude if you ask me.
Especially given, as Phanx has pointed out, it's hard to establish good interoperability in this area, and LHC is set up to be good about it.
No huge deal, certainly one can write yet another lib that creates the backchannel, but I don't know why there is any need for the uncooperative/unfriendly attitude.
I love the code innovation. SpellCast->GUID will be useful in other contexts.
I don't love this though. Essentially you plan to parasite on LHC traffic for your benefit but give nothing in return... kinda lame attitude if you ask me.
Especially given, as Phanx has pointed out, it's hard to establish good interoperability in this area, and LHC is set up to be good about it.
No huge deal, certainly one can write yet another lib that creates the backchannel, but I don't know why there is any need for the uncooperative/unfriendly attitude.
The goal of this is to replace LibHealComm-3.0, it's not meant as another healing comm library and ideally the wrapper library is temporary, meant so that users aren't left in the dark while the library spreads. In a perfect world it will become unnecessary at a certain point, that and I'm not a fan of sending two comm messages for each heal cast.
As I said a page or two ago, I'm more than willing to work with xbeeps on making this an ideal replacement and I've sent out messages to other authors using LibHealComm to get their opinions and suggestions on what they are looking for or want to see.
Well you have basically trashed xbeeps design to pieces. I certainly wouldn't read that as an invitations when his design ideas are dismissed without actually being heard (they were written down a few times). You didn't treat him as someone of a partner in getting a good design at all. Add that you essentially by fiat take the project lead. Would you want to cooperate under these circumstances? If you say that you invite xbeeps you basically decry how this as gone down so far.
That is quite silly because for practical purposes you offer a minor improvement.
As for listening to authors, here is what I say: guarantee interoperability. Phanx asked for it. I ask for it. But maybe you are not listening again.
The improvements you are offering with this lib are not great enough to disrupt good interoperability. There are cases when it's worth it to break it. But handling the rare hunter with the obsession on insisting a double named pets (and refusing the one-shot inscription solution) and the odd vehicle healing case is not it.
You want to take over LHC, that's what this boils down to and you give lip service of being cooperative and listening to peoples concerns. Unfortunately you are not.
Regardless of technical merits or "political" merits, here's how I view the situation as a user:
If I switch from LibHealComm to LibPendingHeals, I lose the ability to see others' heals, and they lose the ability to see my heals, until everyone else switches too. This is bad for everyone. Considering that, as I've said before, I still run into people who don't have LHC even though it's widely supported by a dozen popular addons, it's not realistic to expect everyone else to switch from LHC to LPH in a timely fashion.
If you include read-only compatibility (LPH reads comms from LHC but doesn't send comms that can be read by LHC), I can see others' heals, but they still can't see mine. This is directly bad for everyone else, and indirectly bad for me. Not only am I opposed on general principles to this sort of leeching, but it's frustrating for everyone involved when I'm about to land a 15k heal on a tank, but the other healers don't know that so they panic and spam emergency heals on the tank, wasting their mana and mine, and potentially risking the people they're supposed to be healing.
If I don't switch, but someone else does, then I'm once again unable to see their heals, though they may or may not be able to see mine. Considering how frustrating it is when I run into someone without LHC, this isn't a situation I'd like to see become more common.
Either way, someone is getting screwed, and while the myriad of small improvements sound cool on paper, they just don't add up to enough in practice to make it worth the hassle of trying to get the entire population of users who currently have LHC embedded to migrate to new versions or new addons that embed LPH instead. Most people I talk to couldn't tell you what a library was to save their lives, so arguments about code quality and technical merits are not compelling for them. Unless there is two-way interoperability, there's just no tangible incentive for users to switch, and I think most addon authors will probably stick with LHC simply to avoid the months of headaches such a change would cause.
Updated original post with some API changes and comm format changes after talking with Shefki. Changed it around a little too so it'll support heals with multiple values such as Healing Wave + Glyph of Healing Wave.
Since Blizzard is nice and doing premades and has a PTR up today, should be able to get the last Shaman and Priest formulas done and testing them further.
LPH shouldn't have to send out 2 comm messages per heal, a better solution imo would be to implement a wrapper library for LHC.
What do you mean? LHC doesn't have a any room to hide the extra data that would be needed unless you resort to hackery which could possibly break some addons that are using LHC.
commType,healSize,target1:target2:target3:etc
commType being a three digit long number and healSize being a number padded to 5 characters and capped at 99,999.
Internally it string.subs out commType and healSize expecting them both to be the exact length they are, for direct heals it will just pass target as is so there isn't room for hiding data there.
[edit] Looking at it again, I mean technically it could be done if I hid all of the data as a multi-target heal, but it wouldn't support Penance or any other channeled heal and it might not work due to some of the realm name conversions.
[edit2]
Looking through it closer, LHC is creating a new table each time it parses a temporary message, then it creates another table (if one doesn't exist) per target. It's not really feasible to hide data in there without creating possibly 1-10 new tables per a heal trying to hide GUID and heal amount data.
--
Elsia: You're welcome to keep making up my apparently nefarious motiviations though, perhaps you want to say I've kidnapped the girl and tied her to some train tracks as well or maybe I have a death ray pointed at France.
Phanx: I'm not really arguing code quality, although there are some parts that could be improved. You flat out will get more accurate healing data and the comm format (supposed) to reflect that. If Slakah has a good solution to it then it might solve the two way communication problem.
Elsia: You're welcome to keep making up my apparently nefarious motiviations though, perhaps you want to say I've kidnapped the girl and tied her to some train tracks as well or maybe I have a death ray pointed at France.
Dude, that's not how being inviting and cooperation works... But yeah let's safe that girl shall we, if that's the only thing you can say in response to concerns how this impacts the community.
You flat out will get more accurate healing data and the comm format (supposed) to reflect that. If Slakah has a good solution to it then it might solve the two way communication problem.
Well, again speaking from a user perspective, I've never had any problems with the accuracy of LibHealComm's estimates. If they're wrong, it's not by enough to matter in a world of constant incoming damage, instant heals, HoTs, Lightwells, potions, and health stones. So, "more accurate" is still not compelling enough to convince anyone I know of that it's worth the hassle.
If the comm problem can be solved in a way that doesn't require users to install a separate "LHC2LPH" addon, it may be a different story, but when most users have no idea how exactly they're able to see other people's heals on their raid frames and don't even know that LHC exists, unless the compatibility is built in, I stand by my arguments. :p
At some point in time the client calls TargetUnit, SpellTargetUnit, UseAction, CastSpellByID or CastSpellByName to cast a spell and because they are all protected you can rely on how and in what scenario they are called. By checking the units that are passed to them and replicating the default client method of falling back to the player when self cast is on, you can get the unit (and the GUID).
I think it will fail on macros. Does it work on [target=Xinhuan] macros where the player name is spelled out directly (many arena players use such macros)? Or target=unitIDs?
And then there's self-cast, focus-cast modifiers which might not be active. Say Alt is the self-cast modifier, and 4 is binded to HealA, hitting Alt+4 would self-cast HealA. But if Alt+4 is also separately binded to HealB, HealB wouldn't be considered a self-cast even though Alt is held down.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNot likely will, dealing with healing calculations is annoying enough without adding in formulas for healing through damage.
Casted hots not hots like Fel Armor.
:(
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMy reasoning on only passing endTime/targets instead of amount and such is I don't see it being necessary, people show it as overall healing whether on the person who is being healed or by the person healing. Since spellID is being sent it wouldn't be a big deal to also pass that, I just can't think of a practical use for it.
Thanks, I should have something that could use testing by tomorrow or possibly night.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumStill need to do Shaman data but I got the Priest data in, can be downloaded: http://www.wowace.com/addons/libpendingheals-1-0/ all you need to do is cast a spell and check the heal it prints to the average in DrDamage (In the case of Penance the per-tick average) since it sounds like you have it already installed.
Was able to test on a 65 Priest and everything looks accurate, but Penance seems to be off by around 50-100 healing not too sure why.
I don't love this though. Essentially you plan to parasite on LHC traffic for your benefit but give nothing in return... kinda lame attitude if you ask me.
Especially given, as Phanx has pointed out, it's hard to establish good interoperability in this area, and LHC is set up to be good about it.
No huge deal, certainly one can write yet another lib that creates the backchannel, but I don't know why there is any need for the uncooperative/unfriendly attitude.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe goal of this is to replace LibHealComm-3.0, it's not meant as another healing comm library and ideally the wrapper library is temporary, meant so that users aren't left in the dark while the library spreads. In a perfect world it will become unnecessary at a certain point, that and I'm not a fan of sending two comm messages for each heal cast.
As I said a page or two ago, I'm more than willing to work with xbeeps on making this an ideal replacement and I've sent out messages to other authors using LibHealComm to get their opinions and suggestions on what they are looking for or want to see.
That is quite silly because for practical purposes you offer a minor improvement.
As for listening to authors, here is what I say: guarantee interoperability. Phanx asked for it. I ask for it. But maybe you are not listening again.
The improvements you are offering with this lib are not great enough to disrupt good interoperability. There are cases when it's worth it to break it. But handling the rare hunter with the obsession on insisting a double named pets (and refusing the one-shot inscription solution) and the odd vehicle healing case is not it.
You want to take over LHC, that's what this boils down to and you give lip service of being cooperative and listening to peoples concerns. Unfortunately you are not.
If I switch from LibHealComm to LibPendingHeals, I lose the ability to see others' heals, and they lose the ability to see my heals, until everyone else switches too. This is bad for everyone. Considering that, as I've said before, I still run into people who don't have LHC even though it's widely supported by a dozen popular addons, it's not realistic to expect everyone else to switch from LHC to LPH in a timely fashion.
If you include read-only compatibility (LPH reads comms from LHC but doesn't send comms that can be read by LHC), I can see others' heals, but they still can't see mine. This is directly bad for everyone else, and indirectly bad for me. Not only am I opposed on general principles to this sort of leeching, but it's frustrating for everyone involved when I'm about to land a 15k heal on a tank, but the other healers don't know that so they panic and spam emergency heals on the tank, wasting their mana and mine, and potentially risking the people they're supposed to be healing.
If I don't switch, but someone else does, then I'm once again unable to see their heals, though they may or may not be able to see mine. Considering how frustrating it is when I run into someone without LHC, this isn't a situation I'd like to see become more common.
Either way, someone is getting screwed, and while the myriad of small improvements sound cool on paper, they just don't add up to enough in practice to make it worth the hassle of trying to get the entire population of users who currently have LHC embedded to migrate to new versions or new addons that embed LPH instead. Most people I talk to couldn't tell you what a library was to save their lives, so arguments about code quality and technical merits are not compelling for them. Unless there is two-way interoperability, there's just no tangible incentive for users to switch, and I think most addon authors will probably stick with LHC simply to avoid the months of headaches such a change would cause.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSince Blizzard is nice and doing premades and has a PTR up today, should be able to get the last Shaman and Priest formulas done and testing them further.
What do you mean? LHC doesn't have a any room to hide the extra data that would be needed unless you resort to hackery which could possibly break some addons that are using LHC.
commType,healSize,target1:target2:target3:etc
commType being a three digit long number and healSize being a number padded to 5 characters and capped at 99,999.
Internally it string.subs out commType and healSize expecting them both to be the exact length they are, for direct heals it will just pass target as is so there isn't room for hiding data there.
[edit] Looking at it again, I mean technically it could be done if I hid all of the data as a multi-target heal, but it wouldn't support Penance or any other channeled heal and it might not work due to some of the realm name conversions.
[edit2]
Looking through it closer, LHC is creating a new table each time it parses a temporary message, then it creates another table (if one doesn't exist) per target. It's not really feasible to hide data in there without creating possibly 1-10 new tables per a heal trying to hide GUID and heal amount data.
--
Elsia: You're welcome to keep making up my apparently nefarious motiviations though, perhaps you want to say I've kidnapped the girl and tied her to some train tracks as well or maybe I have a death ray pointed at France.
Phanx: I'm not really arguing code quality, although there are some parts that could be improved. You flat out will get more accurate healing data and the comm format (supposed) to reflect that. If Slakah has a good solution to it then it might solve the two way communication problem.
Dude, that's not how being inviting and cooperation works... But yeah let's safe that girl shall we, if that's the only thing you can say in response to concerns how this impacts the community.
Well, again speaking from a user perspective, I've never had any problems with the accuracy of LibHealComm's estimates. If they're wrong, it's not by enough to matter in a world of constant incoming damage, instant heals, HoTs, Lightwells, potions, and health stones. So, "more accurate" is still not compelling enough to convince anyone I know of that it's worth the hassle.
If the comm problem can be solved in a way that doesn't require users to install a separate "LHC2LPH" addon, it may be a different story, but when most users have no idea how exactly they're able to see other people's heals on their raid frames and don't even know that LHC exists, unless the compatibility is built in, I stand by my arguments. :p
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think it will fail on macros. Does it work on [target=Xinhuan] macros where the player name is spelled out directly (many arena players use such macros)? Or target=unitIDs?
And then there's self-cast, focus-cast modifiers which might not be active. Say Alt is the self-cast modifier, and 4 is binded to HealA, hitting Alt+4 would self-cast HealA. But if Alt+4 is also separately binded to HealB, HealB wouldn't be considered a self-cast even though Alt is held down.