API Issue: GuildControlSetRank protected

Bug Report
It appears that the GuildControlSetRank() function is now marked protected, so the GuildControlGetRankFlags() is now returning incorrect data.


guild, name, rank = GetGuildInfo('player')
GuildControlSetRank(rank+1)
for i, v in ipairs({GuildControlGetRankFlags()}) do
local flag = _G["GUILDCONTROL_OPTION"..i]
print(rank, i, flag, v)
end


Output:


0 1 Guildchat Listen false
0 2 Guildchat Speak false
0 3 Officerchat Listen false
0 4 Officerchat Speak false
0 5 Promote false
0 6 Demote false
0 7 Invite Member false
0 8 Remove Member false
0 9 Set MOTD false
0 10 Edit Public Note false
0 11 View Officer Note false
0 12 Edit Officer Note false
0 13 Modify Guild Info false
0 14 Create Guild Event false
0 15 Guild Bank Repair false
0 16 Withdraw Gold false
0 17 Create Guild Event false
0 18 Requires Authenticator false
0 19 Modify Bank Tabs false
0 20 Remove Guild Event false
Part of the issue seems to be timing. Even though I'm waiting until PLAYER_ENTERING_WORLD fires, the call to GetGuildInfo('player') is returning nil values except guild rank which returns a zero value.

If I then do a /reload in game, the call to GetGuildInfo('player') now returns correct values.

However, in either case, the call to GuildControlGetRankFlags() returns false for all values.

Edit:
I have tried passing a parm to GuildControlGetRankFlags() like 1, "2", and "player". All of which are apparently invalid and/or ignored.

Also, items 14 and 17 are returning the same name "Create Guild Event".
08/31/2017 06:47 AMPosted by Riverhawk
Part of the issue seems to be timing. Even though I'm waiting until PLAYER_ENTERING_WORLD fires, the call to GetGuildInfo('player') is returning nil values except guild rank which returns a zero value.

If I then do a /reload in game, the call to GetGuildInfo('player') now returns correct values.


I've found that you need to wait for PLAYER_GUILD_UPDATE to fire before you can get valid guild information. Since I'm also looking for the guild info tab contents, I have to wait for GUILD_ROSTER_UPDATE to fire a few times and check to the data. too.

Either way, the fact that GuildControlSetRank is now a protected function isn't a timing issue, and it's a big problem if no user-space function was provided to access the rank data.
09/01/2017 07:51 AMPosted by Stigg

I've found that you need to wait for PLAYER_GUILD_UPDATE to fire before you can get valid guild information. Since I'm also looking for the guild info tab contents, I have to wait for GUILD_ROSTER_UPDATE to fire a few times and check to the data. too.


Thanks for the suggestion. I have been able to develop a work-a-round for the guild information. I did not use PLAYER_GUILD_UPDATE as that seems to be fired only when a player joins, leaves or is removed from the guild roster. However, making a call to GuildRoster() and waiting for Guild_ROSTER_UPDATE does seem to provide the solution I needed.

09/01/2017 07:51 AMPosted by Stigg

Either way, the fact that GuildControlSetRank is now a protected function isn't a timing issue, and it's a big problem if no user-space function was provided to access the rank data.


I totally agree. A major functionality of one of my addons is broken until this information is available.
Just wanted to add, "GuildControlSetRank" and many other guild API is now protected as of patch 7.3 and has literally bricked many guild addons.

There was already very limited development in this space, and for the little that was there, Blizz has torpedo'd it.

I am a developer myself "Guild Roster Manager" and while my addon isn't completely broken, I have had to remove the ability to promote/demote players, and removed the ability to kick players through the addon.

Furthermore, my addon needs to do a boolean check on if a player can chat on the guild chat channel, as some guilds might have a punishment rank where that is silenced, and if so, backend comms through "SendAddonMessage()" will not work. You used to be able to just pull the data you are looking for here, but now I have to be creative in pulling the data, so what I do is I send a comm channel to myself over the server, and if I receive it or not I know if I have access to the chat, even though this affects only a small portion people, I still had enough telling me of the issues.

