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.


All times are GMT -6. The time now is 12:53 PM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI