SecurePartyHeaderTemplate
Is it possible to create a party frame with this template which always shows your group?
I have tried to mess around with the attributes, but no luck so far. I would need something like this but securely: Lua Code:
|
I could be wrong, but don't the PartyX UnitIDs point to raid members in your group?
|
Quote:
I managed to hack in to the initialConfigFunction like this: Lua Code:
I'm just not sure how valid is this solution, still testing. The main goal would be to properly show the player's party when in raid too. |
The easiest way I can think of is to just create a static number of party frames. Changing the UnitFrame's unit after it's created may cause problems as the SecureGroupHeader will still create frames and rearrange them based on its own settings.
There is a quirk that I spotted looking at Blizzard's code. They use IsInGroup() to check if the player is in a party and from what I can dig up, should return true if in a raid as well. They don't have any seperate check in the same section to see if you're in a raid. This means if you only set the showParty attribute, it should pop up with your group in raid. This is all in theory, don't be surprised if it doesn't work. :D |
Quote:
If i only use the showParty attribute the party header works fine, because it only shows up in a party and while in a party there is only one group. But i would like to give the user an option to keep the party frame shown even while in raid. IsInGroup() could work perfectly fine if there is an IsInRaid() before it in a if-else/or statement. |
The intresting part is that i might be able to also create arena and boss frames with this method too.
|
ArenaFrames, maybe since the sides are always balanced. BossFrames on the other hand would have a problem with people going into older raids solo or duo depending on the encounter. For example, if 2 people start an encounter that shows 5 BossFrames, only 2 frames would be created since the header is still looking at the size of the raid group instead the number of BossFrames needed for an encounter.
Another problem is that the buttons themselves aren't shuffled around. The header builds a sorting list from its configuration and reassigns the unit for each button according to its list. This means UnitButton1 would be assigned the first in the list, UnitButton2 would be the second on the list, and so on. This would end up overwriting your initial configuration immediately and every time the group composition changes. Even if this were handled with a SecureHandlerAttributeTemplate watching the unit attribute, sorting would be completely disabled and filter settings may truncate the list occasionally. This info is from looking at SecureGroupHeader_Update() and its local helper function configureChildren(). |
Quote:
The sorting seems to be handled with the initially registered unit attribute, so it works properly even with the overridden units. You can test it by yourself: https://github.com/Resike/Z-Perl2 Just overwrite this variable to true: https://github.com/Resike/Z-Perl2/bl...ZPerl2.lua#L58 If you also uncomment this line: https://github.com/Resike/Z-Perl2/bl...arty.lua#L1240 Then you have a alphabetically sorted party frame. I written the party module yesterday, so there could be some possible flaws still. |
I honestly don't have any way to test this in a raid environment. Hence why I've been going off how Blizzard's code would react to the suggested changes.
As the title of the topic said SecurePartyHeaderTemplate, I assumed you meant SecureGroupHeaderTemplate. Looking at your code, the only header template I see is SecureAuraHeaderTemplate. |
Quote:
https://github.com/Resike/Z-Perl2/bl...arty.lua#L1225 |
I still don't see how it can work, but if you got it to, then there isn't much to be done. Without any way to stress test it, there's no way to tell how it'll fail even if it would. In order to put the code through its paces, we'll need to build up a raid of people and test moving people through different groups and mixed role settings (some set, some not). Unfortunately, I don't have access to enough people that'll be willing to stand around for hours on end while I debug code.
|
Quote:
|
All times are GMT -6. The time now is 11:46 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI