• 0

    posted a message on X-Perl Thread
    Quote from CagedTich
    I've done that before (not with the most current version, but a few months back), and the other healers using Grid with LibbHealComm still were unable to see any of my heals. Are you sure that the only thing requires is placing the LibHealComm folder inside my Add Ons folder and that is all? Is there any configuration for it in X-Perl or in-game?


    The currently released Grid (on Curse) supports LHC3. The alpha (available here) supports LHC4. This support went into r1218 on 2009-10-22.

    If you tried this a few months ago, you probably did it before support went in.

    LHC3 and LHC4 cannot directly communicate with each other. LibWrapperHealComm-1.0 exists for this purpose. Most addons that support LHC4 also include this, but it appears that X-Perl does not. For X-Perl to send and receive LHC3 data, therefore, you need another mod installed that loads LWHC. Try VisualHeal.

    Edit: Alternately, install LibWrapperHealComm-1.0 just as you do for LibHealComm-4.0.

    I don't use X-Perl, so I can't speak for the configuration. I don't believe it requires any, though.

    Quote from CagedTich
    So the little info I've been able to find more or less says (and please tell me if i'm wrong or missing steps):
    1. Download LibHealComm 4.0
    2. Unzip and put the folder in your Addons folder.
    3. Log into World of Warcraft
    4. Done. Now you should see all incoming heals from people using the mod, and they should see mine.


    Correct.

    Quote from CagedTich
    When I did do this a few months ago, I could not see any incoming heals and likewise grid users could not see any of my heals. If anyone is using LibHealComm with their X-Perl and knows for a fact they see incoming heals from Grid users, and Grid users can see their outgoing heals I'd really appreciate hearing how it's set up.


    See above.

    Quote from CagedTich
    Also, once it is functional what exactly is it going to look like in X-Perl? I already see glowing green frame borders when other X-Perl users having incoming heals. Will the LibHealComm addon show predictive health gains from incoming heals on the raid frames? How much does this interfere with reading other indicators on the frames (like current health/mana, debuffs, raid icons, etc)?

    Thanks for whoever can help me out.


    It should show predictive heal amounts in some fashion.

    Quote from CagedTich
    Edit:
    Looked at the latest version of X-Perl and it only mentions LibHealComm 3.0. I'm assuming it only supports 3.0 right now?


    X-Perl supports both, preferring LHC4. However, it appears that the .toc lists LHC3 as an optional dependency, but not LCH4. This is a bug. If you're running on an alphabetical file system, this likely won't affect you.

    Quote from CagedTich
    If I were to download LibHealComm 3.0 just like I did above, only putting it in my addon directory and nothing else, would that work with Grid users running the 4.0 version?


    Grid does include LWHC, so yes.
    Posted in: Unit Frames
  • 0

    posted a message on X-Perl Thread
    Quote from CagedTich
    Can anyone help me out trying to get LibHealComm 4.0 to work with X-Perl.


    You should be able to download LibHealComm-4.0 and place it in your addons folder alongside X-Perl.
    Posted in: Unit Frames
  • 0

    posted a message on GridStatusRole
    Quote from Azethoth
    Neat. I can haz Grid2 version?


    Most of it is interface code - the heavy lifting is done by LibGroupTalents-1.0. I can't imagine it would take you long to move over (I don't have any experience writing Grid2 plugins).
    Posted in: Grid & Grid2
  • 0

    posted a message on GridStatusRole
    Adds role status to Grid. Indicates the roles of your group members (Caster, Healer, Melee, or Tank), and updates when group members change roles.

    http://wow.curse.com/downloads/wow-addons/details/gridstatusrole.aspx
    Posted in: Grid & Grid2
  • 0

    posted a message on RaidBuffStatus
    Quote from cremor
    danielbarron, could you please check the Addon TCoL_ScoreUs if it's inspecting correctly?


    I'm not danielbarron, but a quick look over the code shows that it's not calling NotifyInspect(), but rather it calls InspectUnit() which pops up the inspect window.

    In any event, this will call through to NotifyInspect(). Since it's not hooking NotifyInspect(), it can (and probably often does) receive data for a different unit than it believes.

    While I don't think it will cause issues with other correctly written addons (other than forcing them to re-queue a failed inspect), I'm surprised that it works in real use.

    The author of TCoL_ScoreUs talks about it in this thread:
    http://forums.worldofwarcraft.com/thread.html?topicId=18570227226&sid=1

    My advice is that the author switches to LibTalentQuery.
    Posted in: Raid AddOns
  • 0

    posted a message on LibTalentQuery-1.0
    Quote from Brimmstone
    Have you verified that "name" is actually a player name and not a UnitID like "raid1", etc?


    I have indeed.
    Posted in: Libraries
  • 0

    posted a message on LibTalentQuery-1.0
    Quote from Brimmstone
    @Greltok:

    The only thing I can think of is that for whatever reason your inspect flag isn't getting set properly. Have you tried using a different (possible less elegant) method for setting that?

    if (UnitIsUnit("player",name)) then
         InspectFlag = false;
     else
         InspectFlag = true;
     end
    
    I'm also assuming that you're setting "playerName" someplace outside the function. Is it possible you're having a problem with variable scoping that's resulting in "playerName" always being nil inside the function?


    I've tried both ways, actually, and get the same result. I have verified that playerName is setup correctly.
    Posted in: Libraries
  • 0

    posted a message on LibTalentQuery-1.0
    Quote from Brimmstone
    I don't know how many people you tested with, but if their first spec is the same as yours, it may appear that you keep getting your spec back but you're not.


    I've been testing with a full 25 man raid. In many cases, the inspect target is a completely different class, and reporting an identical spec to mine (both tree names and points spent).
    Posted in: Libraries
  • 0

    posted a message on LibTalentQuery-1.0
    I'm having running into an issue in my LibTalentQuery callback. When I call GetTalentTabInfo( tab, inspect ) in my callback, I occasionally get my talent info, rather than the inspect talent info.

    My callback function is paraphrased below:

    function MyMod.TalentQuery_Ready( event, name, realm, unitid )
    	local inspect = ( name ~= playerName )
    	local spec = {}
    	local totalPoints = 0
    	local talentTabs = GetNumTalentTabs( inspect )
    	
    	for tab = 1, talentTabs do
    		local treeName, _, treePoints = GetTalentTabInfo( tab, inspect )
    		totalPoints = totalPoints + treePoints
    		table.insert( spec, { treeName = treeName, treePoints = treePoints } )
    	end


    The name is that of another unit, but the talent tree info is mine.
    Any ideas?
    Posted in: Libraries
  • 0

    posted a message on LibTalentQuery-1.0
    I was hoping someone could review a change to the function NameToUnitID().

    The changes are:
    1) declare the variable unit as local.
    2) fix the return values for unit target and unit pet target as reported on Curse.

    The diff can be found here.
    Posted in: Libraries
  • 0

    posted a message on GridStatusSanity
    For all your Yogg-Saron Sanity needs.

    http://wow.curse.com/downloads/wow-addons/details/gridstatussanity.aspx
    Posted in: Grid & Grid2
  • 0

    posted a message on Target of target broadcast
    There's LibBanzai-2.0, which scans all group members' targets looking for the targets of hostile mobs. Note that it's throttled to scan every fifth of a second.
    Posted in: Lua Code Discussion
  • 0

    posted a message on table size
    If you're only interested in learning whether the table is not empty, you can use:

    if next(t) then
    Posted in: Lua Code Discussion
  • 0

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


    Exactly. A fully qualified name for someone on your realm does not include your realm.

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

    To A, A is "A", B is "B", and C is "C-Two".
    To B, A is "A", B is "B", and C is "C-Two".
    To C, A is "A-One", B is "B-One", and C is "C".

    This is how the Blizzard API sees it.
    For example,:
    A calls UnitName( "B" ) - The API returns "B", nil.
    A calls UnitName( "B-One" ) - The API returns nil, nil.

    From this, we see that a name that includes your local realm name is considered invalid.

    With these changes, A stores heals to B in HealSize["B"], and C stores them in HealSize["B-One"].

    Quote from jlam
    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.


    The Blizzard APIs will return a fully qualified name. The issue in LibHealComm is where it receives names in CHAT_MSG_ADDON. What one client considers to be a fully qualified name may not be the same to other clients. You'll note that these are the only changes I made - I attempt to fully qualify names that are received from other clients.

    Quote from jlam
    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.


    You're right - I probably committed too early, before all reviewers had a chance to weigh in. I had intended to wait for reviews; but in my defense, I took the lack of response to be indifference. What would an acceptable amount of time to wait have been?

    Quote from jlam
    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.


    Absolutely. I would hate to break the trunk for other projects that had referenced LibHealComm as an svn:external. However, I would argue that battlegrounds didn't work before, and now they do (in some capacity). As far as I know, I didn't break anything - I have spent several hours testing these changes both in raids and BGs.

    Quote from jlam
    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.


    The workaround you speak of is to try to ensure that the sender's name is fully qualified, and is not affected by my changes.

    Quote from jlam
    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.


    I have no issues backing out my changes, but where is it incomplete? Even if it is incomplete, is it worse or better than before?
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from jlam
    For example, in UnitIncomingHealGet(), the HealSize table is being referenced via an index that may not be fully qualified with the realm name.


    UnitIncomingHealGet() calls:
    local targetName = unitFullName(unit);
    resulting in a fully qualified name.

    Quote from jlam

    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.


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

    Quote from jlam
    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.


    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.
    Posted in: Libraries
  • To post a comment, please or register a new account.