Nandini: As long as Shadowed can get the unit frame addon authors to endorse/incorporate it and eventually push release versions, people will eventually update. It sounds like he's willing to do the footwork to try to make that happen.
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.
LibHealComm-3.0 being xbeeps project not mine is the reason why I don't name it LibHealComm-4.0.
Keep in mind that a wrapper keeps you up to date it just means others have to update to get more accurate information, pretty sure you can't rely on the order of SendAddonMessage being maintained in CHAT_MSG_ADDON for everyone else, but maybe you can.
[edit damn you HunterZ!]
As HunterZ said, it's not something I plan on simply pushing out and telling people to pick at random what they want, I do actually plan getting it out there and used by other authors.
The first 50% of players who upgrade to addons using this library will be at a distinct information disadvantage. Without a compatible upgrade path, early adopters will be effectively punished for their support.
The last 50% of players who upgrade will also be at an information disadvantage, once they are in the minority. Their failure to upgrade also continues to degrade the quality of information available to the new majority who have upgraded.
I'm just afraid that true improvement will not be realized until there is 100% compliance. In the meantime, everyone will suffer.
Oh, I didn't realize that you had decided to implement a compatible upgrade path somewhere along the line here. I apologize for missing that.
From a deployment perspective, it's certainly okay to "punish" late adopters as a way of encouraging them to upgrade. You just need to make sure the early adopters aren't "punished" in the same way.
The benefits for being the 1st person out of 100 to upgrade just need to be at least as good as being the 51st or 100th person.
Well a wrapper to at least receive HealComm data is pretty straightforward it just means keeping a map of name -> GUID, it's not something I'm going to set in stone right now but receiving should be easy enough.
Is it possible that a unit frame addon could choose to support both libraries? This would put the "upgrade" decision more squarely on those authors, where it should be.
As long as authors are on board to use it, it doesn't matter. A lot of users use Curse/Minion clients to update anyway, then there are patch days as a catch all. 3.3 is only a few/several months away ;D For users, addon updates like this can be fairly viral and encourage updating.
Is it possible that a unit frame addon could choose to support both libraries? This would put the "upgrade" decision more squarely on those authors, where it should be.
The wrapper would have to automatically discard data from people using HealComm still (like a UF using IncomingHeals and Grid using HealComm) anyway, so if they used HealComm + Wrapper + IncomingHeals but never register for any of the HealComm events then sure, in theory you could use both fine. It just means you're sending out healing data twice for both libraries.
It seems as though all the events and messages generated by this library are triggered by the caster of the heal. To me, this makes the "Incoming" part of the library name misleading.
However, "Outgoing" doesn't really make the best sense either, since what most players will actually see isn't outgoing from their characters.
Because of the predictive nature of this library, something like LibPredictedHeals or LibPendingHeals might be appropriate. It doesn't have the confusing directional element that Incoming or Outgoing imply.
Most unit frame addons translate LHC-3.0 events into an "incoming heals" bar that is added onto the end of a unit's health bar.
This library does not seem to be concerned about damage shields at all. However, if this library could provide accurate shield information, it could provide some significant benefit to healers. Imagine an event message that translates to: "My damage shield on UnitX will absorb N more damage in the next Z seconds."
A unit frame might choose to react to such a message by displaying a "shield" bar at the opposite end of the unit's health bar, giving players a better idea of how large a hit the unit can survive. (I.e., pending heals might be attached to the "upper" end of a health bar, and active shields might be attached to the "lower" end.)
A healing library that supports shields in a way addon authors can easily implement in their addons would be a big step forward, I think.
Most unit frame addons translate LHC-3.0 events into an "incoming heals" bar that is added onto the end of a unit's health bar.
This library does not seem to be concerned about damage shields at all. However, if this library could provide accurate shield information, it could provide some significant benefit to healers. Imagine an event message that translates to: "My damage shield on UnitX will absorb N more damage in the next Z seconds."
A unit frame might choose to react to such a message by displaying a "shield" bar at the opposite end of the unit's health bar, giving players a better idea of how large a hit the unit can survive. (I.e., pending heals might be attached to the "upper" end of a health bar, and active shields might be attached to the "lower" end.)
A healing library that supports shields in a way addon authors can easily implement in their addons would be a big step forward, I think.
My understanding is that Blizzard added (adding?) events for absorb shields, although I'm not sure what happened with that since it sounds like it wasn't exposed yet.
My understanding is that Blizzard added (adding?) events for absorb shields, although I'm not sure what happened with that since it sounds like it wasn't exposed yet.
I was merely suggesting a feature that might make your library a "must-have" upgrade. It seems that damage shields are more easily tracked using combat log events now. Having the first practical implementation for these data (other than in damage/healing meters) would be impressive and notable.
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.
You just can't give it up? I've given you more than adequate justification for why the change cannot be accepted into LibHealComm-3.0 (see http://forums.wowace.com/showpost.php?p=285440&postcount=357). It's unnecessary and distasteful to spread FUD about the code being "flawed", just because it is not made exactly the way you want. The fact that i reject the proposol does not mean I'm rejecting collaboration, and in fact there are several contributers to the LibHealComm-3.0 codebase, and through the times there has been multiple developers who have contributed and optimised the code. You should learn that when collaborating you cannot always get your way.
As for this proposal, I'm a bit puzzled. It seems the central improvement is the use of GUIDs instead of names. It's nice to have GUIDs because they, unlike UnitIDs, are truly unique, granted. I considered using GUIDs when the combat log was first introduced (for a possible LibHealComm-3.1 og 4.0, or perhaps internally in 3.0), but found that it was not possible. The combat log event SPELL_CAST_START does not contain the GUID of the target:
You may have noticed that the combat log, in text, says something like: "Helon start to cast Lesser Heal". It doesn't tell anything about who the spell is cast on.
Only the normal event UNIT_SPELLCAST_SENT, which has the spell target name as the fourth argument reveals the identify of the healing target before the heal actually lands. So unless you want a library that tracks what has happened, as opposed to what is going to happen, i don't see how this can be done, unless i'm missing something. I don't know if you're aware of it, but names are quite useful, as they can be used in place of UnitIDs provided that you are grouped with the unit (which is the norm in the context of LibHealComm-3.0). This includes the ability to call UnitGUID, to retrieve the GUID, if that somehow could be useful to an addon.
I'm not arguing this. Your version code is flawed/wrong/unnecessary/whatever word you want, ask any other person and they will tell you the same thing. You disagree with me (and pretty much everyone else), fine it's your project.
Moving to GUIDs and in general other stuff requires rewriting it regardless, and the API could use streamlining more to how it's used by the majority. It's entirely unsuited for LibHealComm-3.0 either way.
You don't use the combat log events or the spell cast, the client knows the UnitID of who it's casting on at one point in time or another before UNIT_SPELLCAST_START is called, it just requires some magic tricks.
If you want to help collaborate on this or you have suggestions on the API's or events or general code I'm more than willing to listen, I don't mind adding people who want to contribute directly to this either. The entire reason I posted this instead of making it then releasing it is to get API/events to be cleaner and in general better.
You don't use the combat log events or the spell cast, the client knows the UnitID of who it's casting on at one point in time or another before UNIT_SPELLCAST_START is called, it just requires some magic tricks.
I'll be interested in this. What is the magic trick(s)?
I'll be interested in this. What is the magic trick(s)?
It's a bit easier to read the code (specifically starting at UNIT_SPELLCAST_SENT) but the basics of it is this, which only applies to casted spells since CLEU will give you the GUID anyway:
You can always fallback on the name -> unit map for grouped members and invalidate names if you find duplicates, it just means keeping a name -> GUID map for units like mouseover that become invalid.
There's a small corner case with mouseovers where when SENT is fired they aren't a mouseover unit anymore, so you have to keep track of the mouseover GUID via the event.
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).
It's not exactly a clean solution granted as you are secure hooking them, but I haven't had issues with it yet, and I could probably drop one or two of those from the hook list once I go through and clean up the code.
It sounds like this way of detecting heal casts will take a lot of work. It's very ambitious, and I wish you the best of luck.
Can you really tell the success or failure of a spell cast just by secure hooking these functions? (For example, if I am stunned for 6 seconds and am spamming Greater Heal a dozen times over those 6 seconds.)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumLibHealComm-3.0 being xbeeps project not mine is the reason why I don't name it LibHealComm-4.0.
Keep in mind that a wrapper keeps you up to date it just means others have to update to get more accurate information, pretty sure you can't rely on the order of SendAddonMessage being maintained in CHAT_MSG_ADDON for everyone else, but maybe you can.
[edit damn you HunterZ!]
As HunterZ said, it's not something I plan on simply pushing out and telling people to pick at random what they want, I do actually plan getting it out there and used by other authors.
Muahaha >:D
The last 50% of players who upgrade will also be at an information disadvantage, once they are in the minority. Their failure to upgrade also continues to degrade the quality of information available to the new majority who have upgraded.
I'm just afraid that true improvement will not be realized until there is 100% compliance. In the meantime, everyone will suffer.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFrom a deployment perspective, it's certainly okay to "punish" late adopters as a way of encouraging them to upgrade. You just need to make sure the early adopters aren't "punished" in the same way.
The benefits for being the 1st person out of 100 to upgrade just need to be at least as good as being the 51st or 100th person.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe wrapper would have to automatically discard data from people using HealComm still (like a UF using IncomingHeals and Grid using HealComm) anyway, so if they used HealComm + Wrapper + IncomingHeals but never register for any of the HealComm events then sure, in theory you could use both fine. It just means you're sending out healing data twice for both libraries.
It seems as though all the events and messages generated by this library are triggered by the caster of the heal. To me, this makes the "Incoming" part of the library name misleading.
However, "Outgoing" doesn't really make the best sense either, since what most players will actually see isn't outgoing from their characters.
Because of the predictive nature of this library, something like LibPredictedHeals or LibPendingHeals might be appropriate. It doesn't have the confusing directional element that Incoming or Outgoing imply.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMost unit frame addons translate LHC-3.0 events into an "incoming heals" bar that is added onto the end of a unit's health bar.
This library does not seem to be concerned about damage shields at all. However, if this library could provide accurate shield information, it could provide some significant benefit to healers. Imagine an event message that translates to: "My damage shield on UnitX will absorb N more damage in the next Z seconds."
A unit frame might choose to react to such a message by displaying a "shield" bar at the opposite end of the unit's health bar, giving players a better idea of how large a hit the unit can survive. (I.e., pending heals might be attached to the "upper" end of a health bar, and active shields might be attached to the "lower" end.)
A healing library that supports shields in a way addon authors can easily implement in their addons would be a big step forward, I think.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMy understanding is that Blizzard added (adding?) events for absorb shields, although I'm not sure what happened with that since it sounds like it wasn't exposed yet.
You just can't give it up? I've given you more than adequate justification for why the change cannot be accepted into LibHealComm-3.0 (see http://forums.wowace.com/showpost.php?p=285440&postcount=357). It's unnecessary and distasteful to spread FUD about the code being "flawed", just because it is not made exactly the way you want. The fact that i reject the proposol does not mean I'm rejecting collaboration, and in fact there are several contributers to the LibHealComm-3.0 codebase, and through the times there has been multiple developers who have contributed and optimised the code. You should learn that when collaborating you cannot always get your way.
As for this proposal, I'm a bit puzzled. It seems the central improvement is the use of GUIDs instead of names. It's nice to have GUIDs because they, unlike UnitIDs, are truly unique, granted. I considered using GUIDs when the combat log was first introduced (for a possible LibHealComm-3.1 og 4.0, or perhaps internally in 3.0), but found that it was not possible. The combat log event SPELL_CAST_START does not contain the GUID of the target:
21:28:45.771 SPELL_CAST_START,0x01000000000FD470,"Helon",0x511,0x0000000000000000,nil,0x80000000,2053,"Lesser Heal",0x2
21:28:48.286 SPELL_HEAL,0x01000000000FD470,"Helon",0x511,0x01000000000FD470,"Helon",0x511,2053,"Lesser Heal",0x2,150,150,0,nil
You may have noticed that the combat log, in text, says something like: "Helon start to cast Lesser Heal". It doesn't tell anything about who the spell is cast on.
Only the normal event UNIT_SPELLCAST_SENT, which has the spell target name as the fourth argument reveals the identify of the healing target before the heal actually lands. So unless you want a library that tracks what has happened, as opposed to what is going to happen, i don't see how this can be done, unless i'm missing something. I don't know if you're aware of it, but names are quite useful, as they can be used in place of UnitIDs provided that you are grouped with the unit (which is the norm in the context of LibHealComm-3.0). This includes the ability to call UnitGUID, to retrieve the GUID, if that somehow could be useful to an addon.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMoving to GUIDs and in general other stuff requires rewriting it regardless, and the API could use streamlining more to how it's used by the majority. It's entirely unsuited for LibHealComm-3.0 either way.
You don't use the combat log events or the spell cast, the client knows the UnitID of who it's casting on at one point in time or another before UNIT_SPELLCAST_START is called, it just requires some magic tricks.
If you want to help collaborate on this or you have suggestions on the API's or events or general code I'm more than willing to listen, I don't mind adding people who want to contribute directly to this either. The entire reason I posted this instead of making it then releasing it is to get API/events to be cleaner and in general better.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'll be interested in this. What is the magic trick(s)?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's a bit easier to read the code (specifically starting at UNIT_SPELLCAST_SENT) but the basics of it is this, which only applies to casted spells since CLEU will give you the GUID anyway:
You can always fallback on the name -> unit map for grouped members and invalidate names if you find duplicates, it just means keeping a name -> GUID map for units like mouseover that become invalid.
There's a small corner case with mouseovers where when SENT is fired they aren't a mouseover unit anymore, so you have to keep track of the mouseover GUID via the event.
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).
It's not exactly a clean solution granted as you are secure hooking them, but I haven't had issues with it yet, and I could probably drop one or two of those from the hook list once I go through and clean up the code.
Can you really tell the success or failure of a spell cast just by secure hooking these functions? (For example, if I am stunned for 6 seconds and am spamming Greater Heal a dozen times over those 6 seconds.)