SecureAuraHeaderTemplate
I was experimenting to update secure aura headers without the "UNIT_AURA" event and without updating every auras every time unnecessary.
I came up with this: Lua Code:
With this method only the changed buffs are gonna get updated and it will leave out the ones which did not changed, so you can save a lot of unnecessary calls. You only need to do a full force update when you: on a loading screen, or when the unit attribute changes. So what do you guys think could this be a valid solution? |
What is triggering the index change?
Does this work if you refresh an aura? Does this work if you refresh an aura and only have one aura active? |
Quote:
For some reason by default the aura header template updates every buffs on every attribute chanes unlike the group headers, and thats the real issue here. And the UNIT_AURA event doesn't give any valid information about which buffs you should update, so you are kinda forced to update everything there too. It works on pretty much any buff changes/refresh because of the index/spellID/expirationTime checker. Additional checkers can be added too, there are just the basic ones, like unitCaster and isCastByPlayer could be usefull too, if someone cast the same buff on you without expiration time, to the same index. The good thing about this, it skips any unchanges or static buffs, that you did not changed or refreshed. |
That is my point. When using the SecureAuraHeaderTemplate something is triggering an update on any aura attribute for you which makes is possible to have a script for OnAttributeChanged?
|
Quote:
The attribute is not on the header frame, but on the frame which gets created BY the header frame (SecureActionButtonTemplate), and it has a index and filter attribute changes every time the unit's buffs get updated: Lua Code:
It looks kinky to create so many functions for every buffs, but even in a 5 man party we are talking about 400 unit and 400 potential pet buffs and god knows how many UNIT_AURA triggers. And for my initial test this method is better performace wise. Maybe the thread's name is missleading. My bad. |
No it is not misleading. I'm just trying to understand what is triggering attribute change. Gonna play around with it myself later.
I think I found what I was looking for: https://github.com/tekkub/wow-ui-sou...aders.lua#L668 Using the template registers UNIT_AURA. Have you read this post from sigg? http://www.wowinterface.com/forums/s...ad.php?t=36117 Btw make sure you implement the cancelaura stuff only for player unit. |
Quote:
I don't think cancelaura could cause any issue. And since you can remove buffs from your vehicle/pet it's better to leave it. And i still can't decide yet, if i want to use secure aura headers or simple textures on the target and focus frames. |
SecureAuraHeader is only useful if you want sorting. Otherwise SecureActionButton should be enough. But the ability to sort auras by own_auras_first is amazing. That is really damn helpful, on any unit. Just think of healers. I do not want to search for my heal over time in 40 auras?! This might make a lot of aura filtering obsolete aswell. One only had to use those because one could not find his own heal over time or debuff.
That being said. There is already a function for OnAttributeChanged. Maybe you can hook it for the desired affect. Currently you use SetScript. Which is bad. If possible always go for HookScript. (Well if the override is not intended of course) Additionally I'm not sure if Blizzard is changing that part for Legion. |
Quote:
HookScript is not usefull here, since than there would be another attribute funcition ticking in the background pointlessly. I also have some issues with the temporary enchant frames, for some reason the header is showing 2 tempenchant buffs all the time, no matter if you only have 1 temporary weapon enchants. |
Yeah I'm not even sure if tempenchants work properly.
Has 2 entries https://github.com/tekkub/wow-ui-sou...aders.lua#L724 Loops over 3 entries https://github.com/tekkub/wow-ui-sou...aders.lua#L795 |
Quote:
https://github.com/tekkub/wow-ui-sou...aders.lua#L793 They use the old GetWeaponEnchant() arguments, instead of the live one: Lua Code:
Somebody poke Blizzard about this, i want a working tempenchant frame. |
Maybe you can PM alestane. I'm pretty sure he wrote that part. http://www.wowinterface.com/portal.php?id=353
|
Quote:
Lua Code:
And it fixes the issue, so i'm pretty sure that problem is what mentioned above: However it breaks the functionality of the whole temp enchants frames. |
It also breaks every other addon that deals with temporary enchants.
|
Quote:
|
If Blizzard actually used their own code in their own UI they might be more interested in making all the Secure* features work well and have enough functionality to implement a true alternative to Blizzard's UI. Sadly Blizzard just gets to cheat and never worry about whether their new features and UI designs work with secure frames and headers.
It took them more than a year to add ranged weapon enchants to the secure aura headers after they were added to the game. No-one at Blizzard even knew it was broken, because nobody there uses the code they wrote. And not many people reported it because nobody outside Blizzard uses secure aura frames either, due to the fact that it never supported filtering or sorting or anything a real aura addon would need. And all this because a few druids in tree form were auto-cancelling their tree aura when a warlock tried to banish them. Hey, maybe now that treeform doesn't exist we can get aura cancelling unprotected and do away with the entire secure aura header system? Somehow I don't see it happening any time soon though. Unless Blizzard had to use their own code anyway, in which case it would have happened five years ago. |
Quote:
But the main issue is that if somebody wants to cheat they can do it so easily. Either remove the lua restrictions (And i don't think anyone ever got banned for it.), or recently i reverse engineered an interrupt bot program, which was working with an ingame addon. The addon created a 1x1 pixel texture in the corner of you screen and listened cast releated events and colorded that pixel based on that information. And outside the game another program just checked the color of the pixel and initiated a keydown action directly from windows which was your interrupt keybind. So my question is that is the secure stuff worth the protection it gives, because i highly don't think so. If at least we could SetPoint in combat i would be so happy. And would solve 90% of the addon blocked issues. |
Back on my issue tho, yesterday i came up with a temporary solution to show the icon of your secodary weapon instead of the blank unclickable frame:
|
Quote:
|
Quote:
Why would i use a workaround on a buggy frame, which breaks the frame functionalities even more. |
All times are GMT -6. The time now is 02:08 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI