Posting to prevent any "where did my posts go" confusion: I've removed the tail end of the arguments over the versioning comm protocol, as those posts contained nothing relevant to the library itself and were primarily complaints and accusations exchanged between individual posters. If you two/three want to keep arguing, please do it in PMs.
Yeah, I don't have time right now to do any testing and see what the "actual" percent is, but I'll see what I can find out tomorrow from a GM. I don't want to put up a ticket tonight because they'll likely not get to it until after I go to bed, and then just send me a standard "delete your Interface and WTF folders because we have no idea how addons work and are too lazy to do any research to answer your question so we'll just say it's your addons' fault even though if we knew anything we'd know it was obviously not an addon problem" response. :p
Crit chance as per character sheet, naked and unbuffed:
Additionally, the tooltip for Intellect reports that my base intellect adds 3.02% spell crit chance. 7.02 - 3.02 = 4, so it looks like the 4% crit chance from Blessing of the Eternals is reported, but the 5% crit chance from Thundering Strikes is not. Next time I'm going to be on for a long period of time (most likely tomorrow evening) I'll petition a GM and see if Blizzard knows anything about it.
Why not? When a priest begins channeling Penance, transmit a "heal started" comm and return the total amount that will be healed over the course of the channel. Every second during the channel, transmit a "heal modified" comm and return the total remaining amount that will be healed. No combat log parsing required. Also, I would not label Penance as an "instant heal", as the healing is not applied all at once at the instant the spell is cast.
It's not really possible to reliably determine whether or not everyone in the target's party are in range, as there is no API to get the distance from Player A to Player B unless YOU are one of those two. You could do a check to see if all party members are within visible range, but other than that there's not much that can be done.
I was not aware that alpha versions ended up in other addons - i thought they had to be tagged as release first.
In theory, that's what is supposed to happen, but in practice, it's much, much easier to simply add the trunk to your svn-externals or your .pkgmeta once and forget about it, than to have to go update for a new tag every time one is created. :p
I was thinking more along the lines of an alpha branch that continuing active development would go on, instead of just for a single feature. I can certainly go one-branch-per-feature, but I didn't want to excessively proliferate branches in the repository. But I will do whatever the developers here with more experience with this project and with WowAce feel is best practice.
Once the feature is "release ready" you can simply merge it back into the trunk and delete the branch. ;)
I'd suggest using a more descriptive branch name (such as "zonespecific") but other than that it sounds fine. Feel free to copy my zone-specific debuff tracking stuff from GridStatusHealingReduced if you want.
sure, but again, i'm not really thinking the change should be made to the directheal callbacks, just the UnitIncomingHealGet function.
UnitIncomingHealGet is part of the existing API. Changing it in the way you propose would, as I've said a dozen times, significantly alter existing and very well established functionality in many addons. If you want to talk about specific changes to that part of the API, an additional parameter could be added to include HoT ticks in the return value; this would not alter existing functionality, but would be very easy for addon authors to add support for.
yeah, but then, presumably you'd want to be throwing heals up on the tank whether you see a dot or not, no?
Yes, but all I see for "incoming heal" is a green dot. It doesn't show me that X healing will land in Y seconds, or that A healing will land in B pieces over C seconds. LHC is not a display. It should not assume that all displays convey all of the information it can provide. Currently, if a user sees an incoming heal on someone, they assume, based on the experience of the last 2-3 years that LHC and its predecessors have been around, that a healer is paying attention to that someone at that very moment. The amount is less important. I trust the other healers in my raid to do their job, and they trust me to do mine. A druid can have HoTs on half the raid; it doesn't mean he's specifically paying attention to, or casting anything on, all of those 12 people at any given moment while those HoTs are active.
or you have those parameters tunable for the different roles -- tank, off-tank, dps, heals, etc.
How much healing is needed by each role is variable, and very situational. There is no one number for "how much healing does a tank need over a 5-second window" that will work for all tanks of all classes of all skill levels with all possible combinations of gear in all possible raid configurations in all situations. Either the user would need to manually tune those settings for every encounter, or the addon author would have to make a lot of assumptions and value judgements about what values to use. But I digress; this topic is irrelevant to LHC, since LHC is a library and not a display, and has no say in how the information it can provide is shown to the user.
that's fine. i want my incoming heal indicator to indicate incoming heals. and the api provides a very clear way to determine how much healing a unit will recieve in the next X seconds -- which seems like a better evaluation method than whether somebody is casting a direct heal, but if you like hot vs direct then that's fine. i'm still really more concerned with the UnitIncomingHealGet portion of the api...
And as above, I'm concerned with that as well. I've already described how I use LHC's data, and it's obviously very different from how you use it. I'm sure others use it differently than either of us. This is why it's so important that the data LHC provides is clear enough that addons can make any distinction the user wants, without having to make its own guesses. This is why it's so important that established functionality is not disrupted. It's not difficult to add new callbacks, new functions, new parameters to pass, and let addons support them if they want.
it seems to me that if hots were going to make it, they'd already be in there.
Not everyone has an infinity of time to spend planning out library APIs and writing code. I have dozens of projects I'd like to polish up, expand, finish, or even start. I would love to have more time in the day where I didn't have to sleep, go to work, attend to personal hygeine, shop for groceries and other necessities, spend time with my significant other and my friends, and actually play the game. The reality is that I don't have that time, and from looking at LHC's commit logs, I'd say its author doesn't either. If you have that time, and want to spend some of it to add HoT support in a way that does not trample all over addons and users who have grown accustomed to the way LHC and its predecessors have functioned for years, feel free to make a branch and get started.
it also seems clear from our debate here that hots are not a priority at all.
Not a priority for adding to LHC, that's probably true. Not a priority in general as far as healing is concerned, that's not true at all. I, and I'm sure other users, have found ways to show LHC's direct heal data and show HoTs in ways that work very well together to provide an efficient overview of raid healing. In fact, I would guess that HoT support in LHC has never been a priority because it's so easy to tell what HoTs are active on someone by watching UNIT_AURA. By contrast, the Blizzard-supplied events and API functions for direct heals are completely inadequate for knowing who's casting what on who for how much; that's exactly why LHC and everything that's come before it was written.
since haunt is a single healing event at a somewhat unpredictable time, it seems like putting it into the direct heal category is the most efficient way to actually having it show up...
Frankly, I'm a bit confused about the purpose of Haunt. I don't play a warlock, but it seems to me that in a PvE group situation, no healer is going to let someone sit around at 50% health for 12 seconds if there's anything they can do about it. Even if I know that someone is a warlock, and even if I know they have a Haunt out, I'm still going to heal them, because I can't take the risk that whatever hit them for 50% of their health won't happen again before then. If they're life-tapping, sure, they might be okay, but if they pulled aggro and took a few hits before the tank got it back, or if there's RST damage flying around, they can't wait that long. It seems more useful for soloing, where LibHealComm really isn't applicable at all, since there is nobody to communicate with...
the thing is, it seems kind of arbitrary to just assume that direct heals are 2-3 seconds and for significant amounts. rather than relying on a loose assumption, the grid dot should rely on something else, imo.
I haven't looked at other addons' code, but I suspect you'll find similar assumptions made there. It's hardly arbitrary; all of the healing spells that LibHealComm and its predecessors have supported for years have been direct heals with casting times no more than 3.5 seconds (untalented Healing Touch pre-WotLK) that healed for significant amounts. :p
personally, i think a better approach would be to take the amount of heals coming in over the next amount of time and indicate whether they go over a threshhold. indeed, you could alter the time and theshhold amount based on the health of the target -- if the target is low, shorten the time and increase the threshhold to indicate emergency circumstances. if the target is at 80% health, then look futher into the future for incoming heals and include even smaller amounts.
An interesting idea, but again, that is up to the display addon - not up to the library. The library's job is simply to provide data on what healing spells are being cast on who, and provide enough details that displays can convey that information in any variety of ways. And again, you should not make changes in a library with the assumption that code in all addons that use the library will be made, and will be made in specific ways you envision. LibHealComm is well established. Any changes made must consider the ways in which LHC functions now, the ways in which existing addons use LHC now, and the ways in which users use data supplied by LHC now.
(On a side note, your example wouldn't work very well for tanks unless you had additional code doing combat log parsing and incoming damage prediction to account for the fact that even if a tank is at 80% health, he needs a much higher volume of incoming healing than, say, a mage who is at 80% health.)
that's true enough, tho again seems like you're just taking advantage of a rather loose correlation between hots and relative healing power. particularly since you can have a few different hots running at the time.
True, but I already have separate indicators for HoTs; I want my incoming heal indicator to show only direct heals. This is what I keep saying about LHC being a library and not a display. The API should provide a clear way for display addons to distinguish between direct heals, and HoTs, and whatever Haunt would be classified as.
i'm more concerned with the "how much healing am i getting in the next X seconds" portion of the api, not the "who's casting heals and who are they casting them on" portion.
That's because you're a warlock, not a healer. As a healer, I want a more granular breakdown. As mentioned before, I show HoTs in a different way, and use the "incoming heal" indicator not only to show me that someone is being healed, but also that another healer is attending to them specifically. While HoTs can indeed put out a respectable amount of HPS, someone having an HoT on them does not necessarily indicate that they're getting attention from a healer at this moment. Again with the library-is-not-display thing, not all displays have room to, or are configured to, show a breakdown of how much healing is incoming over how much time, or list each active HoT, and LibHealComm should not make the assumption that they do.
Why are you so adamant that the existing API should be changed instead of added to? Either way, addons will have to add new code; the only difference is that adding to the API will mean that addons will all continue to work exactly as they work now until new code is added to use the new API, whereas changing the existing API will mean that addons will have to add new code to maintain existing functionality, which will disrupt the gameplay of thousands of users until those addons add that new code.
so you're saying don't add features that the api can account for because people aren't expected to follow the api? that seems kind of limiting. if addons can't add a time component to their lhc interface, i'm guessing managing hots with a separate function might not happen either.
The problem is not that addons cannot add a time component. The problem is that LHC currently works the way it works, and if you just change that, it will automatically change the way all addons that display LHC data work, disrupting functionality without any warning for thousands of users of the dozen or so addons in question that use the API as it currently functions. If addon authors want to handle HoTs exactly as they handle direct heals, they can simply add one new line for each new callback and point it at their existing incoming-heal handler function.
is there a benefit to identifying hots vs diret heals?
Absolutely. HoT ticks are much smaller than direct heals; . And as previously mentioned, the detailed information necessary to convey how much each tick is going to heal for in how much time is just too much for many displays.
Again, I can only speak for my own experiences and preferences, but I will say that if the corner indicator I use in Grid to show incoming heals started showing me HoTs, it would become instantly and completely useless. If it started to show me things that weren't going to happen for 12 seconds yet, it would be almost as bad. I already use another corner indicator to show me if someone has an HoT on them. The incoming heal indicator serves a different purpose.
Obviously Grid, or any other display addon, could easily add extra code to differentiate between HoTs and direct heals using the same callback, but why should it, when it would be much simpler for everyone involved to just add new callbacks for HoTs. Changing LHC at this stage to send HoT data or delayed heal data undifferentiated from direct heal data means that either (a) addons must add code to maintain existing functionality, or (b) users must adapt to significantly altered functionality. Either one is essentially a break in backward compatibility, something that should avoided whenever possible.
Adding new callbacks for HoTs would be reasonably simple, and would instead allow addons to add code to add new functionality.
except that haunt is really more similar to a direct heal than a hot. it's a single heal event. it's not dispellable. the only difference is that it doesn't fire imediately. holding off support for haunt until a comprehensive hot system were to make it into the mix short changes haunt, imo.
So, you expect all of the dozen or so addons that currently use LHC to all add special code to handle the incoming heal callback to add a timer to hold off showing Haunt until it's 2-3 seconds from the end of its duration? Or you expect that all users of those addons will allocate extra screen space and spend more time looking at warlocks to determine if that incoming heal is really a heal coming now, or a Haunt? More realisitcally, users would just start ignoring incoming heal indicators on warlocks and complaining that the addon's incoming heal feature was broken.
if the current api solution is sufficient for the current heals, i don't see why you'd need to split hots from the system. the "basic" info provided is how much healing will the target get in the specified time frame. whether they're hots or direct heals doesn't seem to make any difference in this "boiled down" scheme (that seems to work).
Except that not every display or every user has a fully featured display showing the amount of the incoming heal. Bear in mind that LHC is not a display, and does not specify or even recommend how displays should present the data it makes available. This is why it's important to differentiate between a direct heal that's coming in one chunk right now, versus a heal that's coming in one chunk some time from now, versus a heal that's coming in a bunch of small pieces over some amount of time.
To refer to my own experience again, if I see a warlock take aggro from something on trash, he's obviously in need of an immediate heal or he's going to die. If I'm in a raid with two healers, and I see that the warlock has a heal incoming on him, my experience with how Grid's incoming heal indicator (which originally used IncomingHealsLib, and now LibHealComm) works tells me that he's about to get a heal from the other healer, so I should heal the tank who's also taking damage instead. Now, if that green dot means "this guy might be about to get a heal, or he might just have a Renew ticking, or he might have thrown a Haunt on a mob", its ambiguity makes it far, far less useful as a tool for making critical, immediate decisions about healing.
Again, add new functionality, don't change existing functionality.
so looking at the code, it seems that the api has the time frame as an argument to the data request function. so you ask for how much healing over the next x amount of time. adding haunt wouldn't throw anything off from what i can see. of course, it also wouldn't be as handy for my purposes as a solo warlock trying to manage my mana/health as optimally as possible.
Except that the endTime value does not have widespread support, as right now addons can depend on "incoming heal" being something that's happening within the next 1.5-2.5 seconds. As previously mentioned:
i'm looking at lhc as being a comprehensive healing manager which is why i figured haunt would plug nicely into the framework, but maybe i just need to write a haunt/siphon life monitor for my own purposes... and then an aguf module to support it...
Haunt would indeed be a good addition to LHC, but not with the current API. Even the existing callback names (HealComm_DirectHealStart, HealComm_DirectHealDelayed, HealComm_DirectHealStop) and the language used in the API documentation on the project page make it pretty clear that the current implementation specifically supports only regular direct heals. Again, new callbacks would be a good solution. For example:
Fired when an HoT is applied. Describes the tick interval (unless this is the same for all HoTs? I've never specced my druid resto :p), the time of the final tick, the size of the first tick, and the amount each subsequent tick differs from the first (Wild Growth), and the amount of any final "bloom" heal (Lifebloom, Haunt). This would support all HoTs, and Haunt could be supported exactly like Lifebloom, except with a tick size of zero.
Fired when an HoT is dispelled or consumed; the HoT's caster would need to monitor the aura on its target and broadcast this information. Possibly additional data would need to be supplied in both callbacks to identify specifically which HoT was removed, if the endTime was not sufficient.
Presumably, the display addon would keep track of HoT ticks using the given information, and show them to the user in whatever manner was appropriate.
yeah, 12 seconds is kind of long. really, tho, the problem isn't lhc but the mod using the lhc data. for unit frames using the mod, they should "fade up" the extra health such that when a heal is first cast it is only, say, .3 or so alpha and by the time it's 50% complete, it would be .65 alpha on the way up to 1.0 alpha at the time of completion. that would give you a pretty quick guage of how soon a heal is going to land. (alternately, a heal could be colored red to start and end up blue if alpha is problematic).
it seems to me lhc shouldn't get into value calls of what heals are important or how to manage the amount of data, rather that should be up to the mod using it to handle since it is (theoretically) the ui portion of the equation.
Ideally, yes, but since LHC has already been established as-is, addons that use it expect it to work as it works right now. You should never modify existing API functions and callbacks to behave differently in ways that will cause display addons to behave differently if they don't also modify their code.
Currently, when LHC says "heal incoming on Supertank for 6k!" that means Supertank is getting a 6k heal in roughly 1.5 to 2.5 seconds, not that Supertank is getting a 6k heal spread out in 6 parts over 24 seconds, and not that Supertank is getting a 6k heal in 12 seconds. On a fight like Grobbulus, where the tank doesn't need a constant stream of heals to keep him up, if I see that a 6k heal is coming, I'll probably heal someone else instead. But if that 6k heal is really 6 ticks of 1000 each, I probably should heal the tank now. And if that 6k heal isn't coming for 12 whole seconds, I should definitely heal the tank now. Those distinctions are critical, and removing them with ninja changes to LHC would significantly reduce the usefulness of incoming heal data for many users of many addons.
While UI devices like fade-in bars, color gradients, and time text could help convey this information in some displays, they aren't appropriate for all displays. Better solutions would be to add new callbacks for HoTs and delayed heals that addons can choose to support, or break to a new major version of the library.