oUF - General discussion
 

The old oUF thread over at WoWace has become, quite a monster to say it softly. It's a mess of bug reports, layout issues and general issues/feature people have/want.

Please use this thread for general oUF discussion only (non-layout specific stuff).

Related forum thread: oUF - Layout discussion
Bug reports and feature requests should be posted over at the author portal.

moving the safe zone discussion over here.

is it even possible to calculate a reasonably accurate safe zone for a channeled cast?

the safe zone would presumably be calculated and displayed based on the latency at the beginning of the cast. compared to relatively short cast times like shadowbolt (2.5s when talented) a 5 second channel has much more of a chance to have a different latency at channeling start vs. channeling end. in light of this, would it be possible to delay safe zone calculation/display until a channel is 50% or even 75% complete?

The safe zone calculation is done during the OnUpdate of the casting bar. The latency information we have isn't real-time however, it's polled every 5 sec or so.
I don't remember how often it updates, you can check it yourself by doing: /run ChatFrame1:AddMessage(select(3, GetNetStats()))

Channeled spells are tick based however, so I'm not really sure how helpful a safe zone would be. It also seems that the last tick happens slightly after the cast has finished.

I thought the safe zone should be included to minimize downtime between chain-casts of channeled spells or a regular cast following a channel, but if the last tick is happening after the cast, this is irrelevant (potentially counter-productive). it then seems that the best practice for channeled spells is to begin the next cast after the castbar has disappeared.

I generally just use:
It won't maximize your DPS of course. I don't think the potential gain from interrupting a cast at the end is very significant either :). Adding a safe zone for channels isn't much work at all however, it's basically copy-pasting of the code for casting :p.

i moved to quartz from azcastbar/oUF castbar in an attempt to avoid the button-mashing at the end of channels that this kind of macro (which i've used before) involves. i -wanted- to believe that having a safe zone at the end of channels and a single keypress in this safe zone would be more efficient than a nochanneling macro, especially when moving from a channel to a regular cast, rather than chaining channels. moving back to nochanneling tonight : ) but keeping quartz till someone makes a GCD spark addon/plugin.

I've been trying out oUF again lately on beta and noticed a discrepancy between the oUF castbar and the azCastBar's safe zones. oUF always showed more latency than aCB. Attempting to move while in the oUF safe zone would cancel my cast, while moving during the aCB safe zone was fine. This may have been due to fluctuating latency on beta, but it was in Shattrath with hardly anyone around. Will keep an eye on it again tonight. :)

There has been a lot of talk regarding the safe zone in oUF. When I reviewed the castbar code a while ago, I also changed the safe zone to represent exactly what your current latency was, and not more. People complained about it however, so the math was reverted back to the original state.

With the current arithmetics the safe zone is ten times larger than what the current latency is. If you feel experimental then you could try to change 1e5 to 2e5 in elements/castbar.lua. This will make the safe zone be five times the latency.

I don't know how azCastBar does its latency handling so I can't really comment on that.

Actually, Haste, I was the big complainer ;) (And the battle RAGES on, was an awesome commit message). My shock was mainly that all of the sudden, I had no safezone anymore. Looking back at it now, it could be because this happened while I hadn't gotten used to the latency on EU servers as well. If you go from 120/200 ping to 50-70, your safezone gets a whole lot smaller. I'll try again with your calculations, but safezones actually seem to be freaking iffy to deal with imho.

It is :(. In a perfect world it would equal the latency you currently have, but I guess twice the latency might be better. Guess I should do some testing on the beta servers tomorrow.

But Seerah is right about it though. Perhaps I personally had grown so used to seeing a huge red bar that when it wasn't there I lost it :P (But hey, I made an awesome firey post session about it! Passion galore!)

You mean I can blame it all on you, moonie? :D hehe

I personally think 10x is a bit much. Especially since it was pretty reliable that when the cast bar entered the "safe zone," I wasn't really "safe"...

Yeah, some of it was definately me. Poor haste got hell from me that day. It showed just how much of a math/physics geek I am then.

oUF.colors.health variable should be used in not overriden health update if i understand, tho it isn't and nowhere else too

Post a bug report :3

is it intended that the casttime increases instead of decreases ?
i prefer a decreasing casttime, how can i change this ?

1) Yes
2) Currently the only way to change it is to replace the OnUpdate with your own.

Curious...

Why? Seems unintuitive impo...

There isn't really much reason to it at all. The original code had it hard-coded in that way, and no-one has mentioned anything about it. So I left it that way when I reviewed the code.

Feature request submitted. ;)

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?

Yes.

But even without an override, it shouldn't be doing that, right ?
I think it's either self.Power.colorClass or colorReaction btw.

Speaking about the offline issue, not the ghost, that one isn't important.

color* only does coloring, and nothing else. I'm pretty uncertain what your actual issue is however.

If that can help you track it down.

Link to layout

I'm still uncertain about what your issue is. Neither do you attempt to do any value overriding on power as you said.

Oh nono, that was just a try, this above is the actual layout, but i did try with That didn't do a thing.

New bug report posted linked with SetAttribute in a patch 3.0

You mean other than that they're fully functional and original addons that do exactly what the author intended them to do, that the author then decided to share with people who were interested? I suppose other than that they aren't doing anything.
Bear in mind, you are completely free NOT to download them. In fact, I would go so far as to say you don't have to download a single addon, and as such you can safely ignore them in the listing. </grump>

A plead...
 

Hello:

I just picked up the RothUI compilation yesterday and am thrilled with it. I've been aching for something this good ever since Discord went bye-bye long ago.

A lot of people, myself included, don't understand (or want to understand) LUA coding. And as much as we love you and others for putting out quality oUF layouts and plugins, PLEASE:

Give us an in-game GUI, even if it means simple things like positioning, scaling, etc. Again, I really really love the addon, but a lack of user-friendly customization is slowly becoming a turn off. Any hopes for the future?

Keep up the great work.

EDIT: The reasoning for my post in the first place was about scaling. I run at 1680x1050, and have to keep my UI scale high to have the orbs/action bars to a good size. This unfortunately makes the rest of my UI windows a fairly annoying/bordering on gigantic size, causing me to scale down EVERYTHING else except oUF to compensate.

No, there won't be a in-game configuration internally in oUF. The scope of oUF is really just to handle updating of elements, and let the layouts handle the rest.

Which also means that your scale issue is related to the layout, and not the oUF core :).

If you dont want to learn Lua, use a different addon.

That's the wrong attitude really. It's fully possible to have in-game options and use oUF as a base, just that no-one does it publicly yet.

Yeah of course its possible to make a GUI based layout for oUF, but its not something at least I intend to do.

Though, I heard some guy were working on that, so you never know.

In game positioning should be handled by oUF and not the layout.
The layout could contain a check or oUF itself to check if any saved vars containing positioning are set and decide if the layout's positioning should be used or not.

Or remove positioning from the layout completely and smack everything in center unless anything has been configured in-game.

No. (message too short)

because it would be better if all layouts had their own code for in game positioning system?

Yes, either that or a plugin.

Seriously p3lim, stop spreading your personal opinion as the general opinion of oUF. Your statement is invalid (in this case), and in most (if not all) it's my opinion that matters.

There is however a related feature request for this: http://www.wowinterface.com/portal.p...featureid=3012

Hey Haste?

You've removed the .Name in 1.3, which is perfectly fine by me, only - now I can't customize my names anymore. Basically, I shorten my names and color them on class or reaction. :(

You can re-add it from your layout. The name updating oUF did was a total of four lines of code :p. It was removed since tags will replace it, and it was never intended to be anything advance.

The commit should tell you pretty much what you need to do.

You don't need to insert it as an element of course. You could just add the event handler and register the event in your layout.

ANd with that, I give up. Seroiusly, the little time I have to play, I spend trying to get my layout to work fine again. :( I love oUF, but I give up.

self.TaggedStrings = {self.Name} since that's how my name string is called, just happily shows [name] (just like the other registered tags when I add them to TaggedStrings)

Edit: I don't give up because you removed .Name or told me to re-add it manually. I am just painfully tired of trying to write half-assed decent code, failing miserably, feeling inadequate to even post in a dev thread, etc etc. And right now, all that stops me from throwing all pc bs I have through the dang window is the knowledge that I need it for work.