WoWInterface - Nameplate hacking and unit IDs

Page 1 of 2

Show 60 post(s) from this thread on one page

WoWInterface (https://www.wowinterface.com/forums/index.php)

- Legion Beta archived threads (https://www.wowinterface.com/forums/forumdisplay.php?f=177)

- - Nameplate hacking and unit IDs (https://www.wowinterface.com/forums/showthread.php?t=53439)

MunkDev

05-14-16 06:08 PM

Nameplate hacking and unit IDs

In the Live version of my addon ConsolePort, I'm using a nameplate cursor that deviously hacks the nameplates by caching them securely and scaling them up to cover the entire screen. Coupled with a mouseover macro, this gave me control over targeting without using a mouse cursor. Here's a video of how it used to work:
https://youtu.be/8APU6SXDNpI

Now in Legion, I changed up my code to cache the unit frames associated with nameplates instead, thinking I could utilize the unit IDs. This works out of combat, but when I'm in combat, the frame handles are no longer accessible. My raid cursor (works the same way, but with raid frames) still works as intended, which probably means it's only related to the name plates. Either that, or I'm missing something vital here.

Tab-targeting seems to be better than ever, but I would ideally like to get this system working again with the new nameplate unit frames, because it gives much better control over tab-targeting when you can actually choose the direction in which it should look for the next target.

Here's the code that no longer works:

Lua Code:

Cursor:SetAttribute("GetPlates", [[
    Plates = wipe(Plates)
    Visible = 0
 
    for i, frame in pairs(newtable(WorldFrame:GetChildren())) do
        local name = frame:GetName()
        if name and strmatch(name, "NamePlate") and frame:IsShown() then
            local unitFrame = frame:GetChildren() -- returns nil in combat
            local unit = unitFrame and unitFrame:GetAttribute("unit")
            if unitFrame and unit and PlayerCanAttack(unit) then
                Plates[unitFrame] = true
            end
            Visible = Visible + 1
        end
    end
]])

Any suggestions on how to solve this, if it's even possible?

syncrow

05-14-16 06:43 PM

Quote:

Originally Posted by MunkDev (Post 314795)

Any suggestions on how to solve this, if it's even possible?

Lua Code:

local activeUnitPlates = {}
 
local function AddNameplate(unitID)
    local nameplate = C_NamePlate.GetNamePlateForUnit(unitID)
    local unitframe = nameplate.UnitFrame
 
    -- store nameplate and its unitID
    activeUnitPlates[unitframe] = unitID
end
 
local function RemoveNameplate(unitID)
    local nameplate = C_NamePlate.GetNamePlateForUnit(unitID)
    local unitframe = nameplate.UnitFrame
    
    -- recycle the nameplate
    activeUnitPlates[unitframe] = nil
end
 
local frame = CreateFrame("Frame")
frame:RegisterEvent("NAME_PLATE_UNIT_ADDED")
frame:RegisterEvent("NAME_PLATE_UNIT_REMOVED")
 
frame:SetScript("OnEvent", function(self,event,...)
    if event == "NAME_PLATE_UNIT_ADDED" then
        local unitID = ...
        AddNameplate(unitID)
    end
    
    if event == "NAME_PLATE_UNIT_REMOVED" then
        local unitID = ...
        RemoveNameplate(unitID)
    end
end

This is hopefully what are looking for!

I'm currently constructing new plates for my UI with animated health bars and such things...
The new system is freaking awesome, and very handy!

zork	05-15-16 07:48 AM

Yes it sounds really awesome.

MunkDev

05-15-16 03:28 PM

I'm confused by these answers. Did I ramble too much? The point of the post was that secure references to the unit frames attached to name plates seem to not be accessible in combat. That has nothing to do with styling them or storing them insecurely.

semlar

05-15-16 04:00 PM

Quote:

Originally Posted by MunkDev (Post 314841)

I imagine there aren't that many people who really understand what you're talking about aside from me, because I wrote it, and yourself, since you needed something fairly specialized to suit your purposes.

Frankly it should be easier to do this in legion than it is on live, but I haven't had time to look into it. From what I can tell the unit frame isn't even mouse-enabled so you're still just clicking through it onto the WorldFrame, and there's nothing stopping you from scaling the nameplate and using a mouseover macro like you're doing now.

Just to be clear, it isn't working because you're trying to access the "unit frame", which isn't actually a secure unit frame, in the restricted environment in combat. Just use the nameplate.

Resike

05-15-16 04:15 PM

Quote:

Originally Posted by MunkDev (Post 314841)

I've tried this and it's working fine for me:

Lua Code:

Plates = wipe(Plates)
Visible = 0
 
for i, frame in pairs({WorldFrame:GetChildren()}) do
    local name = frame:GetName()
    if name and strmatch(name, "NamePlate") and frame:IsShown() then
        local unitFrame = frame:GetChildren()
        local unit = unitFrame and unitFrame:GetAttribute("unit")
        if unitFrame and unit then
            Plates[unitFrame] = true
        end
        Visible = Visible + 1
    end
end

I have used it as a plain function tho. How does your hook looks like, when do you run the attribute itself?

Edit: The weird thing is the unit attribute seems to be like "nameplate1-30", you can get the proper unit attribute with a hack from the nameplate's buff/debuff frame like reaching this value: unitFrame.BuffFrame.unit, however that unit value seems to be broken too almost all the time.

syncrow

05-15-16 05:48 PM

Quote:

Originally Posted by MunkDev (Post 314841)

Did I ramble too much? The point of the post was that secure references to the unit frames attached to name plates seem to not be accessible in combat.

My bad, thought you need a way get the unitID / unit frame...

MunkDev

05-15-16 06:35 PM

Quote:

Originally Posted by semlar (Post 314843)

Quote:

Originally Posted by semlar (Post 314843)

Frankly it should be easier to do this in legion than it is on live, but I haven't had time to look into it. From what I can tell the unit frame isn't even mouse-enabled so you're still just clicking through it onto the WorldFrame, and there's nothing stopping you from scaling the nameplate and using a mouseover macro like you're doing now.

Just to be clear, it isn't working because you're trying to access the "unit frame", which isn't actually a secure unit frame, in the restricted environment in combat. Just use the nameplate.

That was my thought exactly, now that we actually have unit attributes. I did not realize the unit frames themselves are not actually secure. I only dumped :IsProtected from the plate itself and just assumed the unit frames were also protected, since they seemingly behave and use attributes like any other unit frame.

Quote:

Originally Posted by Resike (Post 314844)

The reason it works when you run it as a plain execution on a secure header is because you can only do that out of combat. When you're out of combat, an insecure frame (as Semlar mentioned) would be returned in the list of frames from frame:GetChildren(), even in a secure environment. I'm running it in a binding, which should of course work regardless of combat state. Here's the code if you're interested:
https://github.com/seblindfors/Conso...Nameplates.lua

The unit ID probably works for targeting if you create clickable unit frames and assign type as unit and unit as the nameplate attribute, which could mean that Semlar's lazyplates concept would work to create a grid of name plate unit frames instead of hacking the whole system. I haven't tried anything like this yet, but it seems like it should work.

Btw; sorry if I came off as rude Syncrow. That's not the way I meant it. I realize this idea is pretty bananas in itself, so it's not far fetched for someone else to assume it was about caching active name plates and manipulating their look and function.

Resike

05-16-16 03:01 AM

Quote:

Originally Posted by MunkDev (Post 314848)

Hehe. My threads can be quite technical at times, since my addon and the features it provides is unique in a way. Your code, which this was based on, might still work as it does in the live version, but I was hoping to get away from the scaling and use the unit attributes instead, because I would then be able to set the unit attribute in a preclick snippet and essentially remove the need for mouseover.

That was my thought exactly, now that we actually have unit attributes. I did not realize the unit frames themselves are not actually secure. I only dumped :IsProtected from the plate itself and just assumed the unit frames were also protected, since they seemingly behave and use attributes like any other unit frame.

The reason it works when you run it as a plain execution on a secure header is because you can only do that out of combat. When you're out of combat, an insecure frame (as Semlar mentioned) would be returned in the list of frames from frame:GetChildren(), even in a secure environment. I'm running it in a binding, which should of course work regardless of combat state. Here's the code if you're interested:
https://github.com/seblindfors/Conso...Nameplates.lua

The unit ID probably works for targeting if you create clickable unit frames and assign type as unit and unit as the nameplate attribute, which could mean that Semlar's lazyplates concept would work to create a grid of name plate unit frames instead of hacking the whole system. I haven't tried anything like this yet, but it seems like it should work.

Btw; sorry if I came off as rude Syncrow. That's not the way I meant it. I realize this idea is pretty bananas in itself, so it's not far fetched for someone else to assume it was about caching active name plates and manipulating their look and function.

I see. However if the GetChildren retuns nil in a secure environment i thinks that s bug in the secure system. I mean you should be able to iterate between parents and childrens.

MunkDev

05-16-16 06:10 AM

Quote:

Originally Posted by Resike (Post 314853)

I see. However if the GetChildren retuns nil in a secure environment i thinks that s bug in the secure system. I mean you should be able to iterate between parents and childrens.

Unprotected frames are scrubbed when you enter combat, to make sure you can't access insecurely manipulated information from unprotected frames. It's not really a bug, just a way to make sure you can't use information from events or the normal API to make gameplay-changing decisions.

Resike

05-16-16 06:26 AM

Quote:

Originally Posted by MunkDev (Post 314857)

I don't get why are the nameplates not secure then.

lieandswell

05-16-16 07:09 AM

Quote:

Originally Posted by MunkDev (Post 314848)

I only dumped :IsProtected from the plate itself and just assumed the unit frames were also protected, since they seemingly behave and use attributes like any other unit frame.

Just to be clear for anyone else following along: Blizzard_NamePlates re-uses a lot of the code from raid frames (CompactUnitFrame), but without the click-ableness. It attaches things it calla "UnitFrames" to the NamePlate# frames returned by C_NamePlate.GetNamePlateForUnit(namePlateUnitToken) but then disables mouse interaction so all clicks go to NamePlate#.

syncrow

05-16-16 07:53 AM

Quote:

Originally Posted by MunkDev (Post 314848)

The unit ID probably works for targeting if you create clickable unit frames and assign type as unit and unit as the nameplate attribute, which could mean that Semlar's lazyplates concept would work to create a grid of name plate unit frames instead of hacking the whole system.

Tested it a couple hours ago, and it works flawless... Just created some 'SecureUnitButtonTemplates' with nameplate# as unit attributes.

jeruku

05-17-16 06:38 AM

Quote:

Originally Posted by lieandswell (Post 314860)

On a side note, the nameplate frame table itself has a key for the UnitFrame. The UnitFrame is a CompactUnitFrame which has all the bars, text, and frames attached.

Lua Code:

-- for example
nameplate.UnitFrame
nameplate.UnitFrame.unit
nameplate.UnitFrame.healthBar
nameplate.UnitFrame.BuffFrame

MunkDev

05-19-16 06:01 PM

Quote:

Originally Posted by Resike (Post 314859)

I don't get why are the nameplates not secure then.

The nameplates are secure, but the unit frames attached to the nameplates are not. I'm guessing the reason they went this path was to allow authors to resize and tweak the unit frames in response to insecure API calls - or they simply didn't see any reason to protect them. I personally think they should make the unit frames secure as well, because it would make all my users very happy not having to rely on tab-targeting.

The algorithm I use to determine which nameplate to choose from is fairly reliable and would supplement controller gameplay very nicely if I didn't have to hack it the way I have been previously. It was a pretty ridiculous system (and kudos to Semlar for coming up with it), but it did work. All that needs to be done for it to work perfectly without any shenanigans is for Blizzard to make the unit frames secure.

Check out this pull when I'm tanking (slow it down to 0.25 speed if you don't see it) where it takes me less than a second to focus a single target out of a group, whereas bringing the cursor out and attempting to aim with a joystick at the same location would be considerably slower in comparison.

galvin

05-19-16 06:18 PM

One of the most frustating things on live. Is finding your cursor. When there are a lot of mobs and action going on. Your eyes just don't lock onto your cursor. Same problem in diablo 3 too.

p3lim

05-19-16 07:27 PM

Quote:

Originally Posted by galvin (Post 314994)

One of the most frustating things on live. Is finding your cursor. When there are a lot of mobs and action going on. Your eyes just don't lock onto your cursor. Same problem in diablo 3 too.

https://pandateemo.github.io/YoloMouse/

Probably violates the ToS/EULA in some way, I tried it out in Diablo last season.

zork	05-23-16 03:42 AM

Is anyone building new unitframes around the fact that nameplates are now real unitframes with their own unitids?

I thought of making a new nameplate addon where nameplates and normal unitframes interfact. You could fade certain unitframes away (like target or party) if there are nameplates on screen that stand for the same unit.

I tanked my first instance with the default nameplates this weekend. Some nameplate settings are just horrible. I need to rewrite some of that.

What do you think is the best approach to adjust the current Blizzard nameplates? Is writing a new addon worth it or is styling enough (if possible). Can one even disable the current Blizzard nameplates? Probably not fully since you need the position for the frame.

ObbleYeah

05-23-16 05:23 AM

I've thought about something similar re: hiding unnecessary unitframes when nameplate doubles exist. the playerframe seems totally pointless in combat now we have the player nameplate.

i'm halfway through working on an idea that detaches the nameplates & condenses them into a grid. a quick n dirty sketch: http://i.cubeupload.com/I188Bp.png

I've also found the plates relatively easy to style without a rewrite, though i haven't delved much into performance differences just yet:
https://github.com/obble/UIForModern...ates/plate.lua

Resike

05-23-16 05:31 AM

Quote:

Originally Posted by ObbleYeah (Post 315126)

I don't see how could a nameplate be better in any way then a static unitframe with fuckloads of more information.

ObbleYeah

05-23-16 05:42 AM

i've always been about cutting back unnecessary extras where it seems relevant though, having a ton of information on hand is cool but also gets extremely messy and convoluted quickly with priorities getting buried under other heaps of data.

anyway what does the player frame have that the nameplate doesn't? a dropdown menu and your portrait texture?

just a pet project anyway, i don't think id ever do anything beyond questing with something so minimal

zork	05-23-16 05:50 AM

Nameplates are now normal unitframes with unitids. They have all the features as any other unitframe.

Resike

05-23-16 05:54 AM

Quote:

Originally Posted by ObbleYeah (Post 315128)

I issue i see, is that the nameplate itself is moving around the screen while an unitframe have static position. I doubt any healer would like to heal off name plates.

lieandswell

05-23-16 06:06 AM

Quote:

Originally Posted by ObbleYeah (Post 315128)

having a ton of information on hand is cool but also gets extremely messy and convoluted quickly with priorities getting buried under other heaps of data.

I've always thought it's better to have the right information. "Fuckloads more of it" is often just UI spam. Minimal UIs can be really useful in raids if they maximize the attention you can give to encounter mechanics. For example: if you're not a healer or a raid leader, you don't really need to see the raid frames.

That said, in the example you posted I'd find the lines linking the mobs to the unit frames really distracting. Nameplate position on screen provides that information already in a much more intuitive, less intrusive way.

ObbleYeah

05-23-16 06:10 AM

Quote:

Originally Posted by lieandswell (Post 315133)

That said, in the example you posted I'd find the lines linking the mobs to the unit frames really distracting. Nameplate position on screen provides that information already in a much more intuitive, less intrusive way.

agreed — just exploring ways to have my cake and eat it too, benefiting play styles that prefer static frames like Resike states above. i also thought about a numbering system that puts '#1' next to the frame and above the head. but again: less intuitive, more cumbersome read process.

Resike

05-23-16 06:12 AM

Quote:

Originally Posted by lieandswell (Post 315133)

I don't think that you would like to see the friendly nameplates as a dps in raid, since you don't want to target them accidentally. So your only options is the unitframes, you can disable whatever part that you don't want to see.

Also: I doubt it that you can sort nameplates by role/class/name/party etc.

ObbleYeah

05-23-16 06:14 AM

Quote:

Originally Posted by Resike (Post 315135)

Also: I doubt it that you can sort nameplates by role/class/name/party etc.

you should *technically* be able to do this right? these are the same compactunitframes that the raid frame uses after all

zork	05-23-16 06:19 AM

If I'm understanding things right a lot of stuff can be adjusted by editing the frame option tables?

https://github.com/Gethe/wow-ui-sour...rame.lua#L1615
https://github.com/Gethe/wow-ui-sour...lates.lua#L215
https://github.com/Gethe/wow-ui-sour...nels.lua#L1271
https://github.com/Gethe/wow-ui-sour...nels.xml#L1490

ObbleYeah

05-23-16 06:20 AM

yes, with the qualifier that a lot of those options are toggled off because the functions they involve aren't fully routed through the nameplates (hence my *technically*). smoothupdates throws out an error if enabled true for instance

Resike

05-23-16 08:03 AM

Quote:

Originally Posted by ObbleYeah (Post 315136)

you should *technically* be able to do this right? these are the same compactunitframes that the raid frame uses after all

It's the same and it's not. Tecnically it has very similar functions, however they are not secure. My bet would be why are they not secure because it would be really hard to animate and change other parameters if they would be.

Resike

05-23-16 08:46 AM

Also everyone is talking about that you can get the unit from the nameplate itself, but i did not managed to do this yet properly. Both the .unit values and the GetAttribute("unit") method returns "nameplate1-30" values, which is kinda useless. Or am i missing a function somewhere?

You can get the plate frame itself from the unit with C_NamePlate.GetNamePlateForUnit(), but how do you do this in the other way around?

ObbleYeah

05-23-16 08:51 AM

I've found issues with the .unit value too

the first argument for NAME_PLATE_UNIT_ADDED should be the base unitid

zork	05-23-16 09:25 AM

What do you mean useless? nameplate1 is a valid unitid like target or player.
You can compare units with UnitIsUnit or by using GetNamePlateForUnit.
http://wowprogramming.com/docs/api/UnitIsUnit

Quote:

local isSame = UnitIsUnit(unitId1, unitId2)
local nameplate = C_NamePlate.GetNamePlateForUnit(unitId)

Last but not least you can snapshot certain guids and match them against nameplate guids.
http://wowprogramming.com/docs/api/UnitGUID

Resike

05-23-16 10:08 AM

Quote:

Originally Posted by zork (Post 315147)

What do you mean useless? nameplate1 is a valid unitid like target or player.
You can compare units with UnitIsUnit or by using GetNamePlateForUnit.
http://wowprogramming.com/docs/api/UnitIsUnit

Last but not least you can snapshot certain guids and match them against nameplate guids.
http://wowprogramming.com/docs/api/UnitGUID

Except UnitIsUnit("nameplate1", "target") returns false even if you are targeting the unit with nameplate1.

Whats the point of the new system, if you get an alternative unitid then you need to get its guid then compare that with the a real unitids guid?

They should add a new attribute which would return the proper unitid GetAttribute("realUnit") which would return "target"/"pet"/"raid34" etc.

syncrow

05-23-16 10:20 AM

Quote:

Originally Posted by Resike (Post 315151)

Except UnitIsUnit("nameplate1", "target") returns false even if you are targeting the unit with nameplate1.

Try using UnitIsUnit("target", "nameplate1")

And check if you are targeting the nameplate with the unitID "nameplate1" and the unit currently using "NamePlate1"...

Getting a unitID from blizzards nameplates:

Lua Code:

local unitID = nameplate.namePlateUnitToken

Quote:

Originally Posted by Resike (Post 315151)

Whats the point of the new system, if you get an alternative unitid then you need to get its guid then compare that with the a real unitids guid?

It works exactly the same if you target lets say raid24 ... raid 24 is a unitID, and target is also a unitID referring to the same unit if targeted...

So "nameplate#" can be the same unit as raid# / player / target / focus ....

zork	05-23-16 10:24 AM

Resike that has to work. Otherwise you found a bug.

*edit* Tried it. Works both ways.

Quote:

/run print(UnitIsUnit("nameplate3","target")) --returns true
/run print(UnitIsUnit("target","nameplate3")) --returns true
/run print(C_NamePlate.GetNamePlateForUnit("nameplate3"):GetName()) --returns NamePlate3
/run print(C_NamePlate.GetNamePlateForUnit("target"):GetName()) --returns NamePlate3

syncrow

05-23-16 10:34 AM

It should be possible to create a "enemy nameplate grid" using SecureUnitButtonTemplate / SecureHandlerStateTemplate with this conditions:

Lua Code:

RegisterStateDriver(self, "visibility", "[@nameplate#, harm, exists] show; hide")

That would be really helpful for raid encounters like gorefiend....
So much possibilities *-*

zork	05-23-16 10:47 AM

Quote:

Originally Posted by syncrow (Post 315156)

@nameplate#

One million dollars.

syncrow

05-23-16 10:50 AM

Quote:

Originally Posted by zork (Post 315159)

One million dollars.

I don't really get it, but funny :D

lieandswell

05-23-16 10:55 AM

Quote:

Originally Posted by Resike (Post 315144)

Both the .unit values and the GetAttribute("unit") method returns "nameplate1-30" values, which is kinda useless.

Nameplate unitIDs work just fine for everything I've tried. But I did notice that while UNIT_HEALTH_FREQUENT gets called for all the nameplates, UNIT_HEALTH only works after you've targeted them once.

zork	05-23-16 11:31 AM

That is not new. Was the same problem for boss1-4 aswell.

Resike

05-23-16 11:45 AM

Quote:

Originally Posted by zork (Post 315155)

Resike that has to work. Otherwise you found a bug.

*edit* Tried it. Works both ways.

It's broken as hell, sometimes it's working sometimes it's not.
If you change the "Large NamePlates" or "Show All Nameplates" settings its 100% gonna be broken.

Seems like if you change thoose settings then the game rearranges the unitIDs, and NamePlate22 might get "nameplate1" unit attribute.

syncrow

05-23-16 11:56 AM

Quote:

Originally Posted by Resike (Post 315165)

It's broken as hell, sometimes it's wokring sometimes it's not.
If you change the "Large NamePlates" or "Show All Nameplates" settings its 100% gonna be broken.

Its not broken, its intented and has to be dynamic!

To always get the correct unitID for the specific plate you need to check its variable .namePlateUnitToken which reflects the unitID

You might have to update certain things manually whenever a nameplate is shown via "NAME_PLATE_UNIT_ADDED"

Edit: Raidframes work the exact same way, if you rearrange your raid group & switch your main tank from group 3 into group 1 the unitID for this tank also changes...

Resike

05-23-16 11:59 AM

Quote:

Originally Posted by syncrow (Post 315166)

It doesn't matter:

Lua Code:

NamePlate#.namePlateUnitToken
NamePlate#UnitFrame.unit
NamePlate#UnitFrame:GetAttribute("unit")

returns the same value all the time.

Lua Code:

NamePlate#UnitFrame.BuffFrame.unit
NamePlate#UnitFrame.DebuffFrame.unit

Sometimes returns the proper unit like: "target", "focus", but it's mostly the same as above.

Predicate

05-23-16 12:10 PM

That behavior is exactly correct. NamePlate1 is always associated with the unit "nameplate1". However, "nameplate1" can be associated with different units at different times, because nameplates are dynamically assigned. That is, UnitIsUnit("nameplate1", "target") can change from true to false even if you don't switch targets -- simply because the nameplates got rearranged. Currently, all nameplates get refreshed whenever any CVar changes (hence the behavior you're seeing with changing the nameplate settings).

Resike

05-23-16 12:19 PM

Quote:

Originally Posted by Predicate (Post 315169)

This is pretty dumb, because then you can never know when is your unitID is gonna get rearranged to something else. You can't hook every cvar change, and there is no event to listen.

Edit: It seems like cvar updates trigger the NAME_PLATE_UNIT_ADDED, NAME_PLATE_UNIT_REMOVED events so it's gucci if you update based on those.

ObbleYeah

05-23-16 12:54 PM

thats what i suggested on the last page!

some style options for units will also have to be independently updated with a more aggressive hook — the castbar has to be reconfigured more or less every time it is shown if you want to change its size etc. i think.

Resike

05-23-16 01:50 PM

Quote:

Originally Posted by syncrow (Post 315166)

Edit: Raidframes work the exact same way, if you rearrange your raid group & switch your main tank from group 3 into group 1 the unitID for this tank also changes...

Yes, but in partyframes UnitButton1 will always retun the "party1" unit attribute and even if you create a secure header with 1 single group and 30 unit columns UnitButton25 will always have the "party25" attribute, and so on. Here however seems like UnitFrameX can have any random "nameplateY" attribute and randomly rearrange them time to time. Which is confusing and possible root of bugs.

sirann

05-23-16 04:22 PM

Quote:

Originally Posted by Resike (Post 315173)

It's entirely possible I don't fully understand the problem, but could this be to prevent creation of accurate nameplate grids that allow for ridiculous micromanagement of debuffs? Instead of having to hunt and click moving nameplates, you could set a secureheader similar to what we do with party/raid frames, and never really have to look at the mobs, just your grid of clickable nameplates with debuffs and timers over their heads. By having them dynamically switch, it prevents this behavior, while still maintaining the accurate debuff tracking.

Resike

05-23-16 04:42 PM

Quote:

Originally Posted by sirann (Post 315175)

I don't know. I'm not sure what limitations this nameplate attribues have. You might be able to only track debuff/buffs on a plate that you have already targeted at least once. It would be intresting to create an unitframe and set a nameplate attribute for it, and check how does that works then.

lieandswell

05-23-16 05:09 PM

Quote:

Originally Posted by Resike (Post 315176)

You might be able to only track debuff/buffs on a plate that you have already targeted at least once.

I can confirm this isn't so. The default nameplate UI will show a few kinds of debuffs from other players. Just go look at the Orgrimmar training dummies on beta.

Ketho

05-23-16 08:55 PM

Quote:

Originally Posted by lieandswell (Post 315177)

The default nameplate UI will show a few kinds of debuffs from other players.

Why can't they just show your own castable (de)buffs just like in the CompactRaidFrames, instead of only a select few kind of debuffs? :mad:

Sorry I'm just ranting and not contributing

syncrow

05-23-16 09:59 PM

Quote:

Originally Posted by Ketho (Post 315180)

Why can't they just show your own castable (de)buffs just like in the CompactRaidFrames, instead of only a select few kind of debuffs?

Lua Code:

function NamePlateDriverMixin:OnUnitAuraUpdate(unit)
    ...
    filter = "HARMFUL|INCLUDE_NAME_PLATE_ONLY"
    ...
end

That's the snag. For All player based debuffs we need

Lua Code:

filter = "HARMFUL|PLAYER"

zork	06-05-16 05:38 AM

Options

Code:

DefaultCompactNamePlateFriendlyFrameOptions 

DefaultCompactNamePlateEnemyFrameOptions 

DefaultCompactNamePlateFrameSetUpOptions 

DefaultCompactNamePlatePlayerFrameOptions 

DefaultCompactNamePlatePlayerFrameSetUpOptions

https://github.com/tomrus88/Blizzard...rame.lua#L1615

Lua Code:

local groups = {
  "Friendly",
  "Enemy",
}
 
for i, group  in next, groups do
  for key, value in next, _G["DefaultCompactNamePlate"..group.."FrameOptions"] do
    print(group, key,value)
  end
end

NamePlate table & NamePlate.UnitFrame table

Lua Code:

local function OnNamePlateCreated(args1, frame)
  print("==================")
  print("OnNamePlateCreated", frame)
  for key, value in next, frame do
    print(key,value)
  end
  print("------------------")
  print("printint nameplate.UnitFrame keys:")
  for key, value in next, frame.UnitFrame do
    print(key,value)
  end
end
 
rLib:RegisterCallback("NAME_PLATE_CREATED", OnNamePlateCreated)

NamePlateDriverFrame

Lua Code:

print("==================")
print("NamePlateDriverFrame")
for key, value in next, NamePlateDriverFrame do
  print(key,value)
end

NamePlateUnitFrameTemplate

https://github.com/tomrus88/Blizzard...NamePlates.xml

Code:

<Button name="NamePlateUnitFrameTemplate" parentKey="UnitFrame" setAllPoints="true" useParentLevel="true" virtual="true">



  <KeyValue key="disableMouse" value="true" type="boolean"/>



    <Frames>

      <StatusBar parentKey="healthBar" frameLevel="90">

          <Frame parentKey="border" inherits="NamePlateFullBorderTemplate" />

            <Texture parentKey="background">

              <Color r=".2" g=".2" b=".2" a=".85"/>

        <BarTexture parentKey="barTexture" file="Interface/TargetingFrame/UI-TargetingFrame-BarFill" />

      

      <StatusBar parentKey="castBar" frameLevel="100" hidden="true">

          <KeyValue key="iconWhenNoninterruptible" value="true" type="boolean"/>

            <Texture parentKey="background">

              <Color r=".2" g=".2" b=".2" a=".85"/>

            <FontString parentKey="Text" inherits="SystemFont_Shadow_Small">

            <Texture parentKey="BorderShield" atlas="nameplates-InterruptShield" hidden="true" forceAlpha="true">

            <Texture parentKey="Icon" hidden="true" forceAlpha="true">

            <Texture parentKey="Spark" file="Interface\CastingBar\UI-CastingBar-Spark" alphaMode="ADD">

            <Texture parentKey="Flash" file="Interface\TargetingFrame\UI-TargetingFrame-BarFill" alphaMode="ADD" />

        <Scripts>

          <OnLoad>

            CastingBarFrame_OnLoad(self, nil, false, true);

          <OnEvent function="CastingBarFrame_OnEvent" />

          <OnUpdate function="CastingBarFrame_OnUpdate" />

          <OnShow function="CastingBarFrame_OnShow" />

        <BarTexture file="Interface\TargetingFrame\UI-StatusBar"/>

        <BarColor r="1.0" g="0.7" b="0.0"/>



      <Frame parentKey="BuffFrame" inherits="HorizontalLayoutFrame" mixin="NameplateBuffContainerMixin">

          <KeyValue key="spacing" value="4" type="number"/>

          <KeyValue key="fixedHeight" value="14" type="number"/>

        <Scripts>

          <OnLoad method="OnLoad"/>

          <OnEvent method="OnEvent"/>



      <Frame parentKey="RaidTargetFrame">

            <Texture parentKey="RaidTargetIcon" file="Interface\TargetingFrame\UI-RaidTargetingIcons" hidden="true">



    <Layers>

        <Texture parentKey="myHealPrediction"/>

        <Texture parentKey="otherHealPrediction"/>

        <Texture parentKey="totalAbsorb"/>

        <Texture parentKey="totalAbsorbOverlay"/>

        <FontString parentKey="name" inherits="SystemFont_NamePlate" wordwrap="false" justifyH="CENTER">

        <FontString parentKey="statusText" inherits="GameFontDisable" />

        <Texture parentKey="myHealAbsorb"/>

        <Texture parentKey="myHealAbsorbLeftShadow" file="Interface\RaidFrame\Absorb-Edge"/>

        <Texture parentKey="myHealAbsorbRightShadow" file="Interface\RaidFrame\Absorb-Edge">

        <Texture parentKey="overAbsorbGlow"/>

        <Texture parentKey="overHealAbsorbGlow"/>

        <Texture parentKey="selectionHighlight" file="Interface/TargetingFrame/UI-TargetingFrame-BarFill" alpha=".25" forceAlpha="true" alphaMode="ADD">

        <Texture parentKey="aggroHighlight" file="Interface/TargetingFrame/UI-TargetingFrame-BarFill" alpha="0" alphaMode="ADD">

          <Color r="1" g="1" b="0"/>

    

    <Animations>

      <AnimationGroup parentKey="LoseAggroAnim" setToFinalAlpha="true">

        <Alpha childKey="aggroHighlight" duration=".25" fromAlpha="1" toAlpha="0" order="1"/>

        <Alpha childKey="aggroHighlight" duration=".25" fromAlpha="1" toAlpha="0" order="2"/>

    <Scripts>

      <OnLoad function="CompactUnitFrame_OnLoad"/>

https://github.com/tomrus88/Blizzard...Frame.lua#L598

zork	06-10-16 12:46 AM

Finished editing the nameplates. Blizzard made it really easily to adjust the style.

Castbars:

Aggro border (not the default one):

https://github.com/zorker/rothui/blo...Plate/core.lua

zork	06-20-16 12:56 PM

Nameplates have a new option for the ClassificationFrame as far as I can tell.

template: https://github.com/tomrus88/Blizzard...lates.xml#L375
update function: https://github.com/tomrus88/Blizzard...rame.lua#L1615

Ketho

07-25-16 04:52 PM

Quote:

Originally Posted by syncrow (Post 315182)

For All player based debuffs we need

Lua Code:

filter = "HARMFUL|PLAYER"

I tried to show all (harmful) spells from the player, but didn't work :(

When I tried Hemorrhage, nameplateShowPersonal always seemed to be false
Is it maybe because it's a talent?

While for Shadow Word: Pain, nameplateShowPersonal it was true

https://gfycat.com/DeterminedDarkCarpenterant

Lua Code:

hooksecurefunc(NamePlateDriverFrame, "OnUnitAuraUpdate", function(self, unit)
    local filter;
    if UnitIsUnit("player", unit) then
        filter = "HELPFUL|INCLUDE_NAME_PLATE_ONLY";
    else
        local reaction = UnitReaction("player", unit);
        if reaction and reaction <= 4 then
            -- Reaction 4 is neutral and less than 4 becomes increasingly more hostile
            filter = "HARMFUL|PLAYER";
        else
            filter = "NONE";
        end
    end
 
    local nameplate = C_NamePlate.GetNamePlateForUnit(unit);
    if (nameplate) then
        nameplate.UnitFrame.BuffFrame:UpdateBuffs(nameplate.namePlateUnitToken, filter);
    end
 
    -- debug
    local name, rank, texture, count, debuffType, duration, expirationTime, caster, _, nameplateShowPersonal, spellId, _, _, _, nameplateShowAll = UnitAura(nameplate.namePlateUnitToken, 1, filter)
    if nameplateShowPersonal ~= nil then -- still want boolean false
        print(nameplate.namePlateUnitToken, filter, name, caster, nameplateShowAll, nameplateShowPersonal, (nameplateShowPersonal and (caster == "player" or caster == "pet" or caster == "vehicle")))
    end
end)

NamePlateDriverMixin:OnUnitAuraUpdate
NameplateBuffContainerMixin:UpdateBuffs

Miiru

07-28-16 01:05 AM

Anyone found a solution to modify the shield icon with non-interruptable casts?

frame.castBar.BorderShield is the refference to the bar, but that icon is unnamed?

zork	07-28-16 01:13 AM

You can use :GetRegion or GetChildren to access child objects. But are you sure that borderShield is not of type texture?

Miiru

07-28-16 01:21 AM

Quote:

Originally Posted by zork (Post 317123)

You can use :GetRegion or GetChildren to access child objects. But are you sure that borderShield is not of type texture?

Yes, my bad. It indeed seems to be the shield texture.

All times are GMT -6. The time now is 04:06 PM.

Page 1 of 2

Show 60 post(s) from this thread on one page