I'm getting my feet wet writing addons and between the frustration and headbashing, it's been fun. I'm working on a simple unit frame addon, and so far I've done the player and target frames (missing right click dropdown menu). Anyway, what I primarily need help with is setting up the raid frames. I tried using SecureGroupHeaderTemplate, but tbh, I didn't really understand it. So, what's the best way to set up some really basic raid frames?
I actually have that book, and I've followed the examples, including the one myrrodin is referring to. It didn't work though, so I figured Blizzard changed some things since the book's printing (May 2008 ). Thanks for the links, Orion, I'll check them out.
So, what's the best way to set up some really basic raid frames?
and from oUFs description
oUF is a unit frame framework. It attempts to simplify the process of writing unit frames for WoW by doing all the trivial and painfully boring parts for you. So you can focus more on experimenting with the look of the frames.
I'm pretty sure oUF will help simplify or assist in creating raid frames.
The main trouble with oUF is that it lacks some comprehensive docs (or an easy way to find them ; I couldn't). Once you understand how it works, it actually simplifies things, as it provides a lot of simple frame "elements" to add to your layout.
Assuming you know and understand how secure frames work, and, if you made Player and Target Frame, that should be a correct assumption, you only have a little bit of knowledge missing to be able to have workig raid frames.
There are basically two strategies to create raid frames. PitBull 3 (probably 4 too, but I haven't checked) or oUF will create frames beforehand and only show the one which have a valid unit. They don't need a SecureGroupHeaderTemplate to do that.
The other strategy is to let a SecureGroupHeaderTemplate frame do the creation and layout of your raid frames for you. That is what Grid (and Grid2) does. A SecureGroupHeaderTemplate is a special kind of secure frame, which is controlled through a handful of specific attributes. The template will create and affect units to unit frames as needed by the raid group and will perform the layout as instructed by the attributes you set.
Because it's a secure frame, you can only change its attributes out of combat.
The list of attributes is available from FrameXML's source code here.
"template" is important. You can set your own template using XML or use a default template like SecureUnitButton, and provide an initialization function by setting the frame's "initialConfigFunction" key to a callable object. Note that this is not an attribute of the header :
local f = CreateFrame("Frame", UIParent, nil, "SecurePartyHeaderTemplate")
f.initialConfigFunction = function (unitFrame)
-- Note that you CAN call :SetAttribute() on unitFrame in this function even in combat.
oUF does use what you tell it to use, e.g. SecureGroupHeaderTemplate if you want to. In this case, oUF takes care of setting up the header to apply your layout to the created unit frames. You still have to layout your different headers. Sample code:
-- define and select your oUF style here
-- single unit
local player = oUF:Spawn("player", "oUF_MyPlayerFrame")
-- party group
local party = oUF:Spawn("header", "oUF_MyParty")
party:SetManyAttributes("showParty", true, "groupFilter", 1)
oUF will create frames beforehand and only show the one which have a valid unit. They don't need a SecureGroupHeaderTemplate to do that.
Uh... oUF uses the templates....
Creating unitframes isn't as horribly tainty as everyone is making it out to be. The only frame you have to worry about is the base frame, and the header will make that for you. Everything else is just layering bars and fontstrings and icons on top of that base frame, none of which are secure. oUF just provides you with all the logic to update those elements, you just have to create, position and format them.
Remember to unregister UNIT_NAME_UPDATE from your inherited headers or you may get raid frame lockup issues when people join/leave the raid (especially when zoning into a BG). Google for "UNIT_NAME_UPDATE" and "Xinhuan" to find out more.
Some weeks ago I experienced noticeable freezes (e.g. almost a second) in Alterac. Everything was running fine beside that. I've looked up for the addon that caused this (by disabled them one by one until the freezes ceased) and found that Grid was responsible for it. I enabled all addons but Grid and everything was ok. Then I enabled Grid and freezes started to happen again. Unregistering UNU in Grid frame initialization fixed the issue. IMO not all unit frames are impacted the same way by UNU spam but Grid is very bad at it.
Then I enabled Grid and freezes started to happen again. Unregistering UNU in Grid frame initialization fixed the issue. IMO not all unit frames are impacted the same way by UNU spam but Grid is very bad at it.
Grid uses unit name as identifier, so there's no real fix here. UNIT_NAME_UPDATE is very expensive for Grid. Grid2 uses unitid, so will be a lot less impacted by UNIT_NAME_UPDATE spam. In fact, if no indicator is connected to the name status, the event is not even registered.