Haste, combo points don't work in 3.0. The function returns if it's not associated with the player frame, but the event is only registered if it's associated with the target frame.

Post a bug report.

Thanks!
 

I just wanted to thank you for creating the oUF framework. It allows beginner's like me actually create some very advanced stuff with minimal effort, while still learning lua.

I'm certain that running oUF takes alot of effort, and I just wanted to thank you for it.

I am sure that's nice to hear for haste. I couldn't agree more with you. You can see from oUF discussions that him and I not always saw eye to eye, but yeah, he's a good guy and an awesome programmer.

Hope this haven't been asked before. Is oUF capable of displaying the rogue energy gain the smooth 3.0 way? I currently use rabbits layout and the energy gain is jumpy like pre 3.0.

It is, take a look at elements/power.lua and elements/health.lua for more information.

I can has config command?
 

Maybe I'm just dumb, but I can't seem to locate any info on slash commands for configuring this module...

>.>

Edit: Ok, I guess I'm dumb. I guess there are no config commands. In which case I have to say: beautifully crafted addon, except that- if I can't at least move the frames, I can't use it. The defaulted layout conflicts with my UI.

More's the pity. I just liked the look of those orbs of yours- quite slick, and considering a lot of my interface is styled "in the round" it would have been a nice addition.

Sadly, it isn't meant to be. If I have to go in and manually edit the Lua files to do so, well... then the promise that this addon "does all those boring things you'd rather not do yourself" is rather a disingenuous claim. I don't care to hand-code something to alter what I believe I should be able to do live in the interface itself- even if I were capable and learned at doing so.

what he said. :)

Patience is a virtue.

The case is however: oUF is aimed towards add-on authors, who already have experience with the WoW API and Lua. Which means the bar is already put pretty high. The common user already have a bunch of alternatives when it comes to unit frames (ag_unitframes, pitbull, sage to mention the most common). These all provide a varying degree of customization.

It's up to the authors of the layouts to provide such features. The case is currently that most people who write layouts don't really care about who uses their layout or not. Its a thing mostly intended for themselves and no-one else, which is why most (if not currently all) layouts hard-code the whole setup.

As mentioned before, you (as a user) aren't really a part of the intended audience. oUF falls in a rather special category when it comes to who would use it to write layouts. In general its the lazy and the inexperienced who use it. The lazy who just want a unit frame that does X, but don't want to maintain a unit frame themselves. And the inexperienced who take a layout and modify it to their liking.

The whole unit frame creation process is simplified however. In most cases the layout author just have to create and position element X, which it then tells oUF to handle.

In the end it all boils down to: It's a issue of the layout, not oUF.

Is there a way to disable timers on other players debuffs in oUF? It's rather confusing with two locks in an instance!

No, that's currently not possible.

Bah, back to DoTimer then. Any plans to implement disabling timers from other players? Or will this need to come from Blizzard's end?

I don't really plan on anything at the momemt. Feature requests are there for a reason however :).

In the end it all boils down to: it's a nice addon that is sadly completely useless to me, whatever the reason.

if thats the case than i honestly do not understand what all those layouts are doing flooding the download section of this site. just post and/or link them in the fora so ordinary users dont get bothered with them. again, there is some excellent work out there (mainly by you and zork imho) but the lack of a gui-setup kind of thing puts the whole ouf concept down.

You don't seem to understand the concept.

Allright i'm not sure if it's me doing something wrong but, if not i though i should report this.

here are the settings i have affecting the power bar
I am not using self.Power.disconnected, i don't really know how to explain so a screenshot will do.



Some have their power bar full and some emply, i've tried to override with bar:SetValue(0) in my updatePower but that doesn't do it.

The second thing, look at the shaman's power bar, he's a ghost, why isn't it either full or emply ?

I use the default frames and it does this aswell, so it's default behaviour.

Aight, but that's still weird i can't override it, anyway the other issue is the most important.

updatePower is equal to PostUpdatePower?