Thread Tools Display Modes
10-03-10, 04:39 PM   #21
Dawn
A Molten Giant
 
Dawn's Avatar
AddOn Author - Click to view addons
Join Date: May 2006
Posts: 918
This one actually works for player, party, etc.

Code:
oUF.Tags["threatpercent"] = function(unit)
    local _,_,threatpct,_ ,_ = UnitDetailedThreatSituation(unit, "target")
    if threatpct and UnitExists("target") then
        return floor(threatpct + 0.5)
    else
        return
    end
end
oUF.TagEvents["threatpercent"] = "UNIT_THREAT_SITUATION_UPDATE UNIT_THREAT_LIST_UPDATE PLAYER_TARGET_CHANGED"
Not sure how to make it update more frequently, though. Maybe a tag just isn't the right thing for this after all.
__________________
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

"neeh the game wont be remembered as the game who made blizz the most money, it will be remembered as the game who had the most QQ'ers that just couldnt quit the game for some reason..."

  Reply With Quote
10-03-10, 05:23 PM   #22
yj589794
A Rage Talon Dragon Guard
AddOn Author - Click to view addons
Join Date: Mar 2009
Posts: 314
Originally Posted by Dawn View Post
Not sure how to make it update more frequently, though. Maybe a tag just isn't the right thing for this after all.
Tags do support the .frequentUpdates parameter but this can affect CPU usage, especially if something like this is applied to all raid units.
It is also something that needs to be set in the layout, rather than as a default within the Tag element.
  Reply With Quote
10-04-10, 01:16 PM   #23
Dawn
A Molten Giant
 
Dawn's Avatar
AddOn Author - Click to view addons
Join Date: May 2006
Posts: 918
I have an issue with portraits. On live, I'm setting an alpha and force it to update and set the camera position (0). Otherwise alpha and camera setting will "bug out". Aka alpha resets to 1 and stays @1. Camera resets to full body view (2, afaik).

Anyway, I fixed this with the following function (on live).
Code:
local Portrait_PostUpdate = function(Portrait, unit)
	if (not UnitExists(unit) or not UnitIsConnected(unit) or not UnitIsVisible(unit)) then
		Portrait:Hide()
	else
		Portrait:Show()
		Portrait:SetCamera(0)
		Portrait:SetAlpha(cfg.pAlpha)
	end
end
Code:
self.Portrait.PostUpdate = Portrait_PostUpdate
This works ace on live, but beta once again ****s it up.

I tried to set an alpha without using the function. Doesn't work at all
I tried to self.Portrait.Override = Portrait_PostUpdate. Which hides the frames that have a portrait, no lua error.

Some things to note:
Directly setting an alpha without the update function doesn't work, but it works with it - for player (model never changes, alpha stays the same) and initially also for the target, but no longer after the first switch. Which inditactes to me that it's called at least once, but not updated.

Long story short, what am I doing wrong?


Btw, I want to suggest for 1.5 to hide non existent portraits, instead of showing the question mark.
__________________
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

"neeh the game wont be remembered as the game who made blizz the most money, it will be remembered as the game who had the most QQ'ers that just couldnt quit the game for some reason..."

  Reply With Quote
10-04-10, 07:12 PM   #24
neverg
A Frostmaul Preserver
 
neverg's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2007
Posts: 268
Originally Posted by yj589794 View Post
Tags do support the .frequentUpdates parameter but this can affect CPU usage, especially if something like this is applied to all raid units.
It is also something that needs to be set in the layout, rather than as a default within the Tag element.
I use frequentupdates set to 0.1 on live for my Raid Frames Health, because health update lag is really bad with a bit of lag on top. That is why I used quickhealth with Grid (prior to oUF) and I really noticed the difference.

Do you think the performance hit is big when using frequent updates like that on all raid units just on health?
__________________
My oUF Layout: oUF Lumen
  Reply With Quote
10-04-10, 11:41 PM   #25
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by neverg View Post
I use frequentupdates set to 0.1 on live for my Raid Frames Health, because health update lag is really bad with a bit of lag on top. That is why I used quickhealth with Grid (prior to oUF) and I really noticed the difference.

Do you think the performance hit is big when using frequent updates like that on all raid units just on health?
I'm not sure if you are thinking of tags now, or the actual health element. Both support frequentUpdates, but they work slightly different.

On the tags you are able to do frequentUpdates = .1, which pretty much means "call my tag function ten times a second". You'll probably not notice too much of an difference with this, but it depends on quite a lot of factors.

On the health element you only have the option of having it on or off. When it's enabled oUF compares the previous value with the current, and if it's different it triggers the update function. The update loop that does this isn't throttled and checks for updates every (1/fps) second.

Tags aren't that bad however, they are about 40-60% slower than hand-writing the update function. They do generally use more memory however. The reason it's throttled differently is mainly because we don't have any other option.

Originally Posted by Dawn View Post
I have an issue with portraits. On live, I'm setting an alpha and force it to update and set the camera position (0). Otherwise alpha and camera setting will "bug out". Aka alpha resets to 1 and stays @1. Camera resets to full body view (2, afaik).

Anyway, I fixed this with the following function (on live).
Code:
local Portrait_PostUpdate = function(Portrait, unit)
	if (not UnitExists(unit) or not UnitIsConnected(unit) or not UnitIsVisible(unit)) then
		Portrait:Hide()
	else
		Portrait:Show()
		Portrait:SetCamera(0)
		Portrait:SetAlpha(cfg.pAlpha)
	end
end
Code:
self.Portrait.PostUpdate = Portrait_PostUpdate
This works ace on live, but beta once again ****s it up.

I tried to set an alpha without using the function. Doesn't work at all
I tried to self.Portrait.Override = Portrait_PostUpdate. Which hides the frames that have a portrait, no lua error.
.Override is an event function. It's called as: func(self, event, ...).

Originally Posted by Dawn View Post
Some things to note:
Directly setting an alpha without the update function doesn't work, but it works with it - for player (model never changes, alpha stays the same) and initially also for the target, but no longer after the first switch. Which inditactes to me that it's called at least once, but not updated.

Long story short, what am I doing wrong?
It means that the model widget has changed again, but I don't know to what extent. I have to take a look at it myself, which I don't think I'll be able to do today.

Originally Posted by Dawn View Post
Btw, I want to suggest for 1.5 to hide non existent portraits, instead of showing the question mark.
Or just leave it as it is :P
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-05-10, 09:16 AM   #26
Dawn
A Molten Giant
 
Dawn's Avatar
AddOn Author - Click to view addons
Join Date: May 2006
Posts: 918
You don't like portraits, do you?!

Sorry for bugging you with them on every API change, but hey... for some reason they always get borked. It's not me!

Or just leave it as it is :P
I'm fine with that, as long as setting an alpha works (which also allows me to hide them myself on those conditions).


.Override is an event function. It's called as: func(self, event, ...).
Mhm, I'll try that.
__________________
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

"neeh the game wont be remembered as the game who made blizz the most money, it will be remembered as the game who had the most QQ'ers that just couldnt quit the game for some reason..."

  Reply With Quote
10-05-10, 03:02 PM   #27
neverg
A Frostmaul Preserver
 
neverg's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2007
Posts: 268
Originally Posted by haste View Post
I'm not sure if you are thinking of tags now, or the actual health element. Both support frequentUpdates, but they work slightly different.

On the tags you are able to do frequentUpdates = .1, which pretty much means "call my tag function ten times a second". You'll probably not notice too much of an difference with this, but it depends on quite a lot of factors.

On the health element you only have the option of having it on or off. When it's enabled oUF compares the previous value with the current, and if it's different it triggers the update function. The update loop that does this isn't throttled and checks for updates every (1/fps) second.

Tags aren't that bad however, they are about 40-60% slower than hand-writing the update function. They do generally use more memory however. The reason it's throttled differently is mainly because we don't have any other option.
P
Thanks for clarifiying this, haste. I thought you throtle health updates too. Thanks for the clarification.
__________________
My oUF Layout: oUF Lumen
  Reply With Quote
10-07-10, 10:21 AM   #28
senomar
A Defias Bandit
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 3
i have no luck spawning the raid/party frames with 1.5

