Closed Zoombara closed 2 years ago
We would want to lock this down to only those users who can edit guild information tab. But I'm not sure the officers want to see compressed text in the guild info. @mesato will have to comment on that. I'll look at the deflate because that would be huge saving on the bnet side!! This would be absolutely huge to get working, the compression rates are significantly better with deflate. The more compress, the less data needs to be transmitted, which means the less messages. I've been concerned over "too much" data because Blizz will DC a user if it deems it sending too much data via addon eye roll
you were right on the deflate for print thing :)
The idea behind this page was that the finished product would describe the fields needed by an XFaction config at the top and be preloaded with a dummy example similar as seen. For the compress buttons (pardon the current names) a description below them would state something like 'XFaction supports both native and compressed formats in the Guild Information section.' Ideally this was to allow moving teams info out of code, but the page wasn't intended to actually modify the Guild Information directly.
Glad it worked!
I'm kind of wanting to leave the confederate name, what guilds are included, the channel and password in the guild info. that way the officers have control of such things and someone outside the guild cannot start listening in. it also allows them to make a change and everyone gets it without asking hundreds to update their configs (which wont happen). its been hard enough just to get everyone to upgrade to 3.X line.. we do have a request to make teams configurable from another guild, so looking to include your changes. is it possible to store the native/compressed in the guild information if they have the ability to modify guild information? the nice thing about the compression is that it would theoretically make it harder for people to know the channel password. it wont be encrypted but at least it wont be plain text
I might be confused, but I took this proposal initially as just having a builder in the addon that could then output a string that would be posted in the guild info. Benefits being that we're limited by characters currently and an encoded string would allow us to shove more configuration data in the limited space. Not that any configuration would be read or stored in the addon itself for individual users.
you're correct, i was just making a few mind jumps and not bringing the audience along (i tend to do that). if we're going to provide an interface style configuration, then we can get away from the XFg or XFc style, thats just for engine parsing. as a user you should be able to select Stormrage or Proudmoore. also its not a leap to have it auto upload to guild info if the user has permissions, saving a copy/paste. but since on a timeline, you're right in that this can probably just get pulled in as-is and work on a more long term, user friendly version later
Hey sorry I didnt reply as I was out for a few days. yeah this was pretty much what @waggz81 mentioned. If I get some time Ill see what it can do as far as saving to guild info.
Included PR in 3.4.0 alpha build
Implemented in 3.4
Hey Chalsean, I put this together as a prototype to see if its worth integrating. Its an XF config builder. I had noticed some of your comments in constants about remaining EK settings (teams), plus the recent commits around compression and it gave me the idea that you could compress the settings and store in the guild info! So I thought I would put another prototype together and test a bit.
Here are my results: Current config: total characters 290
Compressed: total characters 190
With a larger config like this: total characters 601
Compressed: total characters 394
I modified the TimerEvent to look for the new config first and load if its there, otherwise old method fallback.
Here is the UI side:
Related PR https://github.com/Chalsean/XFaction/pull/203
Of Note: I saw the comments about the deflate not playing nice. I had issues with the raw compress having non-standard characters and it wouldn't save correctly, running with the encode/decodeforprint functions made all the difference. Not sure if something like below would work for the messages.