• 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from Phanx
    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.


    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.

    And thanks for the permission to copy the debuff code from GridStatusHealingReduced. Most of that is directly reusable, which makes me wonder if perhaps that should go in a separate library by itself, and then used by both LibHealComm and your Grid addon, but that is a question for another day -- the code is small enough that duplicating it is a minor problem.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    In changing the "healing modifier from (de)buffs" calculation, I've needed to properly identify zone-specific (de)buffs so that buffs with the same name can be differentiated. The current best-practices method to handle this seem to be embedding libBabble-Zone-3.0. Would it be alright to add an external to this library in the "libs" directory?

    Also, without clear direction on how to continue contributing code for testing without breaking trunk, I plan on creating an "alpha" branch on Wednesday where I can commit such changes. To reiterate how this branch would be used:

    (1) This branch is potentially broken depending on the quality of the code committed.
    (2) Changes will first appear on "alpha" for testing.
    (3) Tested changes will be merged into "trunk", which will be maintained in a working state at all times.

    If this is not acceptable, please let me know.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from yoshimo
    how does lhc calculate the value that is shown for example in grid?
    i noticed a small difference between the healed value and the gridstatus sometimes.
    I read 2.1k on grid but it was only a 2017 heal . is it an average or the minimum or what exactly is shown?


    LHC computes an average value. The algorithm is basically to read the tooltip of the spell to see what the minimum and maximum heal sizes are, then take the average of the two values, then apply the bonus healing effects and percentage modifiers based on talents or buffs.

    For example, take Greater Heal 9. It has a base heal size of 3950 to 4590. Assuming 2000 spell power and fully talented Spiritual Healing and Empowered Healing, the actual heal will be between 8770 and 9474, but LHC will estimate a single value of 9122. In this case, the estimated heal is within 4% of the min/max values. There is clearly some variance in the estimate that is being ignored in the reporting, but as your spell power increases, the percentage difference between the actual heal and the estimated heal decreases.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    I can't seem to commit to the LHC repository ATM to add support for the druid Glyph of Renewal. I'm getting "Access Denied" on the commit attempt.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from cremor
    Whats still missing is the Improved Devotion Aura. I'll try to get a protection paladin for some tests in the next few days.


    The problem with detecting this buff is that regardless of whether the pally has points in that talent or not, all I see is "Devotion Aura" as the buff name, and the tooltip doesn't note the 6% increase in healing taken. For all intents and purposes, it's a "hidden" buff.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Directed mostly to xbeeps:

    I'd like to propose a change in the way the code for LHC is organized so that the following two issues are addressed:

    (1) Projects are using an external that points to LHC trunk.
    (2) It's hard to keep trunk 100% working all the time.

    In most projects I've worked on, there is a "development" where active development happens, and a "stable" branch for release-ready code. Since projects are treating "trunk" as a release-ready branch, I'd like to create a "branches/alpha" branch that is the active development branch where code can be committed for checkout and testing by volunteers. As the changes are verified, they can be merged into "trunk".

    Would this be too cumbersome for the LHC project?

    Also, as it stands, r36 is almost ready for release. Since patch 3.0.8 is coming out today, there are a few minor fixes to deal with changes in paladin glyphs and shaman Healing Way that I'd like to get in before a "3.0.8 release" is made.

    I also have other changes in mind to simplify the aura calculations and also deal with zone-specific debuffs, but those changes can wait until the code management details are sorted out.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Sorry, I meant r36 includes the latest paladin fixes. Please test r36.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Thanks for the paladin information and the data, cremor. I've incorporated the changes you noted into r35. I've verified the new spell coefficients for FoL and Holy Light using the data you collected, so the latest heal estimates should be in line with what you see in the combat log (disregarding non-100% crits). Could you please test the latest trunk?
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from totalpackage
    Getting this on r33 and r34 when casting Prayer of Healing on a priest:
    [2009/01/17 23:27:42-343-x1]: LibHealComm-3.0\LibHealComm-3.0.lua:220: Usage: UnitBuff("unit", [index] or ["name", "rank"][, "filter"])
    LibHealComm-3.0\LibHealComm-3.0.lua:220: in function <...comingHeals\libs\LibHealComm-3.0\LibHealComm-3.0.lua:219>
    LibHealComm-3.0\LibHealComm-3.0.lua:880: in function <...comingHeals\libs\LibHealComm-3.0\LibHealComm-3.0.lua:856>
    LibHealComm-3.0\LibHealComm-3.0.lua:1153: in function `?'
    LibHealComm-3.0\LibHealComm-3.0.lua:17: in function <...comingHeals\libs\LibHealComm-3.0\LibHealComm-3.0.lua:17>
    


    I've committed a fix for this in r35. Thanks for the error report.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from yoshimo
    i tested this glyph in bt and i was really disappointed back then..

    and i have a lua.error in libhealcomm.


    Ah, was this because one of your glyph slots was empty? This should be fixed in r34.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from cremor
    Don't forget that that glyph will be changed in patch 3.0.8 ;)


    I wasn't able to find anything in the current PTR notes regarding this change to the Glyph of Flash of Light:
    http://www.worldofwarcraft.com/patchnotes/test-realm-patchnotes.html

    Do you have more information on this? I'd like to have potential changes for 3.0.8 ready to go as soon as the patch is released.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    r33 includes the following changes:

    - Glyph of Flash of Light (paladin)
    - Focused Power (disc priest)
    - Grace (disc priest)

    I'm not sure if WoW correctly deals with Grace and Tree of Life. From what I've read, they shouldn't stack (meaning the buffs shouldn't simultaneously appear on a unit), but if this is bugged and they both show, then some heal overestimates can happen for a disc priest.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from jlam
    Is there an example for how this is done? I browsed the functions listed on WoWWiki's Interface page, but nothing really jumped out at me.


    For documentation purposes, the way to get the instance difficulty is using GetInstanceDifficulty() which returns 1, 2 or 3:

    "1" if normal or not in an instance,
    "2" if heroic
    "3" if "epic", which doesn't seem to be used yet.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from OrionShock
    there is a way to get the instance difficulty.


    Is there an example for how this is done? I browsed the functions listed on WoWWiki's Interface page, but nothing really jumped out at me.

    I will probably be reorganizing the buff/debuff code to check for a listing in an "all buff/debuff" table and then overriding with a listing in a zone-specific buff/debuff table.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    I have tagged the last release version of LibHealComm-3.0 as "tags/release". We will keep that tag updated to the latest release version at all times. For projects that embed LHC as an external, please track that tag instead of tracking HEAD.

    I'm not fully aware of the conventions used by WowAce, so if this isn't acceptable, please let me know and I'll modify the tags/branches to suit.
    Posted in: Libraries
  • To post a comment, please or register a new account.