• 0

    posted a message on LibSpecRoster-1.0
    Project page: http://www.wowace.com/addons/libspecroster/

    LibSpecRoster is a very lightweight library to keep track of group (party/raid) specializations, roles, talents, and glyphs.

    Blizzard made some nice changes with 5.0. All spec changes by group members trigger the PLAYER_SPECIALIZATION_CHANGED event, and group members can always be inspected, no matter where they are, as long as they are online.

    This means that there is no longer any reason for complex libraries that watch group members' casts to see if they cast a spec change, and that invalidate their data if they go out of range or out of zone. This also means that it is not efficient to send spec changes over addon comm, since less data will be flying around if you DON'T do so.

    The library makes an effort not to issue any unnecessary inspect requests. There is a small delay before requests are issued, and requests by other addons are tracked and not duplicated when possible. All relevant inspect data that comes in to the client is used to keep data up to date.

    The following methods and callbacks are available:

    Library methods:
    lib.RegisterMessage(yourObject, "messageName", yourMethod)
    lib.UnregisterMessage(yourObject, "messageName")
    lib.UnregisterAllMessages(yourObject)
    lib.getInspectData(guid) - returns specName, specID, class, role, blizzRole, talents, glyphs
    lib:getSpecialization(guid) - returns specName, specID, class
    lib:getRole(guid) - returns role, blizzRole

    Callbacks:
    "LSR_SpecializationChanged" - params: eventName, guid, unit, specID, talents, glyphs
    "LSR_RoleChanged" - params: eventName, guid, unit, role
    "LSR_TalentUpdate" - params: eventName, guid, unit, specID, talents, glyphs
    "LSR_GlyphUpdate" - params: eventName, guid, unit, specID, talents, glyphs


    Details:

    Roles are "tank" or "healer" or "melee" or "ranged".

    Blizzard roles are "TANK" or "HEALER" or "DAMAGER".

    Class is always the non-localized class name, i.e. the second return from UnitClass().

    Talents are returned as a simple array of the form {[talentLine] = SpellID | false}, i.e. if no talent has been selected on a given line, the array holds a value of false for that line.

    The glyph array has the form {[glyphSlot] = { spellID = SpellID, rank = 1 | 2} | false}. rank==1 is a minor glyph, rank==2 is a major glyph (as in Blizzard returns). Again, if a slot is empty, the entire entry for that slot is set to false.

    Caveats:

    There is currently no way to detect talent changes that do not involve changing spec. They do not trigger an event (except to that player), and there is no spellcast. Addon comm could be used for this, but unless all clients were running this library, the information would be partial and so, not reliable, which I find greatly limits its usefulness. So I kept it simple.

    The talent and glyph update callbacks are triggered whenever inspect data comes in that shows a change, but, again, talent and glyph changes are not and cannot reasonably be tracked.

    The library captures all relevant inspects, so, if your addon calls NotifyInspect() for a unit and there is a change, the update callbacks will trigger. Do be conservative with this, though.
    Posted in: Libraries
  • 0

    posted a message on Looks Better On You
    Quote from X-buZZ

    Please add an option to display the alt models without gear (naked, like the way MogIt does it).


    Done. You now have a sub-menu that offers all race / sex models, and these are shown naked except for the gear being tried on.
    Posted in: General AddOns
  • 0

    posted a message on Looks Better On You
    Thank you, Phanx.

    My memory ... not so good. I had no idea it wasn't me that put the link there, hah.
    Posted in: General AddOns
  • 0

    posted a message on Looks Better On You
    Heya. Sorry for the delay. I'm traveling at the moment and haven't been at a computer for a few days.

    The link to the project page is actually there at the bottom of my first post.

    I can make it possible to undress the models, I suppose. It's not technically difficult, I'll just have to think a bit about the best way to add that option unobtrusively. I have also been asked elsewhere to add access to all of the race/gender models even if there are no alts on the account of that model. I might just combine those two things. I.e., if you select a male dwarf alt, it will be dressed as that alt, but if you just select the male dwarf model, it will start naked.

    I'm not sure about the problem with the tab at the top right. The real issue here is, I CAN put it on top of the inside of the frame, but I don't want to technically make it part of the frame, i.e. modify the existing frame. Is it just that you don't want the tab sticking out of the side? I am also not clear on what you mean about renaming it. Do you mean that you just want me to refer to it in the text / on the web page as a drop-down and not as a button or a tab?

    In other words, is the issue aesthetic and semantic, or is there some functional change you are suggesting?
    Posted in: General AddOns
  • 0

    posted a message on Looks Better On You
    For my friends who love to spend time ctrl-clicking in Atlas Loot putting together new transmog outfits for their characters:

    'Looks Better Than You' is a small and lightweight addon that allows you to view your alts in the Dressing Room.

    A tab is added to the top right of the Dressing Room showing the name of the character currently being modeled. Clicking the tab displays a pulldown menu with a list of alts that can be viewed. A sub-menu show a list of all generic race /sex models.

    Characters are shown in their own gear except for items that are being tried on. If, for example, you bring up the Dressing Room by ctr-clicking a sword, and then switch to viewing an alt, the alt will be shown in her own gear except for the sword. Generic models are shown naked except for the gear that is being tried on. Show / hide helm / cloak settings are saved separately for each alt.

    Transmogrified items are shown as they would be seen, i.e. as the item they are transmogrified to.

    Equipped items are tracked for each character on your account whenever you log in to that character, so alts will only be available once you have logged in to them after installing this addon.

    If anyone can come up with a better name for this addon, I would very much like to hear it. I'm not all that happy with the name.

    Limitations: There is currently no way to control character customization such as hair style and facial features when loading models. The race and gear for your alts will be correct, but the customized features will not.

    Project Page:
    http://wow.curseforge.com/addons/looksbetteronyou/
    Posted in: General AddOns
  • 0

    posted a message on GridConfigurableLayouts
    Quote from cerbul
    Either I missunderstood you completely, but anyway I need to test out if enabling pets in grid will add that mind controlled mob to grid or not.
    From what I understood, is it that a mind controlled mob will still be a priest pet?

    Yes.

    Isn't it viable to simply "disable" priest pets that are called "Shadowfiend", like that will remain to be displayed those that are mind controlled mobs?

    No. Name filtering cannot be inverted. You can't include mind controls but exclude other pets for the same class, except by putting all possible npc names in a name list BEFORE combat. In fact, you cannot use name filtering at all if you want to filter by player class.

    In 10 ppl version of Naxx, there was a posibility to use that "globe on pillar", to make the mobs mind controlled, are those that player pet?

    Yes.

    You are sugesting that the multitude of dk and hunter pet names will make it impossible to track the difference between a hunter pet and a mind controlled by the hunter boss?

    No. Since name filtering cannot be inverted, the problem is the number of possible npc mind-control targets whose names would have to be listed, presumably in separate lists for each dungeon or zone. The names of the normal pets are irrelevant as long as they are not the same as any npc.
    Posted in: Grid & Grid2
  • 0

    posted a message on GridConfigurableLayouts
    The problem is that a pet is, by definition, someone's pet, and that someone has a class. If, on the Raz fight you give as an example, you have a warlock doing the mind-control, then, if you don't include warlock pets, the mind-control won't show. So class filters don't help at all with what you want to do.

    There is, I suppose, a way of doing it, but it's academic because I am not going to do this, and I don't see why anyone else would. What you would have to do, as far as I can tell, is create a namelist filter on the pets, set the attribute to use the pets' names in the filters, and then make a namelist that includes all of the possible mob names for the mind controls. As long as nobody gave their pet a name identical to any of the possible mind-control mobs, I suppose that would work. But it's definitely not worth it just as a way of filtering for mind-controls.

    I don't see any other way. Sorry.
    Posted in: Grid & Grid2
  • 0

    posted a message on GridConfigurableLayouts
    I have just tagged a Beta version. I believe I have addressed all of the known issues except for the handling of special characters in name lists. I'll try to get to that asap.

    Cerbul, mind controls are not necessarily easy to single out. I could add priest pets as an option to the list, but that would only catch normal mind controls. In the case of Razuvious, for example, that would not work. Mind-controls are just treated as pets of whatever toon controls them, so class filters won't get you anywhere, and I am not aware of any way to filter by how the pet was acquired.

    I think you already found that you can now select for sorting only the classes / roles you want at the top, and the rest of the group members will appear below alphabetically. I believe that is what you were looking for with putting the tanks at the top of the group but keeping the rest alphabetical.
    Posted in: Grid & Grid2
  • 0

    posted a message on GridConfigurableLayouts
    Cerbul, thanks for taking an interest and for giving all this feedback.

    I will answer the first part of your post, about the unit order you are looking for, in a little while. I don't have time to answer everything right now. This post is about the two details you mention at the end of your post:

    Quote from cerbul

    I also found 2 bugs:
    - I modified this myself in the file "GridConfigurableLayouts.lua" , and the code sequence is loking now like this(there was some space between the frames):

    - one other bug was that the black background behind the frames disappeared.


    The space between the frames is intentional. It is only there if you tell GCL to create individual borders around the groups instead of using Grid's single bordered frame around all of the groups.

    The black background behind the frames disappears because the whole point of using the custom borders is that they replace the single border and background that Grid uses.

    It sounds like what you want visually is to turn off the GridConfigurableLayouts group borders and just use the normal Grid border and background. To turn this off, just go to the options for the layout you are using, to the "General" sub-menu, and un-check "Replace Grid Border with Group Borders". If you really want the background but not the border, all you would do is set the border style to "none" in the normal layout options tab for Grid, not in this module's options.

    I am planning on changing the group border functionality a bit, but not in the way you are talking about: What I will be doing is respecting Grid's settings for spacing and background WITHIN the custom borders, so that the individual borders will reproduce the look that you choose in the Grid layout section for the default Grid frame. I will also be using the normal Grid padding setting to set the space between groups, and only add in the actual border thickness of the new borders.

    But as I said, that is very different from what you are suggesting.

    I will post again about the order of units in a little while.
    Posted in: Grid & Grid2
  • 0

    posted a message on GridConfigurableLayouts
    Hmm. I just went out for a cigarette and thought about it. It doesn't seem so tough to present this after all. I will look at the code a little later, and if it isn't too bad, I'll add that possibility for you.

    The way I would present it is to add an "Everyone Else" check box which, when clicked, grays out any remaining categories for sorting. So, say you were creating a role sort order, you could then click "Tanks" to put them first, then "Everyone Else", and then save the order, and it would do what you are asking.

    So, as I said, I'll have a look. I don't think it will be too much trouble.
    Posted in: Grid & Grid2
  • 0

    posted a message on GridConfigurableLayouts
    Hi, cerbul.

    I'm not sure exactly why you don't see any options in r72, but as I have fixed a fair number of bugs since then, I would suggest trying r73. If you don't see options there, I would really like to hear about it.

    At the moment, you can either sort by role (or class, or index), or sort alphabetically. So if you want tanks first in the group, you have two options: you either sort by role and live with the other roles also being sorted behind the tank (not sure why this would be a problem, but definitely not going to tell you what you should want), or you can target the tanks and click them into namelists, then check the box that puts the namelist ahead of the rest (sorted alphabetically).

    Frankly, I would not, myself, use the second possibility. The namelists can be very useful in a pinch when you need something special, but I wouldn't want a setup that required me to update namelists each time the group composition was different.

    Technically, what you are asking is not difficult, but it seems rather special, and I can't think of a clean and generalized way to offer it. If you can, describe it to me, and I'll consider it.

    I understand wanting tanks at the top of groups. In BH, for example, that is what I use as well. But it really doesn't bother me that below them I have melee, healers, ranged (or whatever order you choose), rather than players alphabetically.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid — compact party/raid unit frames
    Yeah, actually, the names of attributes are case insensitive and all get lc'd by SetAttribute(), so the line before should be name = string.lower(name), rather than putting the strings in with the camelcasing.

    Sorry, I grabbed the code from when it was in the OnAtributeChanged hook, saw the problem later and never corrected it here. In OnAttributeChanged all attribute names come through in lc for the reason given above.

    Btw, it actually took me a while to even notice the mistake because, as it happens, even without the change it fixed the problem. As things stand, if you look at where point, unitsPerColumn, and columnAnchorPoint are set in GridLayout, the only time you really ever need the points cleared is when a layout is loaded. Since "point" always gets set, that was happening correctly. If you had no concern at all about saving problems later, you could even just clear the anchorpoints once after loading a layout before showing the group, and everything would be good . . . for now.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid — compact party/raid unit frames
    And here I am yet again. Driving home a little while ago it occurred to me that I was going about this the wrong way. So I fixed it. Then I grouped up, fought, played with layouts, etc., . . . to make sure it works.

    What I realized is that it's ridiculous to hook OnAttributeChanged for this problem. It slows things down whenever an attribute is set and it runs the complete updating of the frame TWICE every time a point needs to change.

    Instead what I did is to create GridLayout.prototype:SetLayoutAttribute() and every time an attribute is set that affects or could affect anchoring, I call that instead of calling SetAttribute directly.

    The change to GridFrame is the same, i.e. comment/remove the hooks.

    The change to GridLayout is now to add the following function:

    function GridLayout.prototype:SetLayoutAttribute(name, value)
       if (name == "point" or name == "unitspercolumn" or name == "columnanchorpoint") then
          GridLayout:Debug("GridLayout.prototype:SetLayoutAttribute : Clearing All Points for " .. self:GetName())
          local count = 1
          local uframe = self:GetAttribute("child" .. count) 
          while uframe do
             -- GridLayout.Debug("   Clearing points for " .. uframe:GetName())
             uframe:ClearAllPoints()
             count = count + 1
             uframe = self:GetAttribute("child" .. count)
          end
       end
       self:SetAttribute(name, value)
    end


    I use that function instead of SetAttribute on lines 108, 114, 119, 174, 909-911, 918, 926-928, and 935. That is, anywhere we might be affecting anchor points of frames.

    Much cleaner, much more efficient.

    Hopefully this concludes my spamming of this thread.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid — compact party/raid unit frames
    After a fair amount of testing I made this work with one change. The call to SecureGroupHeader_Update() was causing tainting. After fixing that, I tested it in combat, inviting and removing players (in and out of combat), changing layouts. No problems with anything that I could find, and the old anchoring problems are completely gone.

    Here are my exact changes:

    -- GridFrame.lua : just commented out the hooks (lines 208-210).

    -- GridLayout.lua :
    -added the following function at line 38:
    local function GridLayout_OnAttributeChanged(self, name, value)
       if (name == "point" or name == "unitspercolumn" or name == "columnanchorpoint") then
          GridLayout:Debug("GridLayout_OnAttributeChanged : Clearing All Points for " .. self:GetName())
          self:ClearPoints()
          if self:IsVisible() and self:CanChangeAttribute() then
             self:SetAttribute("dummy_attribute", "dummy_value") -- to force an update without tainting
             --  the above seems better than Hide/Show, but that would work as well
          end
       end
    end


    -Added the following at line 58 (was 47):
       header:HookScript("OnAttributeChanged", GridLayout_OnAttributeChanged)


    -Added the following function at line 126 (was 113):
    function GridLayout.prototype:ClearPoints()
       local count = 1
       local uframe = self:GetAttribute("child" .. count) 
       while uframe do
          -- GridLayout.Debug("GridLayout.prototype.ClearPoints :  Clearing points for " .. uframe:GetName())
          uframe:ClearAllPoints()
          count = count + 1
          uframe = self:GetAttribute("child" .. count)
       end
    end
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid — compact party/raid unit frames
    Hmm, when I said it was different from "What they are giving us" that was based on downloading what is posted at:

    http://us.media.blizzard.com/wow/interface/WoW_Interface_enUS.zip

    But I looked in Tekkkub's GitHub repo of the blizzard UI and the SecureGroupHeaders.lua there shows exactly the change I mentioned above, i.e. the call to ClearAllPoints was moved into the section that processes only the unused unit frames.

    I'm really not sure where I should be getting the correct source, but anyway what I posted above stands.

    I'm going to log in now and test it as thoroughly as I can to make sure that adding the above and removing the existing hooks doesn't cause any problems / regressions.

    I'm not part of the Grid team. But solving this benefits me for reasons I gave two posts up, so hopefully Phanx won't mind a little unsolicited debugging work and a little clutter in this thread.

    I have a few days of semi-vacation, see.
    Posted in: Grid & Grid2
  • To post a comment, please or register a new account.