This one actually works for player, party, etc.
Code:
oUF.Tags["threatpercent"] = function(unit) |
Quote:
It is also something that needs to be set in the layout, rather than as a default within the Tag element. |
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) Code:
self.Portrait.PostUpdate = Portrait_PostUpdate 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? :rolleyes: Btw, I want to suggest for 1.5 to hide non existent portraits, instead of showing the question mark. :) |
Quote:
Do you think the performance hit is big when using frequent updates like that on all raid units just on health? |
Quote:
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. Quote:
Quote:
Quote:
|
You don't like portraits, do you?! :D
Sorry for bugging you with them on every API change, but hey... for some reason they always get borked. It's not me! :o Quote:
Quote:
|
Quote:
|
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) thx in advance |
Read the code or wait.
|
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 ); EDIT: The portraits aren't merely flickering, they appear to be resetting themselves constantly. The animation constantly restarts, several times each second. |
Quote:
This is the same issues that causes OnMouseUp events to go void on the header frames, which pretty much makes them ignore your clicks. |
Quote:
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. |
Quote:
A hack to solve this is to register AnyDown instead of AnyUp. |
Quote:
By adding to my CreateUnitFrame function Code:
self:SetAttribute("*type1", "target") 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. |
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) Code:
showRaid = [BOOLEAN] -- true if the header should be shown while in a raid |
@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) Also, a note to haste, for element/vehicle.lua Code:
self:SetAttribute('toggleForVehicle', true) |
Hopefully that does not mean that changing vehicle units in combat is impossible.
|
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. |
Quote:
Time for the next question, will use of that XML templete solve the "missing" Code:
self.id Code:
ToggleDropDownMenu(1, nil, _G["PartyMemberFrame"..self.id.."DropDown"], "cursor") |
That's a bug actually.
|
All times are GMT -6. The time now is 07:51 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI