does just announcing you've changed things really help?
The previous example was to whisper everyone online regardless if they were running the lib or not. Announcing that you have changes would interest only those running the lib to request the changes.
it seems to me you should trust your system to be functional and then just broadcast changes (slot#1 is now empty, slot#5 now contains 6x[item], slot #15 now has 15 in the stack, etc)
Wouldn't that have the same issue has my example except with a much shorter message?
Keep in mind we can't broadcast the slot item/count over guild comm because people without rank could see it.
I agree a slot has changed method is better then a whole tab has changed. If I were writing this lib, I'd want to keep comm traffic as small as possible. With full syncs at login of course.
You can't broadcast only changes. I've tried this method and it does not work. People never have the same base, which means you can't apply a change set uniformly. In order to ensure valid data the entire tab needs to be serialized and sent to users.
If the user does a full sync at login. Shouldn't everyone have the same base when a slot change is broadcast?
The previous example was to whisper everyone online regardless if they were running the lib or not. Announcing that you have changes would interest only those running the lib to request the changes.
Wouldn't that have the same issue has my example except with a much shorter message?
Keep in mind we can't broadcast the slot item/count over guild comm because people without rank could see it.
eh, i would just leave it to the client to ignore the stuff you're not supposed to see. i mean, it's not like the data is really secure. if somebody writes a mod that ignores rank, you're not going to be able to stop them. whispering changes to multiple people seems burdensome, tho i suppose if you're at the gb you're not really in a time-critical situation.
something to consider with all of this is the possibility that somebody logs into an alt, runs to the gb, deposits a few stacks of something, then logs out immediately. the longer it takes to dispatch this information, the more likely you'll have problems.
i would think a single broadcast ensures that everybody is on the same page. logging out or dc'ing in the middle of a series of whispers would be bad.
Weird. OK, loaded this lib into live and Beta. no errors on either. Mind, the Beta didn't even load it. LibGuildBankComm-1.0 didn't even show up on the addons list. Live loads it, but doesn't print any of the debug messages.
This was with r10 which I modified quite a bit since my last post, and then I modified slightly again, trying to get some debug messages to print. No dice. Anyway, the biggest changes were in checking both the player and fellow guild mates rank so the comm wouldn't send pages to people who aren't allowed to see them; in the player's part, pages that can't been seen aren't even requested.
This code is completely different from what I posted earlier.
it's not like the data is really secure. if somebody writes a mod that ignores rank, you're not going to be able to stop them.
That's why I'd choose to use whispers. If the sender first checks if the receiver has rank, then having a modded addon isn't going to help the receiver. The sender's still going to see they don't have rank and will ignore their request.
Maybe I'm just being paranoid. I do see the benefit of sending 1 broadcast to guild chat for everyone to receive it at once. Then use the honor system to prevent people from seeing tabs they're aren't ranked to see.
I am all for sending one broadcast, but I couldn't make it send to appropriate people using "GUILD" so I check the rank of all members who are online and whisper them.
Also, I put in a check for the player, insofar checking his or her rank for the "REQUEST" ... mind, if someone wants to poke at the code, I don't have an issue with that, which is why I am making this public domain with an open repository. My previous message has both an attached zip and a link to a paste which I did up after the r10 commit.
Alright, while still in Alpha build, I am taking this out of Experimental status. For those willing, if you want to use LibGuildBankComm-1.0 in your addons, please create a fork for testing purposes, then let me know good or bad.
Good point, and updated. I suppose a better idea would be just send lib.guildBank[guildName] rather than lib.guildBank.
For that matter, is there a difference between lib.guildBank[guildName] and lib.guildBank.guildName?
yes, there's a difference.
lib.guildBank["guildName"] is equivalent to lib.guildBank.guildName (note the quotes). if guildName is a variable, then you can't use it in dot notation.
i'm confused. why index this by guildName at all? you should only ever have one guild for a toon, right?
i would also only describe what is exposed to the user.
the bankData field in the callback is presumably a table of the data. that's really the only thing the lib user needs to know about in terms of data format.
bankData.numTabs = number of pages in the guild bank
bankData.guildFunds = cash in guild bank
bankData[page].links = table of item links indexed by slot number
bankData[page].stacks = table of item stack sizes indexed by slot number
not sure i'd mention the lastScan and hasData fields.
i'm guessing the unit field in the callback is who sent the message? guildName seems superfluous since you already know your guild name.
i'm confused. why index this by guildName at all? you should only ever have one guild for a toon, right?
...
guildName seems superfluous since you already know your guild name.
The code for the data storage/page scanning in the lib was based on my addon MobileVault which keeps track of multiple guild banks since a player can have toons in multiple guilds. I'm guessing it is just an artifact of that.
It might be superfluous, but it probably makes retrieving data for addons like Mobile Vault a little easier. If the lib specifies what the guild name is, then you know exactly which data stream you are dealing with on MV's end.
Incidentally, I just put up r12 which fixes some typos, and only sends "lib.guildBank[guildName]" rather than the whole of "lib.guildBank" over the comm, mainly to not send the player's rank and other probably useless information.
Hate to do this, really, but I think I'm throwing in the towel on this. There is just so much I can't figure out why it isn't working, even with cross-referencing APIs and Events, asking for help in the coding help forums. I really appreciate all the help everybody has given me to get as far as where I am.
If anyone wants to take over LibGuildBankComm-1.0 and finish it, be my guest. It is nearly done, but I give, sorry.
Thought I'd zip up all the files, just in case. I still think this is a worthwhile lib, given all the addons that take snapshots of the guild bank and then don't sync with each other.
Not that it would be feasible to write a new addon or even modify an existing one in a very short time, but I think LibGuildBankComm-1.0 is release candidate at r16. I won't push a beta until some experimentation with the lib in use is done.
Keep me posted if you try it out and something isn't working. As a side note, I didn't localize a lot of global functions (tostring, tonumber, etc) because I wasn't sure if that was a good idea in a lib, but that is easily remedied.
You don't need LibGuildBankComm-1.0 to extend the bank log; there are APIs to get the log as far back as Blizzard shows. After that, create an addon whose SVs append the log.
The problem is if there were more transactions between your visits than your local log knows about, so sending the log as a comm might work, but you face two major problems with that. First, getting your code into addons people would use, and second, getting most people in your guild to use a guild bank addon (a problem not even this lib will fix).
Essentially, LGBC doesn't solve your problem, and even writing up an addon to save the log, you would have to be on top of the log yourself.
And thank you again! Since you are testing LGBC-1 in Mobile Vault, is it safe for me to tag a beta or release, or are you still having the odd issue here and there?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
The previous example was to whisper everyone online regardless if they were running the lib or not. Announcing that you have changes would interest only those running the lib to request the changes.
Wouldn't that have the same issue has my example except with a much shorter message?
Keep in mind we can't broadcast the slot item/count over guild comm because people without rank could see it.
I agree a slot has changed method is better then a whole tab has changed. If I were writing this lib, I'd want to keep comm traffic as small as possible. With full syncs at login of course.
If the user does a full sync at login. Shouldn't everyone have the same base when a slot change is broadcast?
eh, i would just leave it to the client to ignore the stuff you're not supposed to see. i mean, it's not like the data is really secure. if somebody writes a mod that ignores rank, you're not going to be able to stop them. whispering changes to multiple people seems burdensome, tho i suppose if you're at the gb you're not really in a time-critical situation.
something to consider with all of this is the possibility that somebody logs into an alt, runs to the gb, deposits a few stacks of something, then logs out immediately. the longer it takes to dispatch this information, the more likely you'll have problems.
i would think a single broadcast ensures that everybody is on the same page. logging out or dc'ing in the middle of a series of whispers would be bad.
This was with r10 which I modified quite a bit since my last post, and then I modified slightly again, trying to get some debug messages to print. No dice. Anyway, the biggest changes were in checking both the player and fellow guild mates rank so the comm wouldn't send pages to people who aren't allowed to see them; in the player's part, pages that can't been seen aren't even requested.
This code is completely different from what I posted earlier.
That's why I'd choose to use whispers. If the sender first checks if the receiver has rank, then having a modded addon isn't going to help the receiver. The sender's still going to see they don't have rank and will ignore their request.
Maybe I'm just being paranoid. I do see the benefit of sending 1 broadcast to guild chat for everyone to receive it at once. Then use the honor system to prevent people from seeing tabs they're aren't ranked to see.
Also, I put in a check for the player, insofar checking his or her rank for the "REQUEST" ... mind, if someone wants to poke at the code, I don't have an issue with that, which is why I am making this public domain with an open repository. My previous message has both an attached zip and a link to a paste which I did up after the r10 commit.
API page.
Good point, and updated. I suppose a better idea would be just send lib.guildBank[guildName] rather than lib.guildBank.
For that matter, is there a difference between lib.guildBank[guildName] and lib.guildBank.guildName?
yes, there's a difference.
lib.guildBank["guildName"] is equivalent to lib.guildBank.guildName (note the quotes). if guildName is a variable, then you can't use it in dot notation.
i would also only describe what is exposed to the user.
the bankData field in the callback is presumably a table of the data. that's really the only thing the lib user needs to know about in terms of data format.
not sure i'd mention the lastScan and hasData fields.
i'm guessing the unit field in the callback is who sent the message? guildName seems superfluous since you already know your guild name.
The code for the data storage/page scanning in the lib was based on my addon MobileVault which keeps track of multiple guild banks since a player can have toons in multiple guilds. I'm guessing it is just an artifact of that.
Incidentally, I just put up r12 which fixes some typos, and only sends "lib.guildBank[guildName]" rather than the whole of "lib.guildBank" over the comm, mainly to not send the player's rank and other probably useless information.
Plus, I adjusted the API page.
If anyone wants to take over LibGuildBankComm-1.0 and finish it, be my guest. It is nearly done, but I give, sorry.
The project is SVN, with Revision control keyword. http://www.wowace.com/addons/libguildbankcomm-1-0/
Keep me posted if you try it out and something isn't working. As a side note, I didn't localize a lot of global functions (tostring, tonumber, etc) because I wasn't sure if that was a good idea in a lib, but that is easily remedied.
The problem is if there were more transactions between your visits than your local log knows about, so sending the log as a comm might work, but you face two major problems with that. First, getting your code into addons people would use, and second, getting most people in your guild to use a guild bank addon (a problem not even this lib will fix).
Essentially, LGBC doesn't solve your problem, and even writing up an addon to save the log, you would have to be on top of the log yourself.
And thank you again! Since you are testing LGBC-1 in Mobile Vault, is it safe for me to tag a beta or release, or are you still having the odd issue here and there?