LibGuildBankComm-1.0 is designed for bag and inventory addons to communicate the contents of the Guild Bank, regardless of the addon in question. Bag and Inventory addons will need to embed this lib (I think) as it isn't automatic unless you have this lib.
I will do up some docs after the project is finished, approved, .. even created on wowace. Right now it isn't created, because I need feedback. This is my first attempt at writing a library file, and I'm sure I botched something.
Thus far, the two callbacks are GuildBankComm_RosterUpdate(unit, contents) and GuildBankComm_ContentsChanged(unit, contents). The first fires when someone new joins the guild, and the second fires when the contents of the guild bank change, whether money or items.
Do not use this lib with any addons right now! It isn't working, and the _ContentsChanged() callback is missing in places. What I need is people to teach me how to scan tabs for items, adding them to gbContents.numTab.item one, gbContents.numTab.item two, etc, because I couldn't quite figure that part out. If it is not needed to have the tab number, that's fine.
Please poke sticks at this, tell me where I went wrong, what you want to see added (is there any APIs you want?) and generally go over this with the fine tooth comb, please. Xinhuan was mentioning something about the .pkgmeta, which I did not provide, but if there is something special I need to do in the .pkgmeta, then I do not know what it is. I was just going to create a normal .pkgmeta file.
When it is working, any authors using this lib will also need AceAddon-3.0, AceEvent-3.0, and AceComm-3.0 along with LibStub and CallbackHandler-1.0.
While I don't intend to write any specifics as to the wow's guild bank API, you can see how I use it to store guild bank information in BankItems when certain guild bank events fire.
You could also look at MobileVault to learn about using the API Gbank functions.
Although I have to ask, why do we need a lib for this? It would seem that most users would only have maybe 1 or 2 addons that would interact with the guild bank... (I'm really just asking, not trying to discourage you from writing it.)
Although I have to ask, why do we need a lib for this? It would seem that most users would only have maybe 1 or 2 addons that would interact with the guild bank... (I'm really just asking, not trying to discourage you from writing it.)
I guess it is about having a common communication channel, so several, different bag/bank addons could still display the guild bank.
Although I have to ask, why do we need a lib for this? It would seem that most users would only have maybe 1 or 2 addons that would interact with the guild bank... (I'm really just asking, not trying to discourage you from writing it.)
I guess it is about having a common communication channel, so several, different bag/bank addons could still display the guild bank.
Exactly. The idea is that if three different guildies use three different bank/inventory addons, say TBag, OneBag, and ArkInventory, if the addons used the lib, then no matter which guildie visits the gbank, all three get updated at once.
Why does this ever fire the GuildBankComm_RosterUpdate callback ?
My thought process was that if someone joins the guild, then that callback would fire, and the new member, if they had a compatible bag addon, would automatically get the updated contents of the gbank.
If you look further into the code, and hopefully I did it correctly, when you the player leave a guild, the array with the gbank contents gets wiped to reduce resources and add a bit of security. The security probably isn't necessary, as a player cannot access the gbank of a guild he/she is not a member of, but still.
This means that, when a new player logged in, every lib-using players would send the bank content over the guild channel, whether the newcomer had the library or not. That would be spammy as hell ; imagine 30 people that sent the bank content every time someone logged in.
I would recommend you to attach a timestamp to the data, which would be the last time the data was updated. And then use the following logic to handle sync:
When the player logs in, send "REQUEST" with data timestamp.
When receiving "REQUEST" with a data timestamp:
- if the received timespamp is greater or equal to the local timestamp, ignore the message,
- else start the sync timer,
If the running sync timer ends without being cancelled, send a "SYNC" message with local data and timestamp.
When receiving "SYNC" with data and timestamp:
- if the received timestamp is greater than the local timestamp, update the data and cancel any running sync timer,
- if the local timestamp is greater than the received timestamp, start the sync timer.
I think that to be efficient, the sync timer delay should be a value depending on data age. This way, players having more up-to-date data would respond earlier, preventing other players with older data to send them.
And BTW, when updating data directly from the bank tab, do not send any update message before the player closed the window.
Given that the guildbank API only allows one tab to be scanned at once, I think you will have to handle each tab as a separate piece of data, with its own timestamp.
Don't forget to prevent sync'ing of tabs that others can't see. Unless syncs are done in whisper, any tabs that are not viewable by any ranks shouldn't be sync'd out to the guild.
Don't forget to prevent sync'ing of tabs that others can't see. Unless syncs are done in whisper, any tabs that are not viewable by any ranks shouldn't be sync'd out to the guild.
You will have to explain why syncing to the entire guild in the lib is bad, as I would think not displaying the data would be up to the inventory/bank addon, and not the lib itself.
Speaking of the data, I am using the format
gbContent.guildName.Money
gbContent.guildName.tab[n].item info
Then time stamping gbContent, then firing the Callback and CommSend. The concern is the whole point of the lib is defeated if the data isn't standardized.
I took out the _RosterUpdate() callback, as in the end, it wasn't needed. Should have a new zip for people to look at during the weekend. Added was AceTimer-3.0. BTW, what would be a good suggestion for the sync timer? I was thinking every 10 minutes, or 600 seconds to AT3.
You will have to explain why syncing to the entire guild in the lib is bad, as I would think not displaying the data would be up to the inventory/bank addon, and not the lib itself.
The issue is that your code (and the display addon code) will be readable and modifiable by anyone. So even if the addon do not display hidden tabs, one can easily take out the security check to display the data anyway ; or simply listen to sent data and render them.
So the only effective way to prevent anyone to read forbidden tabs is not to expose them publicly by sending them over the GUILD channel.
I took out the _RosterUpdate() callback, as in the end, it wasn't needed. Should have a new zip for people to look at during the weekend. Added was AceTimer-3.0. BTW, what would be a good suggestion for the sync timer? I was thinking every 10 minutes, or 600 seconds to AT3.
I was thinking of a small timer in reply to REQUEST instead of a long, repeatable timer.
Last but not least, libraries are not addons. You should avoid using other libraries (like AceAddon-3.0, AceTimer-3.0, AceEvent-3.0) in your own library, as library depencencies are quite awkward to handle.
I would not use the Ace3 framework if SendAddonMessage() didn't limit me to strings shorter than the contents of even tab 1 of the guild bank, let alone the whole contents.
Tell you what, since I know I am relatively noobish coder: I'll write the lib, post it here like I did on page one, just updated. If anyone finds better ways to do what I have written, then good, because there is no point in writing a bad lib nobody will use. Much like the LDB thread, the community can hash it out until LibGuildBankComm-1.0 is worthy.
I am just writing this as proof of concept, and personally, I never believed my code would be fully used; I am just not that good of a coder yet.
Newest build, and now I need better coders than I to go through this, improve, edit, and tell me what is missing or broken.
Removed AceTimer-3.0 and changed the callback. Also the comms got some love. I couldn't get the sync timer/update request logic to update from the newest gbContents[guildName].lastScan, and will need help there.
I wonder if I performed some overkill on the callback.
The lib isn't finished, and I still wouldn't consider using it in an addon yet, but there is enough there for people to look at the code and start advising changes, fixes, etc. Lots of changes since the first zips were created.
function lib.frame:CHAT_MSG_ADDON(prefix, msg, distribution, sender)
if prefix ~= "gBankComm" then return end
[B]if sender == "player" then return end[/B]
Replace "player" with pName.
local function commSend(contents, distribution, target)
ChatThrottleLib:SendAddonMessage("gBankComm", contents, distribution, target)
end
With ChatThrottleLib, you need to add a priority to your message in the first variable. Add "BULK" before "gBankComm".
That won't send the bank contents across comm. It'll just send a string "table: XXXXXXXX".
You might need to use AceSerializer-3.0 to convert your table to string. (I'm gonna get grilled for saying that)
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI will do up some docs after the project is finished, approved, .. even created on wowace. Right now it isn't created, because I need feedback. This is my first attempt at writing a library file, and I'm sure I botched something.
Thus far, the two callbacks are GuildBankComm_RosterUpdate(unit, contents) and GuildBankComm_ContentsChanged(unit, contents). The first fires when someone new joins the guild, and the second fires when the contents of the guild bank change, whether money or items.
Do not use this lib with any addons right now! It isn't working, and the _ContentsChanged() callback is missing in places. What I need is people to teach me how to scan tabs for items, adding them to gbContents.numTab.item one, gbContents.numTab.item two, etc, because I couldn't quite figure that part out. If it is not needed to have the tab number, that's fine.
Please poke sticks at this, tell me where I went wrong, what you want to see added (is there any APIs you want?) and generally go over this with the fine tooth comb, please. Xinhuan was mentioning something about the .pkgmeta, which I did not provide, but if there is something special I need to do in the .pkgmeta, then I do not know what it is. I was just going to create a normal .pkgmeta file.
When it is working, any authors using this lib will also need AceAddon-3.0, AceEvent-3.0, and AceComm-3.0 along with LibStub and CallbackHandler-1.0.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAlthough I have to ask, why do we need a lib for this? It would seem that most users would only have maybe 1 or 2 addons that would interact with the guild bank... (I'm really just asking, not trying to discourage you from writing it.)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI guess it is about having a common communication channel, so several, different bag/bank addons could still display the guild bank.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat sounds like something cool.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorExactly. The idea is that if three different guildies use three different bank/inventory addons, say TBag, OneBag, and ArkInventory, if the addons used the lib, then no matter which guildie visits the gbank, all three get updated at once.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorMy thought process was that if someone joins the guild, then that callback would fire, and the new member, if they had a compatible bag addon, would automatically get the updated contents of the gbank.
If you look further into the code, and hopefully I did it correctly, when you the player leave a guild, the array with the gbank contents gets wiped to reduce resources and add a bit of security. The security probably isn't necessary, as a player cannot access the gbank of a guild he/she is not a member of, but still.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI would recommend you to attach a timestamp to the data, which would be the last time the data was updated. And then use the following logic to handle sync:
I think that to be efficient, the sync timer delay should be a value depending on data age. This way, players having more up-to-date data would respond earlier, preventing other players with older data to send them.
And BTW, when updating data directly from the bank tab, do not send any update message before the player closed the window.
Given that the guildbank API only allows one tab to be scanned at once, I think you will have to handle each tab as a separate piece of data, with its own timestamp.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatori've been puttering around with gnomish yellow pages trying to sync guild-wide, but guild-sync is hard as hell to debug by yourself.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorYou will have to explain why syncing to the entire guild in the lib is bad, as I would think not displaying the data would be up to the inventory/bank addon, and not the lib itself.
Speaking of the data, I am using the format
Then time stamping gbContent, then firing the Callback and CommSend. The concern is the whole point of the lib is defeated if the data isn't standardized.
I took out the _RosterUpdate() callback, as in the end, it wasn't needed. Should have a new zip for people to look at during the weekend. Added was AceTimer-3.0. BTW, what would be a good suggestion for the sync timer? I was thinking every 10 minutes, or 600 seconds to AT3.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe issue is that your code (and the display addon code) will be readable and modifiable by anyone. So even if the addon do not display hidden tabs, one can easily take out the security check to display the data anyway ; or simply listen to sent data and render them.
So the only effective way to prevent anyone to read forbidden tabs is not to expose them publicly by sending them over the GUILD channel.
I was thinking of a small timer in reply to REQUEST instead of a long, repeatable timer.
Last but not least, libraries are not addons. You should avoid using other libraries (like AceAddon-3.0, AceTimer-3.0, AceEvent-3.0) in your own library, as library depencencies are quite awkward to handle.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorTell you what, since I know I am relatively noobish coder: I'll write the lib, post it here like I did on page one, just updated. If anyone finds better ways to do what I have written, then good, because there is no point in writing a bad lib nobody will use. Much like the LDB thread, the community can hash it out until LibGuildBankComm-1.0 is worthy.
I am just writing this as proof of concept, and personally, I never believed my code would be fully used; I am just not that good of a coder yet.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorRemoved AceTimer-3.0 and changed the callback. Also the comms got some love. I couldn't get the sync timer/update request logic to update from the newest gbContents[guildName].lastScan, and will need help there.
I wonder if I performed some overkill on the callback.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatorhttp://www.wowace.com/addons/libguildbankcomm-1-0/
Data is now formatted lib.guildBank[guildName].stuff, and the callback was changed. I am trying to simplify the data into a standard that makes sense.
Replace "player" with pName.
local function commSend(contents, distribution, target) ChatThrottleLib:SendAddonMessage("gBankComm", contents, distribution, target) endWith ChatThrottleLib, you need to add a priority to your message in the first variable. Add "BULK" before "gBankComm".
commSend("gBankComm", lib.guildBank, sender) ... local gBankContents = tostring(lib.guildBank) commSend(string.format("gBankComm", "UPDATE %s", gBankContents), "GUILD")That won't send the bank contents across comm. It'll just send a string "table: XXXXXXXX".
You might need to use AceSerializer-3.0 to convert your table to string. (I'm gonna get grilled for saying that)
You should go with itemIDs instead of itemName. It's shorter and I think plays better with GetItemInfo and other such API.Also make local references to the global API. eg
local GetGuildInfo = GetGuildInfo
local IsInGuild = IsInGuild
ect
you'd need to transmit the entire item string (sans "item") it seems to me.
you could certain leave of trailing ":0"s tho, so if there are no gems/enchants and no random suffixes, then a straight itemID would do.