oUF - General discussion

[Blood Druid]

Message processing does not work in the new version oUF
self:RegisterEvent('UNIT_NAME_UPDATE', updateName)

function is set:
local updateName = function(self, event, unit)
....
end

did as has been shown in oUF_Lily

what a problem?


P.S. If in oUF_lily to remove a line 82 self:UNIT_NAME_UPDATE(event, unit) that there will be same problems.

Haste what to do?

[haste]

I don't really understand what your problem is .

[p3lim]

It doesnt run the function when the event fires, I had the same issue.

Using tags now though.

(This is about 1.3)

[haste]

Then the next obvious question is: Are you able to tell me how to re-create it?

[p3lim]

Just register the event like you do in 1.3, providing a function for it.
You'll notice it doesnt update the function, for what reason is unknown to me. (didnt look too much into it)

[Blood Druid]

Originally Posted by haste I don't really understand what your problem is .

I have in view of what the appointed function does not fulfil, i.e. names on RaidFrames, Target, TargetTarget, Player etc are not written.
Probably I that do not understand
I understand as message UNIT_NAME_UPDATE works...

Earlier that the name (the specified function has started to work) was updated was to register this event enough and to make oUF:RegisterSubTypeMapping'UNIT_NAME_UPDATE '

...and all worked...

[dafire]

If you use the development version try

self:Tag(namefontstring,"[name]")

[Blood Druid]

Originally Posted by dafire If you use the development version try self:Tag(namefontstring,"[name]")

I do not plan transition to use Tags in my Layout

[Blood Druid]

And so, I seem have not much understood the reason not correct working off:
earlier all events remained in the table subTypesMapping and processing function under this table was in

function oUF:PLAYER_ENTERING_WORLD(event)
.....
end

all became simply and quickly, i.e. all which functions of event were caused were in the table subTypesMapping.
In the new version the mechanism is processed and on a plan is improved, here to dispute are not present, but which functions of event are not caused registered.

I suspect that errors or in

function oUF:RegisterEvent(event, func)
...
end

or in

function oUF:PLAYER_ENTERING_WORLD(event)
...
end

... can in __elements that is not added?

[haste]

.__elements is used for OnShow updates of the frame.
:RegisterEvent() is used for ordinary event handling.

I don't use .__elements in oUF_Lily, because the UNIT_HEALTH function will make the OnShow call for me.

[ant1pathy]

Not sure if this is the right place to ask this; if not I would appreciate a point in the right direction !

For a while I used a HUD called "UnderHood." It did the job well, but used DogTags which I don't really like so I've decided to move to oUF. I have enough knowledge of lua to not hurt myself and move things around, so it's working out pretty well. The one think I miss, however, was a nifty feature about the buffs/debuffs. On the player/target buff/debuff list, it would supersize the ones cast by the player (about 4x the normal size), along with prioritizing those which I believe is standard practice. How might I go about replicating something like that?

[1nstant]

I'm having a problem w/ the player cast bar. I'm not sure if it's been said, probably has because it's pretty obvious to anyone who spams their keys.

For example: If I use steady shot, the casting bar will come up. If I hit it again, the player casting bar will disappear. It won't stop the cast, just the bar will just vanish and the steady shot will still go off.

Tested w/ various layouts.

http://www.theewok.com/images/bug1.jpg
http://www.theewok.com/images/bug2.jpg

[p3lim]

Originally Posted by 1nstant I'm having a problem w/ the player cast bar. I'm not sure if it's been said, probably has because it's pretty obvious to anyone who spams their keys. For example: If I use steady shot, the casting bar will come up. If I hit it again, the player casting bar will disappear. It won't stop the cast, just the bar will just vanish and the steady shot will still go off. Tested w/ various layouts. http://www.theewok.com/images/bug1.jpg http://www.theewok.com/images/bug2.jpg

Fixed in next version

[duhwhat]

[08:36:24] Interface\AddOns\oUF_Banzai\oUF_Banzai.lua:60: attempt to 

call method 'UNIT_HEALTH' (a nil value)
(tail call): ?
[C]: in function 

`UNIT_HEALTH'
Interface\AddOns\oUF_Banzai\oUF_Banzai.lua:60: in 

function `v'
...dOns\oUF_Banzai\libs\LibBanzai-2.0\LibBanzai-

2.0.lua:162: in function <...dOns\oUF_Banzai\libs\LibBanzai-2.0

\LibBanzai-2.0.lua:128>

I guess Banzai is no longer supported, but I get this error with oUF 1.3 and oUF Lyn

[grimman]

Updated my local oUF to the new 1.3 and much to my surprise everything works... except self.Resting. :P
It's stuck on visible, regardless of whether I'm inside or outside of a resting zone, reloading doesn't affect it either.

Another thing I noticed which is merely an inconvenience for me is that whenever I enter a party an error is thrown;

[2008/12/21 15:14:03-1053-x2]: oUF-1.3\ouf.lua:94: attempt to call field '?' (a nil value)

BugGrabber tucks it away nicely in the nether regions of my UI, so it doesn't do much more than squeak a "Fatality!" warning.
Still, a bug is a bug (whether it's yours or mine), and I'd like to get it ironed out if possible.

[p3lim]

Originally Posted by grimman Updated my local oUF to the new 1.3 and much to my surprise everything works... except self.Resting. :P It's stuck on visible, regardless of whether I'm inside or outside of a resting zone, reloading doesn't affect it either.

Most likely an issue with oUF.
Haste: compare lines 15 and 16 in status.lua (aswell lines 23 and 24)

Originally Posted by grimman Another thing I noticed which is merely an inconvenience for me is that whenever I enter a party an error is thrown; [2008/12/21 15:14:03-1053-x2]: oUF-1.3\ouf.lua:94: attempt to call field '?' (a nil value)

Issue with one (or more) of your events, the event handler got changed in 1.3

[grimman]

Originally Posted by p3lim Issue with one (or more) of your events, the event handler got changed in 1.3

Didn't think it would cause an issue. One of the things I hadn't changed in my Lily-cannibalizing (and post 1.3 event handling upgrade) was a single registered event near the end of the style function. "-- self:RegisterEvent(...)" -> success!

That only leaves the rested icon, which is commented out as well. For now.
I suppose I could write my own handler, but I'd hate to waste the effort before I get any official word on the issue.

Thanks for bopping me on the noggin. I should have checked the events more carefully. :P

[haste]

Originally Posted by grimman Updated my local oUF to the new 1.3 and much to my surprise everything works... except self.Resting. :P It's stuck on visible, regardless of whether I'm inside or outside of a resting zone, reloading doesn't affect it either.

Fixed on git.

[wcshadow]

Ive been using oUF for quite a while with Roth's UI, and after updating to 1.3.1 today, my bars seem to be all a mess, while selecting myself i doesnt show my name and same with mobs arent displaying correctly, is there a line of code that can restore these names and proper working ?


dont know if this error code would help or not but i keep getting

oUF-1.3.1\ouf.lua:94: attempt to call field '?' (a nil value)

[haste]

Don't use a 1.2.x layout on 1.3.x.