• 0

    posted a message on Unofficial oUF - methods used for layouts
    Quote from zariel »

    exactly, thats the way i wrote mine


    What happens if no one in the raid is targeting the questioned mob?
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Regarding the aggro updates...

    After taking a quick look at LibBanzai, a fairly simple solution is this: Check for a unit's target, grab it's targettarget and see if both are equal. So the provided code is essentialy what LibBanzai does, except we're comparing unit names instead of table entries.

    	function sUF:UpdateAggro()
    		local unit = self.unit
    		local target = unit.."target"
    		if UnitExists(target) then
    			local targettarget = target.."target"
    			if UnitExists(targettarget) then
    				if UnitName(unit) == UnitName(targettarget) and UnitCanAttack(target, unit) then
    					-- do something
    				end
    			end
    		else
    			-- set back to default
    		end
    	end


    Tested for a few minutes in alterac valley and worked out fine so far.

    Forgot to mention that this function is attached to the raid's OnUpdate handler... :D
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Depends. Since most functions using/returning the fully capitalized english name, i'm not sure if it would be worth it to implement a localization table only used once. It's just easier to do it manually here in my eyes.
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Quote from zork_tdmog »

    I tried the group sorting again and with all three values applied I get a SecureHeader Error. Has anyone a working raid sort per class?


    What's the exact error message?
    By guessing i would say it's just a localization problem, since you use a deDE client, right?
    In this case try renaming WARRIOR to Krieger, MAGE to Magier and so on.
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Quote from Moon Witch »

    PS. Stupid question. But in AV, I need to see the UFs of all team mates, doesn't matter if they're dead/alive/out of range. I still need to see them, seeing as I am the healer :P But my raid frames hide themselves there, which is normal blizzard behavior. Yet Grid can show them all, why is this? And how does oUF handle it? (I have seen pelim's screenie in AV, which showed unitframes, but does it show ALL members? Or is it toned down to 25?


    groupFilter = "1, 2, 3, 4, 5, 6, 7, 8",


    This specifies the groups show in the layout. The example is set to display all 40 members. Since this is also the default value, it's equal to deleting the attribute from your layout function.
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Anyway, i've experienced a little bug while testing my current version. Every time i mouseover an unit in my raid frames which is offline, i get the chat message "No player named "blabla" is currently playing." Not everytime, only the first time i mouseover the specific unit. Anyone know what's causing this or any solution how to fix this? It's not like it's a game breaking issue, but it's kinda disturbing.
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Ok. I see if i might add this in my next release, merging those two approches into one. Maybe setting the update interval up to a few seconds because .5 seems a little bit too low, affecting performance etc. ...
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Quote from p3lim »

    does this check the range against each invidual unit? if not its just pointless.

    one thing is the issue with the updater (but i think your code works sciet, just add a table for it)

    another issue is that it checks the range against your current target, not an invidual raid unit..


    1. Yes, since each unit button in the raid is attached with the script.
    2. Tested in a battleground and worked fine as i said.
    3. What's leading to this assumption?

    Or are you talking about another approach? Little bit confused at the moment because i'm typing this while raiding ssc... :D
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    @ Moon Witch

    Is your range update function still attached to another one like updateHealth, updatePower etc.?
    I'm asking because this would mean that if the health, power etc. of an unit doesn't change, then range update won't work either. If this is the case, then merging those two approches would be a good idea.
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Here is a quick fix for this range thing...

    local rupdateTime = 0                        -- add this to the top section of ouf.lua
    local rupdateInterval = .5
    
    if object:GetParent():GetName() == "raid" then           -- add this to initObject(..) in ouf.lua
    	object:SetScript("OnUpdate", function(self, elapsed)
    		rupdateTime = rupdateTime + elapsed
    		if rupdateTime > rupdateInterval then
    			local inRange = IsSpellInRange("Arcane Intellect", self.unit) 
    			if inRange == 1 then 
    				self:SetAlpha(1) 
    			else 
    				self:SetAlpha(.2) 
    			end
    			rupdateTime = 0
    		end
    	end)
    end


    Make sure to replace "raid" in the first line of the update function with whatever your raid header is called. That's the second argument in CreateFrame(..) in oUF:Spawn(..) under elseif unit == "raid" then. You might also replace "Arcane Intellect" in IsSpellInRange(..) with something suitable for your class.
    I'm not sure if it's wise or efficient to do it this way, but it works fine for me. Tested in a battleground for a few minutes and everthing updated in the right way.
    Credits to LA-Techno[dc2k] for the initial idea to use an OnUpdate script to get this working. :D
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    groupBy = [nil, "GROUP", "CLASS", "ROLE"] - specifies a "grouping" type to apply before regular sorting (Default: nil)


    groupBy is your friend here... :D

    Edit:
    groupFilter = [1-8, STRING] -- a comma seperated list of raid group numbers and/or uppercase class names and/or uppercase roles
    groupingOrder = [STRING] - specifies the order of the groupings (ie. "1,2,3,4,5,6,7,8")


    Seems like these attributes are connected with each other. So if you define groupBy, you also have to define the others to make it work. :D
    Just use the values provided with the example you found and it will work.
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Quote from Stapedius »

    It is not possible to spawn individual raidgroups at the moment?

    This issue will come up a lot since in some Raid/BG situations groups are not full and everything would be kind of messed then. It?s not that uncommon that for some time during a raid for axample a melee group spot will be free until someone shows up.


    What we are doing so far is this: we are settings up a header, "SecureRaidGroupHeaderTemplate", with 40 individual slots attached to it. When people joining the raid each slot is filled with a "SecureUnitButtonTemplate" one after another. The only connecting between these is the anchoring given with specific attributes.
    A solution might be to fill the header with "SecurePartyHeaderTemplate" first, then filling those groups with the unit buttons mentioned before. Or creating individual headers for each party and attach them to one another. Not quiet sure if the header offers handling for such a setup by default or if you have to write your own handler dealing with the roster updates.
    Going to test this and see if it works.

    Edit: Quick test in av went pretty bad. Errors several hundred times and the result is the same as before. Grid itself however, as far as i can see, does this by creating individual headers for each party available as mentioned before. And of course overwriting/redefinig all those function responsible for roster updates und layout issues. :D
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Just to clarify a few things...

    - point : sets the attachment point within a group
    - point = "TOP" means thisGroupMember:SetPoint("TOP", previousGroupMember, "BOTTOM", multiX * xOffset, multiY * yOffset)
    - point = "BOTTOM" means thisGroupMember:SetPoint("BOTTOM", previousGroupMember, "TOP", multiX * xOffset, multiY * yOffset)
    - and so forth...

    - columnAnchorPoint : sets the attachment point between groups
    - columnAnchorPoint = "LEFT" means firstMemberThisGroup:SetPoint("LEFT", firstMemberPreviousGroup, "RIGHT", multiX * columnSpacing, multiY * columnSpacing)
    - and so forth...

    So basically, raid2 is attached to raid1, raid3 to raid2, raid4 to raid3 and raid5 to raid4. raid6, because we open up a new group/column here, is therefore attached to raid1, raid11 to raid6 and so on..
    multiX and multiY are internal values e.g. 0, 1 and -1, calculated in SecureTemplates.lua.

    Another point, as far as i can see, is that there is no possibility by just using SecureRaidGroupHeaderTemplate, to prevent it from filling a half full column before opening a new one. So, if there are 10 people in a raid, 3 in group1, 3 in group2 and 4 in group3, it will display 2 full columns with 5 members each.

    Hope this helps.

    By the way...
    Quote from haste »
    damn 1px issue
    :D
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Quote from lymphatik »

    Adde this one in updatename to get rid of the trouble with health overlapping name in grid mimic. How ever I don't know what happen if someone as a nickname with two letter. :(


    Nothing special. "Ae" will remain "Ae". But iirc this may cause problems with special characters.

    Quote from Cyanix »

    How did you manage to add class coloring to your unit frames ?


    local color = UnitIsPlayer(unit) and RAID_CLASS_COLORS[select(2, UnitClass(unit))] or UnitReactionColor[UnitReaction(unit, "player")]
    if (color) then bar:SetStatusBarColor(color.r, color.g, color.b) end


    Taken from updatePower(..) in layout.lua
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Quote from LA-Techno[dc2k »
    ]
    Thanks Sciet

    can?t wait too test the grid layout.
    How can i set the group horizontal not vertically ?


    		rshowRaid = true,
    		rpoint = "TOP",
    		rsortDir = "ASC",
    		ryOffset = -3,
    		rxOffset = 0,
    		rgroupFilter = "1, 2, 3, 4, 5, 6, 7, 8",
    		rsortMethod = "NAME",
    		rgroupBy = "GROUP",
    		rgroupingOrder = "1, 2, 3, 4, 5, 6, 7, 8",
    		rmaxColumns = 8,
    		runitsPerColumn = 5,
    		rcolumnSpacing = 3,
    		rcolumnAnchorPoint = "LEFT",




    Quote from p3lim »

    also, sciet, mind posting a more updated version of your sUF please? wanna see what youve done to the core :p


    Currently a bit unsatisfied how things work out so far. Going to fix this within the next few days and posting an update.
    Posted in: Unit Frames
  • To post a comment, please or register a new account.