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.

http://github.com/haste/oUF/commit/b...3e15fceb015647

It basically is what I tell people to treat the ARR license as. So there aren't exactly any changes.

Hm, what about that issue with party/raid frames I told you about a week ago, where you get "sluggish" response from clicking on raid and party units.

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?

The initial plan was to keep 1.4.x going a good while. There was some minor annoyances with 1.4.x that were reported shortly after it was pushed however, and I decided that I might as well break the API with Cataclysm coming.

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:

This is pretty much based on the boilerplate for 1.4. However, when I have showRaid set to 'true', it creates the partyframe as a raidbutton and since I'm not doing any specific stylings to any raidframe it turns out all weird-looking. This was tested by adding solo to visibility and adding showPlayer = true and showSolo = true. But I first noticed it when I joined a party. I didn't want to file it as a bug because it's very possible I'm either doing it wrong or assuming it's going to work in another way then it really does.

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. :)

showRaid = true toggles if the header should create raid frames or not. The visibility string controls if the header should be shown or hidden.

Removing showRaid = true, should be all you have to do.


Initially the ready check system was completely useless compared to the add-on alternatives. You had to wait 30 (or was it 60?) seconds until you got any information about what people clicked. Compared to the add-ons that gave you the information instantly.

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. :)

Take a look at the experimental branch. It's there to solve exactly what you're asking for. I explained some of it in the commit.

The following template should work fine, but I haven't gotten to test it yet:
Do notice that the above template lacks anchoring, as that's pretty much up to you. It's also possible to implement this with the current 1.4.x/1.5.x code, but it's a bit more PITA.

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?

Yes, master has been 1.5.x since early September.

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

• threatpct: Number - returns the unit's threat on the mob as a percentage of the amount required to pull aggro, scaled according to the unit's range from the mob. At 100 the unit will pull aggro. Returns 100 if the unit is tanking and nil if the unit is not on the mob's threat list.

or

• rawthreatpct: Number - returns the unit's threat as a percentage of the tank's current threat. Returns nil if the unit is not on the mob's threat list.

Not sure which one would make more sense. Probably threatpct.

I know this could be done by authors them self, but I think the current threat tag is not that, err ... versatile/informative. :)

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.

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.

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).
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? :rolleyes:


Btw, I want to suggest for 1.5 to hide non existent portraits, instead of showing the question mark. :)

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.

.Override is an event function. It's called as: func(self, event, ...).

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.

Or just leave it as it is :P

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

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


Mhm, I'll try that.

Thanks for clarifiying this, haste. I thought you throtle health updates too. Thanks for the clarification. :)

i have no luck spawning the raid/party frames with 1.5

this works with 1.4.x on live:
any clues?
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;
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.

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.

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
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.

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:
Regarding attributes

@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.

At least, it's working fine for me.

Also, a note to haste, for element/vehicle.lua
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.

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.

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" ... I need it for 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?

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 :-/

Don't think anyone does. :]

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.

Ye it is. But still, not yet final. :P

You know software that is actually "final"?

Meh, you know what I ment. When I said final is the actual release of 1.5, even haste said he is not happy with some stuff on it. So that is what I asked, 1.5 to the "public" so to say. :)

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():
Looks like it's not being loaded, but I don't get any specific error messages before that one.

**edit: Ok, got it. It was that XML error.

So it was 1.5 and not 1.5.1 in other words :).

Indeed. Now no more errors, but all my frames are invisible.. oh dear..

First post. The initial-* attributes are no longer processed by the secure system and oUF.

There's nothing about these in the first post.
But thanks. :p

Followed by a set of examples :P.

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:

It can be on any oUF call tho.

I use namespaces for a config file, I use But even if I remove it, it doesn't make a difference, and anyway, why should I? I'm confused. :S

You're among those who had time to fetch oUF 1.5 before I pushed 1.5.1, I guess.

It was that, thanks! ^^

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:
Anyone know a way to create em without taint?

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.