+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 15 of 20

Thread: Chat/addon communications: Features, requests, thoughts, etc.?

  1. #1
    RIFT Community Ambassador the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default Chat/addon communications: Features, requests, thoughts, etc.?

    I know Zorba's working on this, but I figure since we're all sitting around wanting it, we might as well discuss what we'd like or dislike.

    Here's my basic thought: Direct communication is nice, but it would be awesome if data which change rarely could be stashed on the server, because this would reduce bandwidth.

    So my basic concept *.Stash

    Command.Stash.Store(key, value)
    Command.Stash.Request(unit, key, value)
    Event.Stash.Retrieved(unit, key, value)
    Command.Stash.Monitor(unit, key)
    Event.Stash.Monitor(unit, key, value)
    Inspect.Stash.Unit(unit, key)

    These allow storage or retrieval of values up to some size (say, 4k). Stashes are throttled, so are queries. You can have up to some smallish number of stashed values "monitored". If you are monitoring something, it is sent to you (and triggers Event.Stash.Monitor) automatically when it is changed. Inspect.Stash.Unit does not initiate any data transfer, it just tells you the local value if you have one.

    The canonical usage example:

    Command.Stash.Store('RP_Bio', 'Meri Sioux is the most beautiful woman you have ever met, and you fall in love with her instantly...')
    Command.Stash.Monitor('player.target', 'RP_Bio')

    Rationale, such as it is:
    xtensionxtooltip2 was a performance and reliability nightmare. 99% of the people in the game, you will never mouseover. You certainly won't mouseover them often enough to justify every RPer getting an update of every other RPer's bio every 5 minutes or whatever.

    This mechanism isn't really intended for things like, say, combat meters synchronizing between party members; it's intended for stuff that you might want to expose to other people, and which you would set once on login, and never touch again. But it should dramatically reduce the bandwidth costs (especially since, for rarely-changed data, it might be cost-effective to compress the stored copy).

    We presumably also want ways to do addon-to-addon communication by unit, and also by party, guild, raid, etc., but honestly, that problem struck me as relatively well-understood.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  2. #2
    Plane Touched
    Join Date
    Feb 2012
    Posts
    228

    Default

    Why not just:

    - On channel enter or info changed: Broadcast your (new) info to the addon channel.
    - On info received: Update stored info for that sender. If sender wasn't known, either private send your info to the sender or, if there isn't any private send functionality, broadcast your info to the addon channel.

    Not that I don't like the idea of being able to store info in the server (which I'd prefer to be available on Inspect.Item.Detail rather than having to use the Command.Stash.Request you propose), but... What would be the max data size we can store? Is it shared for all addons or each addon has its own space in the server? If shared, it'd be a race condition on which the first addons to load can reserve their space and the others won't be able to register their data. If it's per addon, we'd embed as many modules as we need to bypass the size limitation.

  3. #3
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    What I'd like to see
    1. Throttled sends, but unlimited quantities of sends, just broken into chunks, similar to what WoW's ChatThrottleLib does
    2. Automatic serialization and deserialization, plus automatic dissasembly and reassembly of large data chunks, which WoW's AceComm-3.0 does (AceComm-3.0 uses ChatThrottleLib, which it comes bundled with, to accomplish all this)
    If both of those are wrapped into one Utility command, that would be perfect. There is other functionality both libs provide, which is why I linked to them; better to read for yourselves than me retype everything. While AC3 uses and comes with CTL, you can use CTL by itself in WoW. However, you do not get the unlimited data chunk support that way.


    As a side note, when this functionality gets inevitably incorporated into Rift, however Zorba and co do it, the best and most used functionality would have Rift automatically sync the contents, tabs, coins, etc of the GUILD BANK between all guild members. That is not to say there are plenty of other uses for inter-addon communication; but let's face facts: not everybody will use any given addon that requires inter-addon communication but EVERY guild member would benefit from Rift syncing the guild bank. I wrote LibGuildBankComm for WoW because it was a huge oversight. Hopefully Trion can learn from that blunder.

    Back on topic: beyond what I mentioned, I don't really care much how the events, commands, inspectors, etc handle inter-addon communications, so long as they work.

  4. #4
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Upon thinking again, we do have a way to serialize anything. I don't know what, or if, there is a limit. Point being the addon comm API doesn't need this, as it already exists.

    The rest still stands, but I thought of something else that would be nice: native compression and decompression. Using my guild bank example, although an addon that scans the auction house and updates all users of said addon would also apply, the data involved is fairly hefty. It would be nice to serialize, compress, and transmit, receive, decompress, deserialize. The compression could be optional, possibly a seperate API, but it could also be a default trait, whether you are sending the guild bank, auction house, or the letter "a".

  5. #5
    RIFT Community Ambassador the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Quote Originally Posted by Baanano View Post
    Why not just:

    - On channel enter or info changed: Broadcast your (new) info to the addon channel.
    - On info received: Update stored info for that sender. If sender wasn't known, either private send your info to the sender or, if there isn't any private send functionality, broadcast your info to the addon channel.
    Because that's many many times more data transmitted, and doesn't actually get you data for anyone who was already logged in when you log in.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  6. #6
    Plane Touched
    Join Date
    Feb 2012
    Posts
    228

    Default

    If you broadcast your data when you join the channel, people who were already logged in should get your data, and then spam you with theirs. There have been network discovery protocols working that way for years so it shouldn't be a bad design.

    About Lorandii proposals, it would be great if both compression and large data chunks automatic dissasembly / reassembly were built in the addon communication API.

  7. #7
    RIFT Community Ambassador the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Quote Originally Posted by Baanano View Post
    If you broadcast your data when you join the channel, people who were already logged in should get your data, and then spam you with theirs. There have been network discovery protocols working that way for years so it shouldn't be a bad design.
    It's an awful design for RP addons. Network discovery protocol packets are tiny and usually the network is relatively small, and there isn't a ton of coming-and-going. RP addon data is huge (by comparsion), people are logging in and out constantly, and the number of people you have to deal with is hundreds-to-a-thousand-or-so rather than, say, a few dozen in a typical office.

    It's better than just broadcasting every so often, but the bandwidth of getting all the RP bios at once isn't going to be much fun. (Imagine that half the people had one, and they average 1-2k. A megabyte or two of data all at once on login? Not ideal.)
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  8. #8
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    I don't see it ever happen for Addons to get storage on the server, it just creates more problems that it solves.

    I believe sending data to a preconfigured group of people (i.e. guild, party, raid) wich is redirected by addon identifiers is more than sufficient. Allowing addons to send data to anyone is just bad as long as the server doesn't filter messages to people who don't have the addon installed.

    Anything above that is a luxury, and I'd rather have a working implementation than wait for a big fatty beast. Compression is nice to have, but I consider it a seconday issue. Keep the data small and throttle it yourself.

  9. #9
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    Quote Originally Posted by the_real_seebs View Post
    It's an awful design for RP addons. Network discovery protocol packets are tiny and usually the network is relatively small, and there isn't a ton of coming-and-going. RP addon data is huge (by comparsion), people are logging in and out constantly, and the number of people you have to deal with is hundreds-to-a-thousand-or-so rather than, say, a few dozen in a typical office.

    It's better than just broadcasting every so often, but the bandwidth of getting all the RP bios at once isn't going to be much fun. (Imagine that half the people had one, and they average 1-2k. A megabyte or two of data all at once on login? Not ideal.)
    It isn't that bad actually when you use it for the same purpose: people discovery. Keep it small and tiny. Once you know who is out there you can start sending the real stuff.

  10. #10
    RIFT Community Ambassador the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Quote Originally Posted by Imhothar View Post
    It isn't that bad actually when you use it for the same purpose: people discovery. Keep it small and tiny. Once you know who is out there you can start sending the real stuff.
    Hmm. Interesting thought, but even then, it seems like sending real stuff to people you are never gonna mouseover is expensive. Keep in mind, transmission from one player to another costs twice as much as transmission between either and the server.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  11. #11
    Plane Touched
    Join Date
    Feb 2012
    Posts
    228

    Default

    I was naive enough to believe RPers would write a short note, not a full saga.

    Anyway, I get the point that it wouldn't be a good way to share medium to large amounts of data. I could add some ideas to reduce the bandwidth used, but probably nobody cares about it, so let's go back to the main topic.

    How would you assign server space to an arbitrarily large amount of addons without them competing for that space? What about letting them store only a few short "topic tags" that are sent from the server to your client when the unit is within the visibility range, so those tags are avalaible on the Inspect.Unit.Detail without having to query the server? Then, if you're interested on any of those tags, you could open a communication channel with that player to query further data.

    Again, not that I don't like your idea. Every new API functionality Zorba gifts us with will be welcome.

  12. #12
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    Quote Originally Posted by the_real_seebs View Post
    Hmm. Interesting thought, but even then, it seems like sending real stuff to people you are never gonna mouseover is expensive. Keep in mind, transmission from one player to another costs twice as much as transmission between either and the server.
    Of course it is, that's why I think the system schould not allow generic broadcasts except for guild, party, raid, etc where the number of receipients is known and under control. Addon messages to individuals should be throttled by the server to avoid spam and overuse.

  13. #13
    RIFT Community Ambassador the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Well, even if we ignore the very compelling need for long bios for some characters (the original Merisioux in WoW had a bio which broke some addons; this was part of the joke), there are surely other things where people will want data.

    I'd say stash should be able to fail if there is Too Much Stuff, and there should be a way to query what the stuff is, and which addons stored it.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  14. #14
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Quote Originally Posted by Imhothar View Post
    Compression is nice to have, but I consider it a seconday issue. Keep the data small and throttle it yourself.
    Let's assume Trion does not address the guild bank oversight / blunder, and addon authors have to pick up the slack. How in the world do we keep the data for the entire guild bank small?!? Or keep the auction house synced? Or any other of several ideas that exceed 1 KB of data? No offense, but that observation is ridiculous.

  15. #15
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    Quote Originally Posted by Lorandii View Post
    Let's assume Trion does not address the guild bank oversight / blunder, and addon authors have to pick up the slack. How in the world do we keep the data for the entire guild bank small?!? Or keep the auction house synced? Or any other of several ideas that exceed 1 KB of data? No offense, but that observation is ridiculous.
    First I think the guild bank not syncing is game design related.
    Second, before WoW had a guild bank people created addons which would push the inventory of the "guild bank character" to all guild members and it worked. There is no reason to send hundreds of entries per command. No one will notice if you send 10 items/changes per command. Be creative ;-)

+ Reply to Thread
Page 1 of 2 1 2 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts