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:
Any suggestions on how to solve this, if it's even possible? |
Quote:
Lua Code:
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! |
Yes it sounds really awesome.
|
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.
|
Quote:
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. |
Quote:
Lua Code:
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. |
Quote:
|
Quote:
Quote:
Quote:
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. |
Quote:
|
Quote:
|
Quote:
|
Quote:
|
Quote:
|
Quote:
Lua Code:
|
Quote:
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. |
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.
|
Quote:
Probably violates the ToS/EULA in some way, I tried it out in Diablo last season. |
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. |
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 |
Quote:
|
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 |
Nameplates are now normal unitframes with unitids. They have all the features as any other unitframe.
|
Quote:
|
Quote:
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. |
Quote:
|
Quote:
Also: I doubt it that you can sort nameplates by role/class/name/party etc. |
Quote:
|
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 |
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
|
Quote:
|
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? |
I've found issues with the .unit value too
the first argument for NAME_PLATE_UNIT_ADDED should be the base unitid |
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:
http://wowprogramming.com/docs/api/UnitGUID |
Quote:
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. |
Quote:
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:
Quote:
So "nameplate#" can be the same unit as raid# / player / target / focus .... |
Resike that has to work. Otherwise you found a bug.
*edit* Tried it. Works both ways. Quote:
|
It should be possible to create a "enemy nameplate grid" using SecureUnitButtonTemplate / SecureHandlerStateTemplate with this conditions:
Lua Code:
That would be really helpful for raid encounters like gorefiend.... So much possibilities *-* |
Quote:
|
Quote:
|
Quote:
|
That is not new. Was the same problem for boss1-4 aswell.
|
Quote:
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. |
Quote:
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... |
Quote:
Lua Code:
returns the same value all the time. Lua Code:
Sometimes returns the proper unit like: "target", "focus", but it's mostly the same as above. |
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).
|
Quote:
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. |
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. |
Quote:
|
Quote:
|
Quote:
|
Quote:
|
Quote:
Sorry I'm just ranting and not contributing |
Quote:
Lua Code:
That's the snag. For All player based debuffs we need Lua Code:
|
Options
Code:
DefaultCompactNamePlateFriendlyFrameOptions Lua Code:
NamePlate table & NamePlate.UnitFrame table Lua Code:
NamePlateDriverFrame Lua Code:
NamePlateUnitFrameTemplate https://github.com/tomrus88/Blizzard...NamePlates.xml Code:
<Button name="NamePlateUnitFrameTemplate" parentKey="UnitFrame" setAllPoints="true" useParentLevel="true" virtual="true"> |
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 |
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 |
Quote:
I tried to show all (harmful) spells from the player, but didn't work :(
Lua Code:
NameplateBuffContainerMixin:UpdateBuffs |
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? |
You can use :GetRegion or GetChildren to access child objects. But are you sure that borderShield is not of type texture?
|
Quote:
|
All times are GMT -6. The time now is 08:43 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI