Buddy list

[mnieto]

After looking at QOAL's app I realized that a buddy list is a feature most MMORPG support out of the box.

So... is anybody already working on this? If not, I may take the task then.

[Crush]

When you want to do this you should do it for the new client/server combination.

Implementing the ragnarok friendlist protocol or taking the detour over the online list would be quite a waste of time.

[mnieto]

That's right. Besides, I don't know ragnarok protocol.

Here's what I believe one expects a buddy list to do:

• Add/Remove an entry.
• View online status of each entry.

For the first one I can think of two mechanics:

1. Without confirmation
   1. Character "A" initiates addition of character "B".
   2. If "B" doesn't exist, game server sends "A" an error.
   3. Else, game server notifies "A" of success.
   "B" can optionally be notified of a successful addition.
2. With confirmation
   1. Character "A" initiates addition of character "B".
   2. If "B" is not online or doesn't exist, game server sends "A" an error.
   3. Else, game server asks "B" for confirmation and redirects "B"'s answer to "A".
   In this case, should removal be confirmed too? It would make the system quite rigid, so I guess it shouldn't.

Which one is preferred? 1. seems to be more user friendly for "A" but may be not for "B".

[Crush]

I think that a player should give his/her consent when someone adds him/her to his/her buddy list and be able to revoke this consent to avoid abusing the buddy list as a tool for harrasment or surveillance.

For that reason a buddy relation should be two-sided, in my opinion. This means that when A adds B to his/her buddy list and B confirms, A is also added to the buddy list of B. When one of the characters removes the other from his/her buddy list (should not require authorisation, of course), him/herself is also removed from the buddy list of the other person.

[Jaxad0127]

For that reason a buddy relation should be two-sided, in my opinion. This means that when A adds B to his/her buddy list and B confirms, A is also added to the buddy list of B. When one of the characters removes the other from his/her buddy list (should not require authorization, of course), him/herself is also removed from the buddy list of the other person.