But omg, it is so inefficient. I understand Blizz removing the kicking of players or rank changing as they can be abused, but why the heck would Blizz change this one? Restrict making changes, but at least let us get the boolean info. It literally bricks so many guild addons out there.
I guess someone sneaking in a gdisband into a weakaura ruined it for everyone :(


I am a developer myself "Guild Roster Manager" and while my addon isn't completely broken, I have had to remove the ability to promote/demote players, and removed the ability to kick players through the addon.

Furthermore, my addon needs to do a boolean check on if a player can chat on the guild chat channel, as some guilds might have a punishment rank where that is silenced, ...

But omg, it is so inefficient. I understand Blizz removing the kicking of players or rank changing as they can be abused, but why the heck would Blizz change this one? Restrict making changes, but at least let us get the boolean info. It literally bricks so many guild addons out there.

I really wonder if blizz has decided that guild functionality is no longer a needed/wanted thing in the game anymore. It seems that they prefer the use of lfg and lfr instead of people guilding together.

I, too, was using the logicals to determine if players could use the guild and officer chat channels in order to provide additional functionality (Players frequently get busy and miss chat box messages. I provide an optional popup notification as well as an optional audible alert for appropriate incoming chat channel messages. I can still do that, but I can no longer make those options unavailable for people that can't participate in particular channels. It is misleading to them as they think they will be able to see officer chat, for example, when they can't.).

I don't think I can agree that I understand blizz removing the promote/demote functions because of them being abused. These are guild functions. Any organized body needs to be structured so that the leader can delegate functionality, or it can never grow beyond what the leader can handle and is way too inefficient . If that delegated functionality is abused, then the abusing person should be reprimanded by the leader. If it is the leader himself that is doing the abusing, the guild (in our case) would not last long because people would leave seeking a friendlier place. Even if there was a lot of abuse, that functionality should not be straining servers to perform them. So, in short, I don't see why the ability to perform delegated functionality through addons is being whacked unless blizz is intentionally downplaying guild activities.

09/09/2017 03:26 AMPosted by Teelo
I guess someone sneaking in a gdisband into a weakaura ruined it for everyone :(

Is this something new? I thought this happened quite a while back and had been fixed already. I totally think gdisband is a gleader function and should belong only in the guild functionality panels provided by blizz, not through an addon. However, if someone is writing code that is abusing functionality such as promoting and/or demoting over and over - an addon could do that a lot of times per second - then they are the bad apples that have sadly spoiled the barrel for the rest of us.
09/10/2017 07:45 AMPosted by Riverhawk

09/09/2017 03:26 AMPosted by Teelo
I guess someone sneaking in a gdisband into a weakaura ruined it for everyone :(

Is this something new? I thought this happened quite a while back and had been fixed already. I totally think gdisband is a gleader function and should belong only in the guild functionality panels provided by blizz, not through an addon. However, if someone is writing code that is abusing functionality such as promoting and/or demoting over and over - an addon could do that a lot of times per second - then they are the bad apples that have sadly spoiled the barrel for the rest of us.


The GuildControlSetRank function is necessary to determine what abilities a rank has. If Blizzard meant to address abuse of the abilities themselves, the "fix" has a far larger scope than the problem.
09/10/2017 11:10 PMPosted by Stigg
09/10/2017 07:45 AMPosted by Riverhawk

...
Is this something new? I thought this happened quite a while back and had been fixed already. I totally think gdisband is a gleader function and should belong only in the guild functionality panels provided by blizz, not through an addon. However, if someone is writing code that is abusing functionality such as promoting and/or demoting over and over - an addon could do that a lot of times per second - then they are the bad apples that have sadly spoiled the barrel for the rest of us.


The GuildControlSetRank function is necessary to determine what abilities a rank has. If Blizzard meant to address abuse of the abilities themselves, the "fix" has a far larger scope than the problem.

I think, technically, GuildControlSetRank is still available, but ONLY to guild masters on the guild control panels used by the guild master - my guild master character can still see those values and perform those functions. If you export the current code and look in Blizzard_GuildControlUI.lua you can see it is still used. However, it is "protected" and not available to addons, and there is the rub. We can't write addons that need to "see" those flags in order to provide useful functionality. And, yes, I am in agreement that blizz missed the boat with the "fix" they have implemented.
09/11/2017 08:13 AMPosted by Riverhawk

I think, technically, GuildControlSetRank is still available, but ONLY to guild masters on the guild control panels used by the guild master - my guild master character can still see those values and perform those functions. If you export the current code and look in Blizzard_GuildControlUI.lua you can see it is still used. However, it is "protected" and not available to addons, and there is the rub. We can't write addons that need to "see" those flags in order to provide useful functionality. And, yes, I am in agreement that blizz missed the boat with the "fix" they have implemented.


The call is still tainted if issued by a GM, the capture in the OP was taken on a character that was GM.

My use case (for the GreenWall add-on) is using it to determine if another member within a guild is an officer, which I define as having access to officer chat and officer notes. I can work around figuring out if the character running the add-on is an officer by looking for ochat or trying to read an officer note(which is akin to answering "is it a duck?" by asking "does it quack?"). Unfortunately, I can't determine if another guild is an officer this way.

While I appreciate the hassle this creates for actual guild management add-ons, I can accept that it's Blizzard's prerogative to limit the functionality to prevent malicious or harmful activity. What I do think they should do is provide a wrapper for the protected functions that allows read-only access to the rank capabilities for tainted code.
09/08/2017 07:02 PMPosted by Arkaan
Just wanted to add, "GuildControlSetRank" and many other guild API is now protected as of patch 7.3 and has literally bricked many guild addons.

There was already very limited development in this space, and for the little that was there, Blizz has torpedo'd it.


One of the addons I wrote is completely destroyed by this change. The point was to provide an overview of guild rank capabilities, but now that we can't even query the capabilities of any rank from any addon, the whole thing is shot. With no explanation.

Somebody with a Twitter account please ask the devs if this was intended as part of their "don't let weakauras disband guilds" sweep.

Join the Conversation

Return to Forum