• 0

    posted a message on GridLayoutPlus
    I added an option to sort "By Role". There are 5 roles:

    Tanks = Warriors & Paladins with 31 in Protection, Druids with 31 points in Feral
    Melee = Rogues, Warriors who are not tanks, Paladin with 31 points in Retribution, Shaman with 31 points in Enhancment
    Healer = Priests who are not Shadow, Paladin with 31 points in Holy, Druids & Shaman with 31 points in Resto
    Hybrid = Paladin, Druids, and Shaman who do not have 31 points in any 1 tree (usually low levels)
    Ranged = Mage, Warlocks, Hunters, Priests with 31 points in Shadow, Druids with 31 in Balance, Shaman with 31 points in Elemental

    The 5 buckets are just for sorting, there are no hard groups defined. So if you have 3 tanks, and are set to 5 units per column, then 2 melee will be in the same column as the tanks. I could easily change this to 4 hard defined groupings (I would merge healer and hybrids) but I'm not sure it's necessary yet.

    It also adheres to the classOrder that you define in the options menu. The sorting logic is (roleorder)(classorder)(level [DESC])(unitid)

    Also note that it takes about 1 second per unit to get their talents. It only queries talents for hybrids, Warriors, and Priests. So usually 30 seconds after joining a new AV (for example), the roles are finished being sorted out. If a unit is out of visibile range then the unit will stay on a queue until you are in range of the unit. No units are lost, they just will be sorted in a default location until the talent can be queried.

    WARNING: You may find that DogTag addons (PitBull, CowTip) behave strangely when using "By Role". This is not a fault of mine, but a fault of the way DogTag handles talent queries. It assumes it's the only addon that has the right to query talents and doesn't take any precaution to prevent it's queries from being "hijacked". Blame Blizzard really, they could have made querying talents a little easier.


    I also took the luxury to redo the entire Layout option menu. I always hated how the options weren't grouped together properly. Please give me feedback on this as I'm planning for these options changes to be merged into the core.
    Posted in: Unit Frames
  • 0

    posted a message on Hijacking of INSPECT_TALENT_READY
    Problem 1) INSPECT_TALENT_READY does not tell you which unit it has talents for. You need to figure out how to make the connection.

    Solution 1) Save the unitid in a variable before firing NotifyInspect()

    Problem 2) If you keep INSPECT_TALENT_READY as a constant registered event, then it will be triggered by other addons and default UI events.

    Solution 2) Only register INSPECT_TALENT_READY when you call NotifyInspect(). Unregister it when event fires. It's a one to one relationship (NotifyInspect requests talents from server, and INSPECT_TALENT_READY is fired when the info is available).

    Problem 3) Since other addons call NotifyInspect(), it's possible for your INSPECT_TALENT_READY to be triggered by someone elses addon. This is the problem I created this thread for.

    Solution 3) As Xinhuan suggested, hooksecurefunc on NotifyInspect to make sure it was called by you. Do preventive measures if it's not "yours".
    Posted in: Lua Code Discussion
  • 0

    posted a message on Hijacking of INSPECT_TALENT_READY
    Confused... why are we messing with frames? Could you explain what you are trying to fix?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Hijacking of INSPECT_TALENT_READY
    Quote from Xinhuan »

    You need to securehook NotifyInspect() so that if any other addon that isn't yours tries to call it, you can catch the unitID of the call. If there is already a talent request ongoing, then you know the reply will be invalid.


    That worked!

    Here is some sample code of what I did (using Ace2):

    local RL = AceLibrary("Roster-2.1")
    
    MyAddon = AceLibrary("AceAddon-2.0"):new("AceEvent-2.0")
    
    local inspectingUnit = nil
    local inspectQueue = {}
    
    function MyAddon:OnEnable()
    	...
    	hooksecurefunc("NotifyInspect", MyAddon_NotifyInspect)
    end
    
    function MyAddon_NotifyInspect(unit)
    	if (unit ~= inspectingUnit) then
    		if MyAddon:IsEventRegistered("INSPECT_TALENT_READY") then
    			MyAddon:UnregisterEvent("INSPECT_TALENT_READY")
    		end
    		if inspectingUnit then
    			inspectQueue[inspectingUnit] = true
    			inspectingUnit = nil
    			if (not MyAddon:IsEventScheduled("CheckInspectQueueID")) then
    				MyAddon:ScheduleEvent("CheckInspectQueueID", function() MyAddon:CheckInspectQueue() end, 2)
    			end
    		end
    	end
    end
    
    function MyAddon:INSPECT_TALENT_READY()
    	local u
    	if inspectingUnit and UnitIsVisible(inspectingUnit) and UnitIsConnected(inspectingUnit) and UnitInRaid(inspectingUnit) then
    		self:UnregisterEvent("INSPECT_TALENT_READY")
    		u = RL:GetUnitObjectFromUnit(inspectingUnit)
    		inspectingUnit = nil
    	end
    	if u then
    		u.talentrole = "NONSPECIALIZED"
    		for tab = 1, GetNumTalentTabs(true) do
    			local treename, _, pointsspent = GetTalentTabInfo(tab, true)
    			if ((treename == "Protection") or (treename == "Feral Combat")) and (pointsspent > 31) then
    				u.talentrole = "TANK"
    			elseif ((treename == "Retribution") or (treename == "Enhancement")) and (pointsspent > 31) then
    				u.talentrole = "MELEE"
    			elseif ((treename == "Holy") or (treename == "Restoration")) and (pointsspent > 31) then
    				u.talentrole = "HEALER"
    			elseif ((treename == "Shadow") or (treename == "Balance") or (treename == "Elemental")) and (pointsspent > 31) then
    				u.talentrole = "RANGED"
    			end
    		end
    		self:RosterUpdate()
    	end
    end
    
    function MyAddon:CheckInspectQueue()
    	local repeatqueuecheck = nil
    	if (not inspectingUnit) then
    		inspectingUnit = next(inspectQueue)
    		if inspectingUnit then
    			if UnitIsVisible(inspectingUnit) and UnitIsConnected(inspectingUnit) then
    				inspectQueue[inspectingUnit] = nil
    				self:RegisterEvent("INSPECT_TALENT_READY")
    				NotifyInspect(inspectingUnit)
    			end
    			repeatqueuecheck = true
    		end
    	else
    		repeatqueuecheck = true
    	end
    	if repeatqueuecheck then
    		if (not self:IsEventScheduled("CheckInspectQueueID")) then
    			self:ScheduleEvent("CheckInspectQueueID", function() self:CheckInspectQueue() end, 2)
    		end
    	end
    end
    
    function MyAddon:RosterUpdate()
    	...
    	for u in RL:IterateRoster(nil) do
    		if (not u.talentrole) and ((u.class == "WARRIOR") or (u.class == "PALADIN") or (u.class == "DRUID") or (u.class == "SHAMAN") or (u.class == "PRIEST")) then
    			if (not inspectingUnit) and UnitIsVisible(u.unitid) and UnitIsConnected(u.unitid) then
    				inspectingUnit = u.unitid
    				self:RegisterEvent("INSPECT_TALENT_READY")
    				NotifyInspect(inspectingUnit)
    			else
    				inspectQueue[u.unitid] = true
    				if (not self:IsEventScheduled("CheckInspectQueueID")) then
    					self:ScheduleEvent("CheckInspectQueueID", function() self:CheckInspectQueue() end, 2)
    				end
    			end
    		end
    	end
    	...
    end


    Also note that I only register the INSPECT_TALENT_READY right before I call NotifyInspect, and unregister it immediately after when my INSPECT_TALENT_READY function is called. I think if all addons (*cough*DogTag*cough*) that query talents do these 2 things (1 - register/unregister INSPECT_TALENT_READY on the fly & 2 - hook NotifyInspect to check if it's "yours") then we can all play nice again.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Hijacking of INSPECT_TALENT_READY
    Hi, I'm trying to write a proof of concept grid addon to query talent specs and rearrange the groups accordingly. The problem is with DogTag (or any other talent querying addon) hijacking my INSPECT_TALENT_READY events, or triggering the event without me knowing what unit it's looking at. The code works perfectly without DogTag enabled.

    When looking at the DogTag/Proximo/Remembrance code, I noticed they all keep the INSPECT_TALENT_READY event registered all the time. It would have been wonderful if Blizzard passed the unitid in the event, but because they don't, it's irritating that these events are always registered.

    So my question... How do we allow multiple addons to query the talents without stepping on each others toes? Can we susspend other addon functions from being triggered by an event while you are are waiting on data from that event? There has got to be a better solution.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Grid Layout Simulator
    I thought I was the only one. I've been reported so many times.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid
    If it's related to GridLayoutPlus, please post your findings here:

    http://www.wowace.com/forums/index.php?topic=11027.0

    I personally have not had this issue. Make sure you are updated to latest version, and that you aren't using any other layout addons.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid
    Quote from Pachelbel »

    But even looking at talents specs isn't always enough -- although it's a great first guess. Just like looking at aura/stances/form/etc. isn't always accurate. I know some fights we have prot pallies or druid tanks heal. As a holy paladin, I've even been asked to heal a fight with righteous fury up to try and draw mobs to me away from squishes.

    Unfortunately, I think this problem is always going to involve some manual sorting.


    I still don't think this feature should be in the core, but instead provided in an additional module like GridDynamicLayout, but if I were to write it, this is what I would do:

    I would create 5 groupings:

    Tanks:
    Warrior with 31 or more in Protection
    Paladin with 31 or more in Protection
    Druid with 31 or more in Feral

    Melee DPS:
    Rogue
    Warrior with less then 31 in Protection
    Paladin with 31 or more in Retribution
    Shaman with 31 or more in Enhancement

    Healers:
    Priest with less then 31 in Shadow
    Druid with 31 or more in Restoration
    Paladin with 31 or more in Holy
    Shaman with 31 or more in Restoration

    Ranged DPS:
    Mage
    Warlock
    Hunter
    Priest with 31 or more in Shadow
    Druid with 31 or more in Balance
    Shaman with 31 or more in Elemental

    Hybrid:
    Druid with less the 31 in all 3 trees
    Paladin with less then 31 in all 3 trees
    Shaman with less then 31 in all 3 trees

    I personally would like for all units to stay in one place for the entire raid, which means that I don't want to look at what buffs a unit has to determine placement on my screen. As far as feral druids being either tanks or melee, my philosophy is that all feral druids are potential tanks, if they only bring dps gear to a raid they will probably be yelled at.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid
    Phanx:
    I had a discussion with Mokhtar about this when I was asked to merge my code into the core. I think we both agreed that the functionality in his mod (moving people around based on their buffs) is beyond what would be considered a core feature. I personally think that if you wanted features that sorted people by their role, then we would need a more static and foolproof method of looking at peoples talent specs (like the way Rock/CowTip does it or Proximo). I don't like the idea of a pally jumping around on my screen because he changed his aura, or a druid jumping around because he changed forms. I also don't know of another raid unit addon that has any role sorting features in it's core. So I don't think users expect that fuctionality to be in Grid's core either. But it's not really my call, I was asked to merge my code, and that's what I'm working on :)

    Someone did suggest supporting personal targets from oRA2 as a "tank type". I like this idea, but the problem is oRA2 doesn't trigger any events for personal targets. It is possible to add an option to create a custom group that you could add your raid members names to so they show up as an additional group but I'm not sure this should be a core feature either. I will leave that up to Pasta and crew to decide.


    Fritos:
    Grid does not have any oRA2 layouts by default. And if you were using the latest version of GridLayoutPlus, then your description wouldn't really fit (you do not pick layouts, you select options). What addon are you talking about? If it's an older version of GridLayoutPlus, please update and test the latest version.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid
    I committed a modified version of Grid in:

    /branches/Grid/AutoLayout/Grid/

    It's basically a merge of GridLayoutPlus with a restructured layout menu. If anyone is interested in testing it, that would be great. All comments welcome.
    Posted in: Grid & Grid2
  • 0

    posted a message on GridLayoutPlus
    I have the fix for this in the branch version of Grid (GridLayoutPlus merge temporarily called "AutoLayout"). If you want to try out that version, you are welcome to, but just remember it's an alpha version and will be changing a great deal before moving into trunk. If you do decide to try it out, please disable GridLayoutPlus.
    Posted in: Unit Frames
  • 0

    posted a message on GridLayoutPlus
    I have a few questions:

    1) Is the addon working fine in a normal scenario? You haven't told me yet.

    2) If you leave a raid and then join a new one, why would oRA2 keep the main tanks from the previous raid? That is not normal afaik.

    3) Was there a mix of Blizzard and oRA2 tanks being set by different people?
    Posted in: Unit Frames
  • 0

    posted a message on GridStatusHealPriority - Who should I be healing?
    I renamed this addon to make it less confusing as to it's purpose. GridStatusHealer was a bit too misleading. There are also some performance enhancements and bug fixes in the last commit as well.

    Make sure you remove your old GridStatusHealer directory from your addons folder.
    Posted in: Unit Frames
  • 0

    posted a message on BanzaiAlert - aggro notifications
    I really miss the "Aggro from (emeny)" text as well. I want to go back to the old version but that would be a pain in the ass. I don't understand the reasoning with taking it out. Maybe make it optional somehow with BanzaiAlert, but PLEASE please can you put it back in.
    Posted in: General AddOns
  • 0

    posted a message on GridLayoutPlus
    I committed a change to the raid assist tank code (oRA, CTRA) that should prevent this error. Please let me know how it works for you.
    Posted in: Unit Frames
  • To post a comment, please or register a new account.