I support this method. When B is not online, the server should tell A that and ask B when they are and send A a confirmation (either immediately or later depending on A's online status). If B removes A before A gets the confirmation message, A should get a rejection message instead of both.

[mnieto]

I'm trying to get something out of the method described by Crush. Here is what I have so far. Most of it is still not functional or just thoughts. Only temporary addition is working.

Protocol

These are the packets involved in a buddy list operation. Some of them may need to be reworked. Remove and update are candidates, as a being public id could be meaningless in their usage context.

Code: Select all

    PGMSG_BUDDY_ADD          /*    = ????*/, // W being id
    GPMSG_BUDDY_ADD          /*    = ????*/, // W being id
    PGMSG_BUDDY_REMOVE       /*    = ????*/, // W being id
    GPMSG_BUDDY_REMOVE       /*    = ????*/, // W being id
    PGMSG_BUDDY_RESPONSE     /*    = ????*/, // B error
    GPMSG_BUDDY_RESPONSE     /*    = ????*/, // B error
    GPMSG_BUDDY_UPDATE       /*    = ????*/, // { W being id, B status }*

And these are the error codes for the response.

Code: Select all

    BUDDY_INPROGRESS = 0x40, // another buddy operation already started
    BUDDY_BUSY,              // target character is offline, busy or too far away
    BUDDY_ISBUDDY,           // target is already a buddy
    BUDDY_REJECT,            // operation rejected by target character
    BUDDY_CANCEL             // operation cancelled

ERRMSG_OK is used to signal successful completion.

The packets are used in three ways. The following ascii art should illustrate how they flow.

Addition

Code: Select all

                           _______
       PGMSG_BUDDY_ADD    |       |    GPMSG_BUDDY_ADD
 |----------------------->|       |---------------------->|
#|                        |   GS  |                       |#
 |<-----------------------|       |<----------------------|
     GPMSG_BUDDY_RESPONSE |_______|  PGMSG_BUDDY_RESPONSE

The packets from and to the second character are not sent if it is not ready to be involved in a buddy list operation.

Removal

Code: Select all

                          _______
     PGMSG_BUDDY_REMOVE  |       |  GPMSG_BUDDY_REMOVE
 |---------------------->|       |--------------------->|
#|                       |   GS  |                      |#
 |<----------------------|       |                      |
    GPMSG_BUDDY_RESPONSE |_______| 

Unless the character is not in the buddy list, the operation always succeeds. If the character on the right is online, it is notified of the removal, so the client can remove it from its list.

Update

Code: Select all

                          _______
                         |       |  GPMSG_BUDDY_UPDATE
                         |       |--------------------->|
                         |   GS  |                      |#
                         |       |                      |
                         |_______|

This is used to populate client's buddy list when connecting and keeping it updated as other characters go offline.

Persistence

A single table can be used for storing all the buddy relationships, one per row. Two columns store the ends of the relation. As a result of being two-sided, and to keep the size of the table as small as possible, the order of the columns is not relevant.
In this case, selecting every row with a given id in any column should result in the buddy list for the character assigned to that id.

Notification

Well, there's not much about this. I need to figure out if there exists some implementation other than completely traversing the online users list.

[ElvenProgrammer]

I think that those messages should go through the account server instead of game server. When an account connects it gets notified about his buddy online and the server will also notify his buddies. The same happens on disconnection.

About persistence I think at least another field is required indicating the status of the relation: to be confirmed, to be deleted, refused, ... when the process could not be completed in real time for any reason or just to keep track of answers. Status could also be used to keep track of our blacklist: people refused we want to readd for example.

I agree about having only one row per relation this way we can easily keep track of direction of relation (who started it is always on the left column). But how to keep track of special statuses: i.e. what if I don't want a particular buddy to see when I'm online. I could use the status field but what if also him does the same?

mnieto: Keep up the good work

[mnieto]

I think that those messages should go through the account server instead of game server. When an account connects it gets notified about his buddy online and the server will also notify his buddies. The same happens on disconnection.

Game server is not appropriate ( but I didn't know at first ) because only a subset of the characters may be reachable.
Chat server is better as every client is connected to it, and an update message can be sent to anyone at any time.
As regards account server, I believe a client may disconnect without actually logging out. Then, a notification would be delayed until map server change.
However, I'm not completely sure of connections lifetimes.

About persistence I think at least another field is required indicating the status of the relation: to be confirmed, to be deleted, refused, ... when the process could not be completed in real time for any reason or just to keep track of answers. Status could also be used to keep track of our blacklist: people refused we want to readd for example.

Certainly better than the "please try again" approach.

[....] I could use the status field but what if also him does the same?

It could be shared using a bit field, but it depends on the number of statuses.

Until they are ready for mantis, horrible patches will be here.

[oliver]

Just a very faint idea: how about using Jabber / XMPP (http://www.jabber.org/about/overview.shtml) for in-game chat? TMW client could use a XMPP client library, and the chat server would be an existing Jabber server which loosely connects to the TMW server for status info. Network communication wouldn't necessarily use the existing ports but would run independently of the TMW communication packets.

The advantages that I see:
- all the small details (bugfixes) are already done in the existing Jabber implementations
- we could use existing messengers like Gaim to see who's online in TMW and we could chat with in-game players from a normal messenger
- when Jabber gets a widespread voice chat functionality, we could use that in TMW as well (not sure if that makes sense in an MMORPG, though)
- same goes for all other improvements that might appear for Jabber (like status notification on a website)

[trapdoor]

In the guilds and parties branch there is already support for a guild member list, where you can add and remove users, see whether they are online and have private discussions with them.

This could be expanded for a buddy list, or be used instead of one.

Either way, it should use the chat server and not the account or game servers.

--
trapdoor

[Crush]

I would like to see the guild- and party branch being merged into the trunk version soon because I would like to incorporate the party system into the exp distribution system I am currently programming.

[trapdoor]

I am desperately trying to find time to finish the integration of the guild system. The party system has not yet been started.

--
trapdoor

[mnieto]

In the guilds and parties branch there is already support for a guild member list, where you can add and remove users, see whether they are online and have private discussions with them.

Ok, I'll check that.

This could be expanded for a buddy list, or be used instead of one.

I don't think guilds should replace the buddy list. The later allows you to group arbitrary characters for no particular reason. The former allows you to group character which has something in common. They are actually complemental.

It could be possible to implement a buddy list based on guilds by creating a personal guild for each character. Adding someone to the buddy list would be acomplished by inviting him/her to this guild. And the associated channel could be used to talk to all your buddies.
However, It isn't a clean solution for a character would belong to so many channels. One for each buddy, one for yourself and the ones for real guilds. (I'm thinking about the interface here. It usually has tabs for each channel. But dummy channels could be hidden.)

Looking at defines.h, I guess that status notification is done through this packets:

Code: Select all

    CPMSG_USERJOINED                  = 0x0425, // W channel, S name
    CPMSG_USERLEFT                    = 0x0426, // W channel, S name

is that right? As they need a channel it may be difficult to reuse that for a buddy list. But I have to finish looking at the branch just in case something is reusable. After all, functionality is quite similar.

[Jaxad0127]

Instead of using the similar guild/party functionality, abstract it and use it for all three. The client can have a single window for all three with tabs (or similar) to choose which list you're viewing. Each "buddy" could have different attributes (on buddy list, in guild, and in party) that are show on all lists so you can see information from multiple lists when viewing only one of them.

[Crush]

We could use an abstract CharacterGroup base class that is used for guilds, parties and buddies.

But keep in mind that a character may be in multiple guilds and buddy lists at the same time but only in one party. It would be very convenient for exp calculation and other situations when a character is always in a party. When the character is alone it should be in a party with only itself as a member.

By the way, when talking about game systems and their technical implementation please use the following naming conventions to avoid confusion:

Player: A physical human person sitting in front of a computer playing TMW
Client: Software that connects to the TMW server
Character: Player character in the game