Nameplates

[Dridzt]

Originally Posted by Maul Not entirely, I turned the taint log off and still had issues until I narrowed down my crash issue to modifying a custom gametooltip (like used for tooltip scanning). I eliminated the modifications as well as the :GetRegion() calls on the custom tooltip and only then did the crashes stop. And I still crash on a /reload occasionally with the taint log off.

You can add WorldFrame:GetChildren() to the list of things that hard crash the beta client (build 15882)

(typical for nameplate addons looking for nameplates)

Note: Pulled these posts from MoP beta topic as they're no longer MoP specific. - Haleth

[ballagarba]

Originally Posted by Dridzt You can add WorldFrame:GetChildren() to the list of things that hard crash the beta client (build 15882) (typical for nameplate addons looking for nameplates)

In case you didn't know: http://www.wowinterface.com/forums/s...9&postcount=30

[Haleth]

You still need to use WorldFrame:GetChildren() to actually iterate through potential frames. Then you can check them by name.

It would be much better if we could hook into the function that creates nameplates, but we don't have access to it.

[p3lim]

Originally Posted by Haleth You still need to use WorldFrame:GetChildren() to actually iterate through potential frames. Then you can check them by name.

Actually...

local index = 1
 
local addon = CreateFrame('Frame')
addon:SetScript('OnUpdate', function()
    while _G['NamePlate' .. index] do
        local frame = _G['NamePlate' .. index]
 
        -- do whatever
 
        index = index + 1
    end
end)
addon:Show()

[Dridzt]

Originally Posted by p3lim Actually...

That's a simple and clever workaround for the bug actually,
might have to poach it for a couple addons that I've had to keep disabled in beta.

Edit: Scratch that, a while loop won't work sadly, nameplate frames are reused for one so you don't always have a nice collection of sequential frames from 1 to n.
Even if we did have that, it would still need to wrap around to index 1 when it exits the while loop.
It's food for thought definitely...

And another function that hard crashes the client (no addons present) GetDestinationReforgeStats() (build 15882)

[Haleth]

Okay, p3lim, that's clever. Should be quite a bit more efficient

[p3lim]

Originally Posted by Dridzt That's a simple and clever workaround for the bug actually, might have to poach it for a couple addons that I've had to keep disabled in beta. Edit: Scratch that, a while loop won't work sadly, nameplate frames are reused for one so you don't always have a nice collection of sequential frames from 1 to n. Even if we did have that, it would still need to wrap around to index 1 when it exits the while loop. It's food for thought definitely...

local function Update(self)
    -- do whatever
end
 
local index = 1
 
local addon = CreateFrame('Frame')
addon:SetScript('OnUpdate', function()
    while _G['NamePlate' .. index] do
        local frame = _G['NamePlate' .. index]
        frame:HookScript('OnShow', Update)
 
        Update(frame)
 
        index = index + 1
    end
end)
addon:Show()

[endx7]

Originally Posted by zork You are sure that you want to update every single name plate on every single frame in the game? With 40 plates thats 40 updates per frame. At 100fps thats 4000 calls per second.

since index is never reset, it is only nameplates that have never been seen before. Each OnUpdate starts where it left off. If there are no new frames at all, the while loop fails immediately.

The OnShow handler ensures that the next time the frame is reused, we can handle updating the frame again.

[Dridzt]

Originally Posted by zork You are sure that you want to update every single name plate on every single frame in the game? With 40 plates thats 40 updates per frame. At 100fps thats 4000 calls per second. Not sure why you even want to do that. All nameplate stuff can be done with one style function and some hooks. Once a nameplate is styled it can be ignored from that time on.

The discussion originated from the fact that in current MoP beta one of the things that hard crashes the client is calls to WorldFrame:GetChildren() which most nameplate addons use in their nameplate identification functions.

[zork]

Forget what I wrote.

Btw...Does adding a throttle based on elapsed have any positive results performance-wise?

*edit* Tested...does not work

NamePlate1 is not found. Script stops.

Not sure why you say that checking the WorldFrame crashs the client...I'm doing just that and the client does not crash. Or is that only in combination with the taintlog enabled?



NamePlateIds start at 2xx in my case. Not sure why...it's just what the GetName() spits out.

[p3lim]

Originally Posted by zork NamePlate1 is not found. Script stops. NamePlateIds start at 2xx in my case. Not sure why...it's just what the GetName() spits out.

