API version 5: changes and discussion
Current changes:
- The license has been changed to MIT, from ARR. - oUF:UpdateElement(name) has been removed. This function has been replaced with element:ForceUpdate(). - element:Update() has been renamed element:Override() to correctly reflect what it actually does. - Elements no longer require element:GetParent() to return the oUF object. Elements now have a element.__owner which points towards self at enable. - Support for cataclysm has been added. - HealPredition element added. - HolyPower element added. - PhasingIcon element added. - SoulShards element added. - QuestIcon element added. - EclipseBar element added. - ReadyCheck element added. - oUF automatic frame name generator has been improved. It will no longer generate names such as: oUF_LilyPartyParty. - Elements no longer use the .Override function directly with the event system. - Support for blank parent frames on headers. - Added a third argument to the style function indicating if the frame was spawned from a header or not (isSingle). - Minor optimizations of common tag paths. - [defict:name] has been renamed [deficit:name]. - Added ['pereclipse'] tag. - tagfs.overrideUnit has been added. It basically tells the tag system that it should feed the "real" unit to the tag function as a second argument. - self.disallowVehicleSwap has been removed. Vehicle switching is now always enabled. - Sub-objects now correctly have self.id set. Known issues: - Headers: Due to how RegisterAttributeDrive works on 4.0.x, clicking _can_ go void on frames. The solution to this is to use self:RegisterForClicks('AnyDown') instead of AnyUp. Another solution is to NOT use the visibility field in :SpawnHeader(). - Portraits: On header frames this will constantly reset their animation due to the bug mentioned above Needs testing: - All of the new elements require as much testing and input as possible. Updating version 4 layouts to version 5: - Any use of oUF:UpdateElements(name) needs to be changed to element:ForceUpdate(). - Any use of element.Update needs to be renamed element.Override. - If you are checking for an automatically generated name in your style, then you might have to update this check. - All usage of restricted functions on secure frames (self:Set{Width,Height,Size,Attribute} and a ton other) need to be split into two parts, one of headers and one of single spawns. Code:
-- single units can be done within the style function: |
|
Quote:
It basically is what I tell people to treat the ARR license as. So there aren't exactly any changes. |
Quote:
It looks like some sort of problem with input handling for secure headers, though since you didn't list it maybe there's a workaround for that kind of behavior? |
I haven't been able to write a small test case on that yet, so I don't know if it's a general issue or something with oUF.
|
haste give me a hint. I currently stopped working on my layout because I thought 1.4.xx would be a version to go live with Cataclysm.
So I assume this is not the case? |
Quote:
The changes between 1.4.x and 1.5.x aren't exactly extensive on the surface, and they'll probably not get any worse than they currently are. |
I'm not sure if this is a 1.5 error or just user error (more likely), but since I'm only developing on the beta I can't really compare to any earlier version.
However, I want my partyframes to be shown even when I'm in a raid. Thus I spawn them using this: Code:
local party = self:SpawnHeader(nil, nil, 'party,raid', Apologies if this should've gone in it's own thread or someplace else. The elements for HolyPower and SoulShards works beautifully on the other hand, no problems at all so far. Only done limited testing on warlocks though. Incoming heals was working fine as well as far as I can tell. Is there any reason why a ReadyCheck-element isn't included in oUF itself, instead of relying on a plugin? Seems like a default thing to have available on any unitframe in my humble opinion. Not bashing p3lims plugin, just curious. I spend five minutes trying to find something about it in the elements-folder before figuring it wasn't included. :) |
Quote:
Removing showRaid = true, should be all you have to do. Quote:
Then there's the fact that no-one asked for it to be implemented and the fact that oUF_ReadyCheck was public when the ready check system didn't suck. |
Ah, that clears things up. Thanks!
|
I would like to see Ready Check being part of oUF's core, though. I don't know if it's just me, but It never seemed to update properly. At least hiding itself after a certain period of time - after someone performed a ready check - did not seem to work sometimes. And after all this is definitely an unit frame element. :)
Have you thought about giving party pets and all things alike an own .. err, term(?!) which can be used to address them, like you did with party and raid instead of the "GetPArent() .... whatever" thing it was in the past? I still think it's quite annoying that frames like party pets inherit all and everything from party and one has to "ClearAllPoints()" etc. everything to clean them up. But maybe I'm just doing it wrong - spawning them through xml, atm. :) |
Quote:
The following template should work fine, but I haven't gotten to test it yet: Code:
<Ui xmlns="http://www.blizzard.com/wow/ui/"> |
I forgot to comment on the Ready check part; I'll have a look at it.
|
Oh hai! With this commit unitsuffix information was added to the unit fed to the style function. I think I addressed all your questions with this :P.
|
So, I read through most of the secure group headers code today, and did a comparison against the LK version. The result was that I had to change quite a lot of stuff to make headers work correctly in combat in CC. I also removed the LK support code from 1.5. And I merged experimental into master.
The changes made aren't set in stone yet, so feel free to decipher the commits and give your feedback. I'll update the initial post when I feel it's more "stable". |
Ok, gonna test the 1.5 version next week. I guess the newly commited master is 1.5.x?
|
Quote:
You should note that master is currently a moving target, and I'm not entirely sure what changes I will (and have) to do yet. The changes should mainly be around how you call :SetAttribute() and other secure/protected functions. One of the current solutions is the 'oUF-initialConfigFunction' attribute, which allows you access to the secure function oUF uses to call the style function insecurely. The gain of this is that you have full secure access, as if you were called from the header directly. It's only used for header units however, not direct spawns. |
No biggy, but would you consider adding a threat tag that shows the percent value of threat of the current target. Or maybe changing the default tag to show UnitDetailedThreatSituation instead of just UnitThreatSituation?
Either
or
Not sure which one would make more sense. Probably threatpct. Code:
local _,_,threatpct,_,_ = UnitDetailedThreatSituation("player", "target") |
Feel free to create an issue about how there should be an threatpct tag :P.
|
Meh, forgot that the target is not optional for UnitDetailedThreatSituation like it is for UnitThreatSituation ... I'll think about it. :rolleyes:
|
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.
|
First post update, don't think I forgot anything. I'm still not pleased with the current solution.
|
I'm not pleased with warrior tanking talents. Not that anyone cares...;)
|
meh, druid no longer have a spamable AoE for tanking. boooooo.
The last boss in Stonecore would be soooo easy with the old swipe, but it is gone now :-/ |
Quote:
haste, yj, any ETA on 1.5 release? I'm not rushing, just asking. :) And no patch yet here in Europe, servers on Maintance now. 3:30 AM here. Better get to bed! ;P |
Imo this is 1.5.x
http://github.com/haste/oUF/zipball/master It still claims 1.4.3 but I think that is the 1.5 one. |
Quote:
|
You know software that is actually "final"?
|
Quote:
The thing is I tested the Github Master download on the Beta and somehow it wasn't showing any of my frames, not even with other layouts updated for it. So I was hoping for the actual 1.5 to test on live. But I downloaded the master again, going to try it again. :) |
I was fiddling about with the latest commit of 1.5 on the betaservers last night and stuff was working fine from what I could tell. If they weren't, it was because of me. :P I just made the changes Haste outlined in the now updated original post.
So hopefully all will be fine today when the servers come back up. |
With 1.5.1, I get this when I try to call RegisterStyle():
Code:
[19:39:13] Interface\AddOns\oUF_Nivaya\oUF_Nivaya.lua:897: attempt to index global 'oUF' (a nil value) **edit: Ok, got it. It was that XML error. |
So it was 1.5 and not 1.5.1 in other words :).
|
Quote:
|
Quote:
|
Quote:
But thanks. :p |
Quote:
Quote:
|
Meh, I'm going crazy porting to 1.5.
I'm getting "attempt to index global 'oUF' (a nil value)"... Before it worked fine, on 1.4. Any clues? It returns that error on this: Code:
oUF.colors.power = { I use namespaces for a config file, I use Code:
this: |
You're among those who had time to fetch oUF 1.5 before I pushed 1.5.1, I guess.
|
Quote:
|
CancelUnitBuff() tainted
Hi you all
Do we have anyway to create secure aura/buff/debuff buttons or are we locked out by Blizzard ? Currently this is how I create my Auras buttons: Code:
do -- setup buffs and debuffs |
You need to use the SecureAuraHeader to create player auras. I haven't had time to look much into it yet. It's on my TODO heap somewhere however.
|
All times are GMT -6. The time now is 09:30 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI