Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
Main goal of this is to improve the accuracy of incoming heal data, instead of using names it will use GUIDs and instead of using UNIT_AURA for calculating healing modifiers it will use spellIDs through CLEU mainly. The API will also be simpler to reflect how people use it overall.
Why name this library IncomingHeals? It seems to be as much about outgoing heals as it is about incoming ones. I would understand if this library only predicted incoming heals for the player, and possibly the player's pet or vehicle, but it seems to account for heals "incoming" to other units as well. From whose perspective are these heals "incoming"? From reading some of your other goals, it seems more like you are trying to predict future heal amounts on all targets from all sources within a configurable timeframe. It might be more honest to call such an addon PredictedHeals or EstimatedHealsInTheNextTwoSeconds if that is its true purpose.
Why would this library provide inherently more accurate results than other existing options? Is it possible for a player being targeted by a heal to have a more accurate estimate of the amount of that heal than the caster could provide?
What improvement is realized from using GUIDs rather than names? If this is a limitation in another otherwise functional library, perhaps it could be incorporated as an enhancement to that library.
Which event accounts for heals that do not finish casting due to interruption?
Will this library communicate with other users of the library to improve its predictive power?
Why name this library IncomingHeals? It seems to be as much about outgoing heals as it is about incoming ones. I would understand if this library only predicted incoming heals for the player, and possibly the player's pet or vehicle, but it seems to account for heals "incoming" to other units as well. From whose perspective are these heals "incoming"? From reading some of your other goals, it seems more like you are trying to predict future heal amounts on all targets from all sources within a configurable timeframe. It might be more honest to call such an addon PredictedHeals or EstimatedHealsInTheNextTwoSeconds if that is its true purpose.
Why would this library provide inherently more accurate results than other existing options? Is it possible for a player being targeted by a heal to have a more accurate estimate of the amount of that heal than the caster could provide?
What improvement is realized from using GUIDs rather than names? If this is a limitation in another otherwise functional library, perhaps it could be incorporated as an enhancement to that library.
Which event accounts for heals that do not finish casting due to interruption?
Will this library communicate with other users of the library to improve its predictive power?
1) It's a quick name I chose randomly mostly, LibHeals or something along those lines would be better.
2) There are a few spells like Unrelenting Assault or Necrotic Poison that monitoring by spellID is the only way to get accurate modifier data. I know LHC is missing Natural Shapeshifter but haven't started going through class spells yet, shapeshifter was just something I saw at a glance.
3) Not really, the comm would have to be redone to either send out legacy messages and new ones or it would have to move purely to the new ones and if it's the latter that means a major bump.
Names aren't accurate they are relatively accurate but things like pets with the same name or vehicles with the same name you have no way of really saying which is which without a GUID.
4) HealStopped, I could add a flag to it that indicates the spell was successful vs stopped earlier although I'm not sure why you would need that kind of info.
5) As #1 says, the name is a bit misleading. Healers send out the comm data and other users read it, as nice as it would be to have one person figure out what heals they are getting it's not really possible.
Are the Started, Delayed, and Stopped events meant to be correlated with each other? If so, how will this be managed? It seems like only the Started event contains the amount of a heal, while it might be important to know during the Delayed and Stopped events, as well.
Are the Started, Delayed, and Stopped events meant to be correlated with each other? If so, how will this be managed? It seems like only the Started event contains the amount of a heal, while it might be important to know during the Delayed and Stopped events, as well.
They're mainly meant to tell the mod that the total amount of healing incoming on someone has changed, the end time and guid are there so you can specifically look at how much healing is incoming within the time the user is casting a spell.
The delayed and stopped events don't need the amount because you don't use the amount value for calculating the total amount of healing incoming on a person. Only time you'd really use I can think of is if you want to see what healer is doing what, but you don't need the amount in Delayed and Stopped because you're not subtracting the amount from any grand total.
While your improvements over LHC sound neat, I just don't see a new healing comm library being very useful. It took forever to get widespread support for LHC, and I still run into people who don't have it. Even if I run the shiny new thing, it doesn't really do anything useful unless everyone else I'm playing with (or at least a strong majority of them) are also running it. :|
Generally I'd agree with you, but this is the kind of thing that simply won't work without widespread support from raid/unit frame addons. Remember how long it took to get the Healbot guys to support LHC? Imagine how long it would take to convince them to add support for a second healing comm lib. :p
Not to mention even if you get them to support it, many users tend not to update their addons unless they are totally broken. :/ Adding HOTs to HealComm as optional may work - although even as a resto druid I am not sure I would want that -, changing the whole thing to GUIDs from names is a different story.
yea, nailertn is right. I sometimes meet people which still have threat-2.0 on their computers ;)
In the programming world sometimes people arent happy about the software , forge it, develop it further and it gets merged back into the source-tree once they have proven , that the code is good.
yea, nailertn is right. I sometimes meet people which still have threat-2.0 on their computers ;)
In the programming world sometimes people arent happy about the software , forge it, develop it further and it gets merged back into the source-tree once they have proven , that the code is good.
This isn't really something that's going to get merged into LHC, it breaks compatibility either way and it rewrites too much of the code.
Generally I'd agree with you, but this is the kind of thing that simply won't work without widespread support from raid/unit frame addons. Remember how long it took to get the Healbot guys to support LHC? Imagine how long it would take to convince them to add support for a second healing comm lib. :p
The point is it's not adding a second healing comm library, it's replacing it with a better one more towards how people actually use it. Sure it's not going to be used by everyone overnight, but it also means you are forced into using one.
Would have been a bit better if I had done this in before 3.2 since a lot of people updated, but oh wel.
Competition is usually a good thing for business, but sometimes, collaboration would have been a better thing. For example, the Blu-Ray vs. HD-DVD question led to widespread consumer confusion, slow adoption of either technology, and near total obsolescence of one segment of the consumer population's hardware investment.
A few studies have been done attempting to predict how the consumer market would have reacted to a single standardized upgrade path to DVD, and each of them predicts higher profit for the companies involved and faster consumer adption rates. Together, they would only have had to market themselves as an upgrade to DVD, not as being an upgrade to DVD and being marginally better than the other competing format.
You anticipate that addons that utilize the current de facto library will replace it immediately, abandoning support for the old library entirely. For quite some period of time, probably months, this will lead to players having less information than they have now. What good is it if players have some information that is 25% more accurate, but have 50% less information overall?
I predict that a "planned obsolescence with no compatible upgrade path" will result in significant near-term disruption and confusion to players. I am not yet convinced that the touted benefits would outweigh this cost.
Are you certain there is no collaborative alternative to pursue?
Given that xbeeps refuses to even consider that his version code is flawed, it's doubtful that collaboration on something that requires rewriting most of the code and changes the API isn't going to go much better :p.
I never said that it's going to be replaced immediately, but again if nothing is done then there is never a replacement and it never gets better.
You can't use an example like HD-DVD and Blu-Ray, they cost consumers money in both having to buy disks specific to one format but they also had to buy hardware that can only play that specific format. In this case, the consumer isn't spending their money on it, it's purely on the authors and swapping API's isn't that complicated depending on what they use LHC for.
When you get down to it it's simple, there is no way you can use GUIDs and the LibHealComm format which is built on names. Any transition to GUIDs requires a new comm format and new callbacks or else you break backwards compatibility, as it's a library you would do a major bump. The only solution is either not use GUIDs or write a wrapper that does it's "best guess" to translate names to GUID and at least receive HealComm data. That's not my priority right now, I might look into it later but I'd rather get this working first.
My point was not that players will have to spend money, it's that they will still have to upgrade. During this period, everyone will suffer from having less information until the very last player completes the upgrade.
If your primary goal (at least the primary goal visible to end-users) with this library is to provide players with more accurate data, I strongly feel you would be working against this goal by not providing a compatible upgrade path. This might require extra work on your part. Are you willing to do that work to improve the players' experience?
Trying to introduce something like this, even if it's an awesome improvement, is going to be a nightmare. You've got a large install base of addons out there using LHC, and some of them are widely used but not actively maintained. The best result you could thus attain from promoting LIH uptake is that the significant number of people who will continue to use LHC addons will not be sharing any cast info with people using LIH addons and vice-versa, which will make them both worse off than if they both just continue to use the "suboptimal" LHC.
The question is thus: "Is no data at all better than bad data?" Don't think that pushing it in your own unit frame addon is enough either; even ckknight doesn't have the kind of weight to make that a feasible method of pressuring other unit frame addon authors into switching libraries :p You'll just end up turning away prospective users of your unit frame addon who care about LHC compatibility.
My point was not that players will have to spend money, it's that they will still have to upgrade. During this period, everyone will suffer from having less information until the very last player completes the upgrade.
If your primary goal (at least the primary goal visible to end-users) with this library is to provide players with more accurate data, I strongly feel you would be working against this goal by not providing a compatible upgrade path. This might require extra work on your part. Are you willing to do that work to improve the players' experience?
If you have a suggestion I'm more than willing to listen, but the only way you can maintain compatibility with HealComm and IncomingHeals for sending healing data is to send out data twice for each library the HealComm format will flat out not work with GUIDs and does not have any room to hide a GUID in unless you go with hackery and that would be more likely to cause compatibility problems.
Writing a wrapper to receive heals sent from HealComm wouldn't be that difficult, sending data is where it becomes a pain.
Just to be clear, I'm doing this project either way as something interesting to do it's just a question of how useful it is to others.
[edit saw HunterZ's edit]
I already talked to Shefki and he's interested providing the API and library is better, writing a patch to do it for oUF and PerfectRaid are easy enough (as I did the original HealComm one for PR anyway) and once I have something more solid I'll talk to other unit frame authors.
Just keep in mind that whatever you decide to name this library, the way it will be implemented makes it effectively "LibHealComm-4.0", whether you call it that or not. (That is, if the library is adopted by authors the way you foresee it will be.)
I imagine players would be extremely grateful if you went the extra mile and smoothed out the upgrade path for them, even if it requires some hard work and hackery on your part.
As a smart player, I would refuse to upgrade my unitframe addon to one that supports the new library (and ignores the old one) until at least 50% of other players had already done so.
That's going to require an adventurous initial 50% who are willing to take that first step.
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 Premium.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium1) It's a quick name I chose randomly mostly, LibHeals or something along those lines would be better.
2) There are a few spells like Unrelenting Assault or Necrotic Poison that monitoring by spellID is the only way to get accurate modifier data. I know LHC is missing Natural Shapeshifter but haven't started going through class spells yet, shapeshifter was just something I saw at a glance.
3) Not really, the comm would have to be redone to either send out legacy messages and new ones or it would have to move purely to the new ones and if it's the latter that means a major bump.
Names aren't accurate they are relatively accurate but things like pets with the same name or vehicles with the same name you have no way of really saying which is which without a GUID.
4) HealStopped, I could add a flag to it that indicates the spell was successful vs stopped earlier although I'm not sure why you would need that kind of info.
5) As #1 says, the name is a bit misleading. Healers send out the comm data and other users read it, as nice as it would be to have one person figure out what heals they are getting it's not really possible.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThey're mainly meant to tell the mod that the total amount of healing incoming on someone has changed, the end time and guid are there so you can specifically look at how much healing is incoming within the time the user is casting a spell.
The delayed and stopped events don't need the amount because you don't use the amount value for calculating the total amount of healing incoming on a person. Only time you'd really use I can think of is if you want to see what healer is doing what, but you don't need the amount in Delayed and Stopped because you're not subtracting the amount from any grand total.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAlthough i'm not sure if this works for wow-addons as well ;)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIn the programming world sometimes people arent happy about the software , forge it, develop it further and it gets merged back into the source-tree once they have proven , that the code is good.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis isn't really something that's going to get merged into LHC, it breaks compatibility either way and it rewrites too much of the code.
The point is it's not adding a second healing comm library, it's replacing it with a better one more towards how people actually use it. Sure it's not going to be used by everyone overnight, but it also means you are forced into using one.
Would have been a bit better if I had done this in before 3.2 since a lot of people updated, but oh wel.
A few studies have been done attempting to predict how the consumer market would have reacted to a single standardized upgrade path to DVD, and each of them predicts higher profit for the companies involved and faster consumer adption rates. Together, they would only have had to market themselves as an upgrade to DVD, not as being an upgrade to DVD and being marginally better than the other competing format.
You anticipate that addons that utilize the current de facto library will replace it immediately, abandoning support for the old library entirely. For quite some period of time, probably months, this will lead to players having less information than they have now. What good is it if players have some information that is 25% more accurate, but have 50% less information overall?
I predict that a "planned obsolescence with no compatible upgrade path" will result in significant near-term disruption and confusion to players. I am not yet convinced that the touted benefits would outweigh this cost.
Are you certain there is no collaborative alternative to pursue?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI never said that it's going to be replaced immediately, but again if nothing is done then there is never a replacement and it never gets better.
You can't use an example like HD-DVD and Blu-Ray, they cost consumers money in both having to buy disks specific to one format but they also had to buy hardware that can only play that specific format. In this case, the consumer isn't spending their money on it, it's purely on the authors and swapping API's isn't that complicated depending on what they use LHC for.
When you get down to it it's simple, there is no way you can use GUIDs and the LibHealComm format which is built on names. Any transition to GUIDs requires a new comm format and new callbacks or else you break backwards compatibility, as it's a library you would do a major bump. The only solution is either not use GUIDs or write a wrapper that does it's "best guess" to translate names to GUID and at least receive HealComm data. That's not my priority right now, I might look into it later but I'd rather get this working first.
If your primary goal (at least the primary goal visible to end-users) with this library is to provide players with more accurate data, I strongly feel you would be working against this goal by not providing a compatible upgrade path. This might require extra work on your part. Are you willing to do that work to improve the players' experience?
The question is thus: "Is no data at all better than bad data?" Don't think that pushing it in your own unit frame addon is enough either; even ckknight doesn't have the kind of weight to make that a feasible method of pressuring other unit frame addon authors into switching libraries :p You'll just end up turning away prospective users of your unit frame addon who care about LHC compatibility.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf you have a suggestion I'm more than willing to listen, but the only way you can maintain compatibility with HealComm and IncomingHeals for sending healing data is to send out data twice for each library the HealComm format will flat out not work with GUIDs and does not have any room to hide a GUID in unless you go with hackery and that would be more likely to cause compatibility problems.
Writing a wrapper to receive heals sent from HealComm wouldn't be that difficult, sending data is where it becomes a pain.
Just to be clear, I'm doing this project either way as something interesting to do it's just a question of how useful it is to others.
[edit saw HunterZ's edit]
I already talked to Shefki and he's interested providing the API and library is better, writing a patch to do it for oUF and PerfectRaid are easy enough (as I did the original HealComm one for PR anyway) and once I have something more solid I'll talk to other unit frame authors.
I imagine players would be extremely grateful if you went the extra mile and smoothed out the upgrade path for them, even if it requires some hard work and hackery on your part.
As a smart player, I would refuse to upgrade my unitframe addon to one that supports the new library (and ignores the old one) until at least 50% of other players had already done so.
That's going to require an adventurous initial 50% who are willing to take that first step.