WoWInterface

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:
  1. Cursor:SetAttribute("GetPlates", [[
  2.     Plates = wipe(Plates)
  3.     Visible = 0
  4.  
  5.     for i, frame in pairs(newtable(WorldFrame:GetChildren())) do
  6.         local name = frame:GetName()
  7.         if name and strmatch(name, "NamePlate") and frame:IsShown() then
  8.             local unitFrame = frame:GetChildren() -- returns nil in combat
  9.             local unit = unitFrame and unitFrame:GetAttribute("unit")
  10.             if unitFrame and unit and PlayerCanAttack(unit) then
  11.                 Plates[unitFrame] = true
  12.             end
  13.             Visible = Visible + 1
  14.         end
  15.     end
  16. ]])

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:
  1. local activeUnitPlates = {}
  2.  
  3. local function AddNameplate(unitID)
  4.     local nameplate = C_NamePlate.GetNamePlateForUnit(unitID)
  5.     local unitframe = nameplate.UnitFrame
  6.  
  7.     -- store nameplate and its unitID
  8.     activeUnitPlates[unitframe] = unitID
  9. end
  10.  
  11. local function RemoveNameplate(unitID)
  12.     local nameplate = C_NamePlate.GetNamePlateForUnit(unitID)
  13.     local unitframe = nameplate.UnitFrame
  14.    
  15.     -- recycle the nameplate
  16.     activeUnitPlates[unitframe] = nil
  17. end
  18.  
  19. local frame = CreateFrame("Frame")
  20. frame:RegisterEvent("NAME_PLATE_UNIT_ADDED")
  21. frame:RegisterEvent("NAME_PLATE_UNIT_REMOVED")
  22.  
  23. frame:SetScript("OnEvent", function(self,event,...)
  24.     if event == "NAME_PLATE_UNIT_ADDED" then
  25.         local unitID = ...
  26.         AddNameplate(unitID)
  27.     end
  28.    
  29.     if event == "NAME_PLATE_UNIT_REMOVED" then
  30.         local unitID = ...
  31.         RemoveNameplate(unitID)
  32.     end
  33. 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'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.

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'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.

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

Lua Code:
  1. Plates = wipe(Plates)
  2. Visible = 0
  3.  
  4. for i, frame in pairs({WorldFrame:GetChildren()}) do
  5.     local name = frame:GetName()
  6.     if name and strmatch(name, "NamePlate") and frame:IsShown() then
  7.         local unitFrame = frame:GetChildren()
  8.         local unit = unitFrame and unitFrame:GetAttribute("unit")
  9.         if unitFrame and unit then
  10.             Plates[unitFrame] = true
  11.         end
  12.         Visible = Visible + 1
  13.     end
  14. 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)
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.

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.

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)
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.

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)
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.

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)
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#.

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:
  1. -- for example
  2. nameplate.UnitFrame
  3. nameplate.UnitFrame.unit
  4. nameplate.UnitFrame.healthBar
  5. 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'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

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'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

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'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.

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:
  1. 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:
  1. 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)
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 certained things manually whenever a nameplate is shown via "NAME_PLATE_UNIT_ADDED"

It doesn't matter:

Lua Code:
  1. NamePlate#.namePlateUnitToken
  2. NamePlate#UnitFrame.unit
  3. NamePlate#UnitFrame:GetAttribute("unit")

returns the same value all the time.

Lua Code:
  1. NamePlate#UnitFrame.BuffFrame.unit
  2. 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)
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).

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)
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.

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)
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.

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:
  1. function NamePlateDriverMixin:OnUnitAuraUpdate(unit)
  2.     ...
  3.     filter = "HARMFUL|INCLUDE_NAME_PLATE_ONLY"
  4.     ...
  5. end

That's the snag. For All player based debuffs we need
Lua Code:
  1. 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:
  1. local groups = {
  2.   "Friendly",
  3.   "Enemy",
  4. }
  5.  
  6. for i, group  in next, groups do
  7.   for key, value in next, _G["DefaultCompactNamePlate"..group.."FrameOptions"] do
  8.     print(group, key,value)
  9.   end
  10. end



NamePlate table & NamePlate.UnitFrame table

Lua Code:
  1. local function OnNamePlateCreated(args1, frame)
  2.   print("==================")
  3.   print("OnNamePlateCreated", frame)
  4.   for key, value in next, frame do
  5.     print(key,value)
  6.   end
  7.   print("------------------")
  8.   print("printint nameplate.UnitFrame keys:")
  9.   for key, value in next, frame.UnitFrame do
  10.     print(key,value)
  11.   end
  12. end
  13.  
  14. rLib:RegisterCallback("NAME_PLATE_CREATED", OnNamePlateCreated)



NamePlateDriverFrame

Lua Code:
  1. print("==================")
  2. print("NamePlateDriverFrame")
  3. for key, value in next, NamePlateDriverFrame do
  4.   print(key,value)
  5. 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:
  1. 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?
https://gfycat.com/DeterminedDarkCarpenterant

Lua Code:
  1. hooksecurefunc(NamePlateDriverFrame, "OnUnitAuraUpdate", function(self, unit)
  2.     local filter;
  3.     if UnitIsUnit("player", unit) then
  4.         filter = "HELPFUL|INCLUDE_NAME_PLATE_ONLY";
  5.     else
  6.         local reaction = UnitReaction("player", unit);
  7.         if reaction and reaction <= 4 then
  8.             -- Reaction 4 is neutral and less than 4 becomes increasingly more hostile
  9.             filter = "HARMFUL|PLAYER";
  10.         else
  11.             filter = "NONE";
  12.         end
  13.     end
  14.  
  15.     local nameplate = C_NamePlate.GetNamePlateForUnit(unit);
  16.     if (nameplate) then
  17.         nameplate.UnitFrame.BuffFrame:UpdateBuffs(nameplate.namePlateUnitToken, filter);
  18.     end
  19.  
  20.     -- debug
  21.     local name, rank, texture, count, debuffType, duration, expirationTime, caster, _, nameplateShowPersonal, spellId, _, _, _, nameplateShowAll = UnitAura(nameplate.namePlateUnitToken, 1, filter)
  22.     if nameplateShowPersonal ~= nil then -- still want boolean false
  23.         print(nameplate.namePlateUnitToken, filter, name, caster, nameplateShowAll, nameplateShowPersonal, (nameplateShowPersonal and (caster == "player" or caster == "pet" or caster == "vehicle")))
  24.     end
  25. 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 06:03 PM.

vBulletin © 2020, Jelsoft Enterprises Ltd
© 2004 - 2020 MMOUI