this works with 1.4.x on live:
Code:
oUF:Factory(function(self)
	self:SetActiveStyle('my_raid')
	local raid = {}
	local group = self:SpawnHeader(nil, nil, 'raid,party',
		'showParty', true,
		'showPlayer', true,
		'yOffset', -5,
		'showRaid', true,
		'groupFilter', '1'
	)
	table.insert(raid, group)
	group:SetPoint('TOPLEFT', UIParent, 20, -15)
	for i = 2, 8 do
		local group = self:SpawnHeader(nil, nil, 'raid,party',
			'yOffset', -5,
			'showRaid', true,
			'groupFilter', tostring(i)
		)
		group:SetPoint('TOP', raid[i-1], 'BOTTOM', 0, -20)
		table.insert(raid, group)
	end
end)
any clues?
thx in advance
  Reply With Quote
10-07-10, 10:33 AM   #29
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Read the code or wait.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-09-10, 04:17 PM   #30
Goldpaw
A Wyrmkin Dreamwalker
AddOn Author - Click to view addons
Join Date: Sep 2007
Posts: 56
I have a different problem with portraits on party frames; they flicker.

Constant flickering for no apparent reason at all. I also have portraits on player/target frames, and they don't flicker. So far it appears to only be an issue with the party frames. Not sure if it this also happens on raid/arena frames.

The code I use to display it is very straight forward, no hokus pokus that can explain the behavior I'm getting;
Code:
      local Portrait = CreateFrame( "PlayerModel", nil, self );
      Portrait:SetPoint("TOP", self, "TOP", 0, 0);
      Portrait:SetPoint("BOTTOM", self, "BOTTOM", 0, 0);
      Portrait:SetPoint("RIGHT", self, "LEFT", self:GetHeight(), 0);
      Portrait:SetPoint("LEFT", self, "LEFT", 0, 0);

      self.Portrait = Portrait;
Is this something you're aware of or am I the only one experiencing this?

EDIT:
The portraits aren't merely flickering, they appear to be resetting themselves constantly. The animation constantly restarts, several times each second.

Last edited by Goldpaw : 10-09-10 at 04:45 PM.
  Reply With Quote
10-10-10, 12:57 AM   #31
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Goldpaw View Post
I have a different problem with portraits on party frames; they flicker.

Constant flickering for no apparent reason at all. I also have portraits on player/target frames, and they don't flicker. So far it appears to only be an issue with the party frames. Not sure if it this also happens on raid/arena frames.

The code I use to display it is very straight forward, no hokus pokus that can explain the behavior I'm getting;
Code:
      local Portrait = CreateFrame( "PlayerModel", nil, self );
      Portrait:SetPoint("TOP", self, "TOP", 0, 0);
      Portrait:SetPoint("BOTTOM", self, "BOTTOM", 0, 0);
      Portrait:SetPoint("RIGHT", self, "LEFT", self:GetHeight(), 0);
      Portrait:SetPoint("LEFT", self, "LEFT", 0, 0);

      self.Portrait = Portrait;
Is this something you're aware of or am I the only one experiencing this?

EDIT:
The portraits aren't merely flickering, they appear to be resetting themselves constantly. The animation constantly restarts, several times each second.
This is due to a bug with RegisterAttributeDrive, which is used to handle showing/hiding of the header frame based on conditions. If you disable the visibility function on your header it should behave normal.

This is the same issues that causes OnMouseUp events to go void on the header frames, which pretty much makes them ignore your clicks.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-10-10, 08:31 PM   #32
Zilver
A Fallenroot Satyr
 
Zilver's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2006
Posts: 29
Question

Originally Posted by haste View Post
This is the same issues that causes OnMouseUp events to go void on the header frames, which pretty much makes them ignore your clicks.
Is this why I currently can't target any party unit's by clicking the party unit frame ?

If this isn't the case I think I'm gonna need help sorting that out, but get back to me on this, I'll then post code if needed.
  Reply With Quote
10-10-10, 11:23 PM   #33
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Zilver View Post
Is this why I currently can't target any party unit's by clicking the party unit frame ?

