• 0

    posted a message on LibHealComm-3.0 Official Thread
    I'm trying to detect certain situations for shamans where it's possible to know that the crit heal is guaranteed. For example, if Tidal Force is activated (60% crit) and you have Riptide-enhanced LHW (25%), then a shaman only needs 15% crit on the character sheet to be guaranteed a LHW crit, and it'd be nice to factor that into the estimated heal being broadcast to the raid.

    Can anyone with a shaman please answer some questions for me?
      1. What's your spec (please link to a talent calculator)?
      2. With no gear on and no buffs, what's your spell crit chance (open up your character sheet)?
    In theory, if you've fully talented into Thundering Strikes and Blessing of the Eternals, you should have a base spell crit chance of at least 9% just from talents, but that's not what I saw last night on my shaman. My character sheet showed a smaller number than that.

    I guess the safest thing to do is to GetSpellCritChance() for the Nature School and add in crit from the Tidal Mastery talent to get a lower limit for the healing spell crit chance, but does anyone know how to get a more accurate answer?
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    r66 on the patch-3-2-testing branch is stable for me and working properly on shamans and druids. I was unable to find a priest in my guild to test for me (my server is pretty high population and queue times were long last night), but the only change in the priest section was altering one spell coefficient. It should be safe to merge the branch back into the trunk.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    I'm trying to figure out how to support Glyph of Healing Wave. For reference, the description of Glyph of Healing Wave (patch 3.2) is:
      Your Healing Wave also heals you for 20% of the overall healing when you heal someone else.
    The API and the callback arguments imply that the same-sized heal is being cast on multiple targets, but for the case of Glyph of Healing Wave, it's only 20% of the heal on the target. In this case, what should UnitCastingHealGet() return? It would normally return a triplet of heal size, cast end time, and a list of targets, but that would be insufficient in this case.

    For the future (LHC-4?), I think the non-trivial messages could be made more future-proof if they included a header size, e.g.
      MsgType|FixedPayloadSize|FixedPayload|VariablePayload
    That way, you could append additional fixed payload fields to handle future extensions to the messages, with new versions of LHC understanding all the extensions, and older versions just skipping the stuff they don't know how to read. And all versions of LHC would know how to skip past the fixed payload to get to the target names.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    I created a branch called "patch-3-2-testing" that includes the changes to support Patch 3.2. The changes are untested as yet... I intend to test it on shamans, priests and druids tonight (no changes were made as yet to the Paladin section).
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Will do, thanks. I just want to have a version ready for release as soon as the PTR changes go live so my guild's healing mods stay accurate.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from xbeeps
    There are no branches. The latest revision is a result of testing on the PTR, fixing a tooltip scanning problem, because the spell tooltips now also contains the global cooldown when active.

    Apart from that there may be some differences in talents, but that will have to be fixed up as we go. If you know of some specific talent changes that may affect healing, or new trinkets/buffs/debuffs, you are welcome to post them here, which will make my job much easier, because i don't have to go over several talent trees of classes i don't play myself (i play a shaman!).


    Would it be easier for you if I just included the changes but commented out in the LUA file directly? Or just post patches to this forum that can be applied after 3.2 is released?
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from Phanx
    It does, but those "instant casts" come at fixed intervals while the priest is channeling the spell. It's exactly like a mage's Arcane Missiles.


    Huh, so it's sort of like a way around the GCD on one spell... the "instant casts" can come well under GCD and still be affected by haste. I wonder why people don't propose this spellcast mechanic more often when they explore ways to buff their class's spell toolkit.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Ah, then I misunderstand the spell description on Wowhead which seem to indicate in the comments that the spell acts like a sequence of instant casts.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from Troox
    Penance (Priest) Support is the one i miss -.- Is it possible to add this channeled Spell as a Direct Cast Spell like Greater Heal? Our Paladins blame me (Disciple Priest) that they dont see many Heals from me ;)


    I don't see any way to support Penance in LHC-3. The spell doesn't put a buff on the target, and as it's being channeled, it applies an instant heal on the target every second that it's channeled. While I can see LHC-3 someday supporting HoT ticks, I don't see how instant heals can be usefully communicated in a heal group by an addon.

    Perhaps there is some interesting combat logging that happens for Penance? Can you provide it? Even so, it would require parsing the combat log to get the details, which xbeeps has said he prefers not to do.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Has there been any work on incorporating the changes in 3.2 into LHC-3 yet? Is there a branch that may be tested on the PTR?
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from Greltok
    UnitIncomingHealGet() calls:
    local targetName = unitFullName(unit);
    resulting in a fully qualified name.


    Look at the implementation of unitFullName(). If the unit is in the local realm, the it doesn't return "name-realm", it only returns "name".


    Quote from Greltok
    If all names passed to the internals of library are fully qualified, then this shouldn't be an issue.


    And my point is that they're not in the latest revision on trunk. There is no point in the code where names are canonicalized to be "name-realm" beyond which you know that what you're dealing with is only fully qualified names. If you're pushing to make a change like this, you need these types of guarantees in the code so that it's maintainable.


    Quote from Greltok
    To be pedantic, I didn't expand the API - I fixed (or attempted to fix) what I perceive to be a bug.

    At any rate, if my changes are incomplete, or you would prefer not to take them, I will be delighted to back them out (or you can if you wish).

    I would have held off on checking in the changes had I known that you (or anyone else) were actually reviewing the changes. After several days, the only feedback was a note about perhaps using GUIDs internally.


    This confuses me because in your original post, you said you didn't want to commit without review and permission. As this is xbeeps' project, permission runs through him, though public code review is always good. You posted a patch, then one day later I post a query, then the next day you commit your changes. Perhaps I misunderstood your stated intentions.

    If you look back over the recent posts on this thread, you'll find there is a stated intent to keep trunk as "always working" as it is referenced as an svn:external library by many different projects. And you'll find the discussion came about because I broke the trunk due to a misunderstanding on how projects were embedding this library both for release and for development. Let's not go down that same path again.

    I'm delighted to see people looking at the code and fixing shortfalls and bugs. If LHC is broken in the battlegrounds, this should be fixed. There is even a noted workaround in CHAT_MSG_ADDON() for battlegrounds which was left alone by your patch which should probably be affected in some way. I would recommend backing out your changes which are incomplete and posting a more complete patch for review and later, commit permission from the project author.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from Greltok
    I've committed these changes (with a few small edits). I'm pretty confident it works as expected after testing in both raids and BGs.


    Your committed changes are incomplete. For example, in UnitIncomingHealGet(), the HealSize table is being referenced via an index that may not be fully qualified with the realm name. Also, it is not good that not every table that is indexed via unit name is using a fully qualified name if you are pursuing these changes because the various Heal* tables are very tightly-coupled -- within the internal code of the library, you've now made it required that it must be kept in mind which names must be fully qualified and which may not be when accessing the information stored in the Heal* tables.

    The change you had proposed to expand the API were minor, but the implementation details to do it correctly were much larger than the patches you had posted. I simply didn't have enough time to review your changes before you committed them.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from Greltok
    More troublesome, though, is the method UnitIncomingHealGet(). It seems that the incoming heals data is stored by name, but not necessarily fully qualified.

    ie:
    A is on realm One.
    B is on realm One.
    C is on realm Two.

    Both A & C heal B.
    A transmits that he's healing B.
    C transmits that he's healing B-One.

    Both of these heals are stored as separate entries in the HealSize table (HealSize["B"] and HealSize["B-One"]), so UnitIncomingHealGet() won't return them both.


    This sounds like what UnitGUID() is meant to solve. Maybe we should use unit GUIDs to index the Heal*[] lookup tables?
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    r39 should be pushed out on Curse.com as the latest release. It handles the latest changes in patch 3.0.8 to paladins and shaman talents and glyphs.
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    After some more thought, I've decided to go with one-feature-per-branch to house all of the development for that feature. My rationale is that I don't want to put more overhead onto someone else's project than is absolutely necessary. This way, minor commits can still be made to trunk, while features can be fleshed out on branches and tested there before being merged into trunk.

    In practice, I don't expect an explosion of branches to happen.
    Posted in: Libraries
  • To post a comment, please or register a new account.