The reason is because you did /reloads, and the game keeps continuing from where it left off before you did.
Unlike most frames, the nameplates are written (or wrapped) in C, and will not reload like the rest of the UI does.

Here is a way to counter this:

local function Update(self)
    -- do whatever
end
 
local index = 1
local fresh = true
 
local addon = CreateFrame('Frame')
addon:SetScript('OnUpdate', function()
    while _G['NamePlate' .. index] or fresh do
        local frame = _G['NamePlate' .. index]
        if(frame) then
            fresh = false
 
            frame:HookScript('OnShow', Update)
 
            Update(frame)
        end
 
        index = index + 1
    end
end)
addon:Show()

[Dridzt]

Wouldn't that loop run 'forever' and keep bumping index if you happen to reload in an area with no nameplates?

[Haleth]

I'd still prefer to limit the while loop to run only, say, 10 times per second, rather than every new frame. Comparing two numbers (to check if enough time has elapsed) is likely far more efficient CPU-wise than looking up a frame in _G.

Btw, I pulled these posts from the MoP topic.

[p3lim]

Originally Posted by Dridzt Wouldn't that loop run 'forever' and keep bumping index if you happen to reload in an area with no nameplates?

It would indeed.

A possible solution instead of the previous would be using a combination of an event and function that only works on a login (not reload) to reset a SV containing a variable that is set on PLAYER_LOGOUT to keep counting properly.

It would lead into a monstrosity though.

[p3lim]

Originally Posted by Haleth I'd still prefer to limit the while loop to run only, say, 10 times per second, rather than every new frame. Comparing two numbers (to check if enough time has elapsed) is likely far more efficient CPU-wise than looking up a frame in _G.

That is not desireable, as it would leave a (possibly) big gap where a nameplate would look like default.

[Haleth]

Perhaps we should just request on the official forums that they add a better way for addons to do this. Since it's handled outside of lua, perhaps there could be an event like NAMEPLATE_CREATED, passing the frame as a parameter.

They listened to the request for new macro conditionals. Worth a shot, or?

[p3lim]

Originally Posted by Haleth Perhaps we should just request on the official forums that they add a better way for addons to do this. Since it's handled outside of lua, perhaps there could be an event like NAMEPLATE_CREATED, passing the frame as a parameter. They listened to the request for new macro conditionals. Worth a shot, or?

Go for it, I don't have access to the US forums.
Also, frame name or id would be enough, don't think they'd go for passing the whole frame table.

Remember, I am not trying to replace the current method we are using, this is just a temporary thing to work around the issues on the beta client, and perhaps find something nice while we're at it.

I agree that the nameplates should be easier to do anything with, but blizzard is avoiding showing the code, most likely to counter potential bots.

[p3lim]

Here we go, PLAYER_LOGOUT event saving the last index to a savedvariable, two OnUpdate scripts iterating either a new index or the savedvariable, and either of them shuts down the savedvariable one.

local index = 1
 
local backup = CreateFrame'Frame'
backup:SetScript('OnUpdate', function(self)
    if(not SomeCleverVariableName) then return end
 
    if(_G['NamePlate' .. SomeCleverVariableName]) then
        self:Hide()
 
        index = SomeCleverVariableName
        SomeCleverVariableName = nil
    end
end)
 
local iterate = CreateFrame'Frame'
iterate:SetScript('OnUpdate', function()
    while(_G['NamePlate' .. index]) do
        local frame = _G['NamePlate' .. index]
        frame:HookScript('OnShow', Update)
        backup:Hide()
 
        Update(frame)
 
        index = index + 1
    end
end)
 
iterate:RegisterEvent'PLAYER_LOGOUT'
iterate:SetScript('OnEvent', function()
    SomeCleverVariableName = index + 1
end)

[p3lim]

Also, move this to the proper MoP discussion sub-forum, as it is not related to live clients.

[Lombra]

Originally Posted by p3lim Go for it, I don't have access to the US forums. Also, frame name or id would be enough, don't think they'd go for passing the whole frame table.

Some spontaneous ideas, should anyone put together a formal proposal to Blizzard; NAMEPLATE_SHOW(index), GetNumNameplates(), GetNameplate(index). Possibly additional events for _CREATE and _UPDATED, and/or an argument indicating a new frame was created.