If this isn't the case I think I'm gonna need help sorting that out, but get back to me on this, I'll then post code if needed.
You should still be able to click them, but it would require 1+ clicks as you can get unlucky and hit it when the frame ignores them.

A hack to solve this is to register AnyDown instead of AnyUp.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-11-10, 12:15 AM   #34
Zilver
A Fallenroot Satyr
 
Zilver's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2006
Posts: 29
Originally Posted by haste View Post
You should still be able to click them, but it would require 1+ clicks as you can get unlucky and hit it when the frame ignores them.

A hack to solve this is to register AnyDown instead of AnyUp.
Had a go at it again here this morning, after looking through the Spawn & SpawnHeader code I eventually ended up in initialConfigFunction ...

By adding to my CreateUnitFrame function
Code:
self:SetAttribute("*type1", "target")
I now again have the ability to target party units.

Edit: Should this not be set in initialConfigFunction ? when spawning a player you don't need to set it (oUF does set it), but spawning a party you do need to set it (oUF doesn't set it)

Must have still been sleeping, in my first attempt I couldn't get 'self:SetAttribute("*type1", "target")' by adding it to my CreateUnitFrame function, but after looking again I figured out that I was simple adding it to the wrong file, so remember guys 'n girls check you are writing to the right files.

Last edited by Zilver : 10-11-10 at 12:30 AM.
  Reply With Quote
10-11-10, 12:27 AM   #35
zork
A Pyroguard Emberseer
 
zork's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 1,740
Time will tell. 4.0.1 is coming this week. Which version of oUF is gonna work there?

@haste
How do I disable the visibily function of my party header?

What I found is your test on the StateDriver which has some info on the visibility.
http://github.com/haste/RegisterStat...atsmyinput.lua

If anyone wants to know how to adjust the initialConfigFuntion needed for header created frames, do:
Code:
local initialConfigFunction(self)
  self:SetWidth()
  self:SetHeight()
  self:SetScale()
end
header.initialConfigFunction = initialConfigFunction
Regarding attributes
Code:
showRaid = [BOOLEAN] -- true if the header should be shown while in a raid
showParty = [BOOLEAN] -- true if the header should be shown while in a party and not in a raid
showPlayer = [BOOLEAN] -- true if the header should show the player when not in a raid
showSolo = [BOOLEAN] -- true if the header should be shown while not in a group (implies showPlayer)
nameList = [STRING] -- a comma separated list of player names (not used if 'groupFilter' is set)
groupFilter = [1-8, STRING] -- a comma seperated list of raid group numbers and/or uppercase class names and/or uppercase roles
strictFiltering = [BOOLEAN] - if true, then characters must match both a group and a class from the groupFilter list
point = [STRING] -- a valid XML anchoring point (Default: "TOP")
xOffset = [NUMBER] -- the x-Offset to use when anchoring the unit buttons (Default: 0)
yOffset = [NUMBER] -- the y-Offset to use when anchoring the unit buttons (Default: 0)
sortMethod = ["INDEX", "NAME"] -- defines how the group is sorted (Default: "INDEX")
sortDir = ["ASC", "DESC"] -- defines the sort order (Default: "ASC")
template = [STRING] -- the XML template to use for the unit buttons
templateType = [STRING] - specifies the frame type of the managed subframes (Default: "Button")
groupBy = [nil, "GROUP", "CLASS", "ROLE"] - specifies a "grouping" type to apply before regular sorting (Default: nil)
groupingOrder = [STRING] - specifies the order of the groupings (ie. "1,2,3,4,5,6,7,8")
maxColumns = [NUMBER] - maximum number of columns the header will create (Default: 1)
unitsPerColumn = [NUMBER or nil] - maximum units that will be displayed in a singe column, nil is infinate (Default: nil)
startingIndex = [NUMBER] - the index in the final sorted unit list at which to start displaying units (Default: 1)
columnSpacing = [NUMBER] - the ammount of space between the rows/columns (Default: 0)
columnAnchorPoint = [STRING] - the anchor point of each new column (ie. use LEFT for the columns to grow to the right)
__________________
| Simple is beautiful.
| WoWI AddOns | GitHub | Zork (WoW)

