Buddy list
Forum rules
This forum houses many years of development, tracing back to some of the earliest posts that exist on the board.
Its current use is for the continued development of the server and game it has always served: TMW Classic.
Buddy list
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.
So... is anybody already working on this? If not, I may take the task then.
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.
Implementing the ragnarok friendlist protocol or taking the detour over the online list would be quite a waste of time.
- former Manasource Programmer
- former TMW Pixel artist
- NOT a game master
Please do not send me any inquiries regarding player accounts on TMW.
You might have heard a certain rumor about me. This rumor is completely false. You might also have heard the other rumor about me. This rumor is 100% accurate.
That's right. Besides, I don't know ragnarok protocol.
Here's what I believe one expects a buddy list to do:
Here's what I believe one expects a buddy list to do:
- Add/Remove an entry.
- View online status of each entry.
- Without confirmation
- Character "A" initiates addition of character "B".
- If "B" doesn't exist, game server sends "A" an error.
- Else, game server notifies "A" of success.
- With confirmation
- Character "A" initiates addition of character "B".
- If "B" is not online or doesn't exist, game server sends "A" an error.
- Else, game server asks "B" for confirmation and redirects "B"'s answer to "A".
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.
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.
- former Manasource Programmer
- former TMW Pixel artist
- NOT a game master
Please do not send me any inquiries regarding player accounts on TMW.
You might have heard a certain rumor about me. This rumor is completely false. You might also have heard the other rumor about me. This rumor is 100% accurate.
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.Crush wrote: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'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.
And these are the error codes for the response.
The packets are used in three ways. The following ascii art should illustrate how they flow.
Addition
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
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
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.
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 }*
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.
Addition
Code: Select all
_______
PGMSG_BUDDY_ADD | | GPMSG_BUDDY_ADD
|----------------------->| |---------------------->|
#| | GS | |#
|<-----------------------| |<----------------------|
GPMSG_BUDDY_RESPONSE |_______| PGMSG_BUDDY_RESPONSE
Removal
Code: Select all
_______
PGMSG_BUDDY_REMOVE | | GPMSG_BUDDY_REMOVE
|---------------------->| |--------------------->|
#| | GS | |#
|<----------------------| | |
GPMSG_BUDDY_RESPONSE |_______|
Update
Code: Select all
_______
| | GPMSG_BUDDY_UPDATE
| |--------------------->|
| GS | |#
| | |
|_______|
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
- Founder
- Posts: 2526
- Joined: 13 Apr 2004, 19:11
- Location: Italy
- Contact:
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
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
Game server is not appropriate ( but I didn't know at first ) because only a subset of the characters may be reachable.ElvenProgrammer wrote: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.
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.
Certainly better than the "please try again" approach.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.
It could be shared using a bit field, but it depends on the number of statuses.[....] I could use the status field but what if also him does the same?
Until they are ready for mantis, horrible patches will be here.
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)
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)
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
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
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.
- former Manasource Programmer
- former TMW Pixel artist
- NOT a game master
Please do not send me any inquiries regarding player accounts on TMW.
You might have heard a certain rumor about me. This rumor is completely false. You might also have heard the other rumor about me. This rumor is 100% accurate.
Ok, I'll check that.trapdoor wrote: 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.
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.This could be expanded for a buddy list, or be used instead of one.
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
Last edited by mnieto on 22 Jan 2008, 23:14, edited 1 time in total.
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.
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
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
- former Manasource Programmer
- former TMW Pixel artist
- NOT a game master
Please do not send me any inquiries regarding player accounts on TMW.
You might have heard a certain rumor about me. This rumor is completely false. You might also have heard the other rumor about me. This rumor is 100% accurate.