"I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)

Last edited by zork : 10-11-10 at 12:43 AM.
  Reply With Quote
10-11-10, 01:38 AM   #36
tukz
A Fallenroot Satyr
 
tukz's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2009
Posts: 20
@zork: don't know if it's the best way to do it but i made my party/raid spawning look like this:

example with my 3 groups raid file.

Code:
oUF:RegisterStyle('TukuiHealR01R15', Shared)
oUF:Factory(function(self)
	oUF:SetActiveStyle("TukuiHealR01R15")

	local raid = self:SpawnHeader("oUF_TukuiHealRaid0115", nil, "custom [@raid16,exists] hide;show", 
	'oUF-initialConfigFunction', [[
		local header = self:GetParent()
		self:SetAttribute('*type1', 'target')
		self:SetWidth(header:GetAttribute('initial-width'))
		self:SetHeight(header:GetAttribute('initial-height'))
		self:SetAttribute('toggleForVehicle', true)
		RegisterUnitWatch(self)
	]],
	'initial-width', TukuiDB.Scale(150*TukuiDB.raidscale),
	'initial-height', TukuiDB.Scale(32*TukuiDB.raidscale),	
	"showParty", true, "showPlayer", TukuiCF["unitframes"].showplayerinparty, "showRaid", true, "groupFilter", "1,2,3,4,5,6,7,8", "groupingOrder", "1,2,3,4,5,6,7,8", "groupBy", "GROUP", "yOffset", TukuiDB.Scale(-4))
	raid:SetPoint("TOPLEFT", UIParent, "TOPLEFT", 15, -300*TukuiDB.raidscale)
end)
At least, it's working fine for me.

Also, a note to haste, for element/vehicle.lua
Code:
self:SetAttribute('toggleForVehicle', true)
need to be changed, it taint UI while a new unit is entering raid and while we are in combat. I just commented this line in vehicle.lua for now.

Last edited by tukz : 10-11-10 at 01:45 AM.
  Reply With Quote
10-11-10, 01:59 AM   #37
zork
A Pyroguard Emberseer
 
zork's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 1,740
Hopefully that does not mean that changing vehicle units in combat is impossible.
__________________
| Simple is beautiful.
| WoWI AddOns | GitHub | Zork (WoW)

"I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)
  Reply With Quote
10-11-10, 08:20 AM   #38
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Being lazy here:
@Zilver: Yes it's missing. I'm not entirely satisfied with how initialConfigFunction currently is used, and I'm mainly focusing on separately spawned sub-frames, which currently do that through the XML template as shown earlier.

@zork:
"Time will tell. 4.0.1 is coming this week. Which version of oUF is gonna work there?"
1.5.x
and
No, that's the wrong use of initialConfigFunction. Use oUF-initialConfigFunction as tukz does. See below.

@tukz: toggleForVehicle is going to be set on "all" frames with 1.5.x. I mentioned it somewhere else that I'm killing disallowVehicle switch.

You can use oUF-initialConfigFunction like you do, but please keep a track on the changes made to oUFs git before posting code.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-11-10, 01:21 PM   #39
Zilver
A Fallenroot Satyr
 
Zilver's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2006
Posts: 29
Originally Posted by haste View Post
@Zilver: Yes it's missing. I'm not entirely satisfied with how initialConfigFunction currently is used, and I'm mainly focusing on separately spawned sub-frames, which currently do that through the XML template as shown earlier.
Aagh ok I see, I somehow overlooked the XML template you posted when reading through the thread.

Time for the next question, will use of that XML templete solve the "missing"
Code:
self.id
... I need it for
Code:
ToggleDropDownMenu(1, nil, _G["PartyMemberFrame"..self.id.."DropDown"], "cursor")
I found a way to get it from the "oUF:Spawn" code but haven't found a good place to create the self.id except from the menu that needs it, any suggestions?
  Reply With Quote
10-11-10, 01:29 PM   #40
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
That's a bug actually.
__________________
「貴方は1人じゃないよ」
  Reply With Quote

WoWInterface » Featured Projects » oUF (Otravi Unit Frames) » API version 5: changes and discussion

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off