Mod Ideas/Buddy List

Description

Gives the ability to store Buddy's in a list and edit (add/remove from) that list.

Find out what server your buddy is on

(if that data is allowed by buddy)

Option to "Follow" buddy

makes you automatically join whatever server he/she goes to. (if that data is allowed by buddy)

Be Followed

(Option not to be automatically "Followed".)

Option to PM

(private message) buddies.

No PM's

(Option not to accept PM's. (at all))

Ignore list

(accept no PM's from whoever also do not give out current-server-attended-information)

Visible-To list

only allow PM's and current-server-attended-information to those in a list.

Hide-From list

similar to Visible-To list, but allow PM's and current-server-attended-information to anyone who is NOT in the list.)

(Only ONE option, Visible-To OR Hide-From, will be used, by the client at a time. may end up being named Friends list and Shit list hehe.)

(add more features at will, not all will end up in the final.)

Progress

Not started as of 5April04.

(already have some code to build a buddy list from a window via the mod menu item that has a combolist object, an add button, and a remove button. All entries in the combolist object are stored in an ini file and load back up when the window is called up. works great, even ignores duplicates, code available upon request for use in this mod or any other.)

Structure

I've been giving this some thought and have an idea of how it could be accomplished. Consideration has been given to avoid searching all the servers from the MasterServer list and then searching all those servers for a playername. That would take to long and would suck. This structure is proposed to only bombard with the MasterServer with no more than the heartbeat of just one more server.

First of all, the server-side

MasterPlayerServer: This is a ut dedicated server that recieves a heartbeat from all clients running the mod. The heartbeat includes Name, and IP address. The MasterPlayerServer will do only two things; track heartbeats and forward them upon requests. Everything else is done client-side once the client has gotten the ip address of his buddy.

The server itself runs a new gametype and sends a heartbeat to the masterserver in case the MasterPlayerServer (this server)'s ip address stored in the client-side ini file should ever change. Upon not finding the server at that address the client-side mod will query the MasterServer for the server running that new gametype and update the ip address in the ini file.

This server-side mod accepts no joins (could be as simple as a serverpackage set in the server ini file and allow downloads set to false, we don't want anyone to join this server). The new gametype can simply override the login function of GameInfo class to return False, then no one could log in.

Possibly all heartbeats are added to or appended in a dynamic array server-side. The information in that heartbeat (Client's IP address) is forwarded to the client that sent the query looking for that player.

I would consider the priveledge of hosting the MasterPlayerServer to be an honor, and already have a host in mind with unlimitted bandwidth. Upon completion of this mod I will present the opportunity to Ryan @ ShooterSGL.com. If for some reason he declines the offer I can only imagine there are plenty with the facilities to host it, and that they would be happy to. This mod should include in the interface a nice thank you to ie. "ShooterSGL.com for hosting the MasterPlayerServer". See the appeal? This message is stored in the Client-side ini file and should the host ever change, this message would be updated from the Server-side mod to reflect the name of the current host as he would edit that line in the Server-Side ini.

Now, Client-side

Clients running this mod will, upon launching UT, begin sending a heartbeat to the MasterPlayerServer every 60 seconds.

Upon querying the MasterPlayerServer for a certain buddy, the dynamic array is searched for that player's name. If found that player's ip address is forwarded to the searching Client. If not found a confirmation is sent to that effect.

Upon finding a buddy, via matching his Name to that of a heartbeat, a query is sent to the buddy's client requesting the ip address of the server he is playing on. That way the buddy can control who tracks him via an ignore list or possible a visible-to list. PM's can now be sent.

The PM could even reach the buddy when he is on a server in the form a duplicate of the chat area drawn in the lower right of his screen. Or in the form of a "left message" depending on the buddy's set options reguarding incomming PM's.

The hearbeat could even be sent from a subclassed form of dedicated server and could remain active to recieve PM's without even running any other instance of UT. Then PM's would be pop-up windows instead.

I'm thinking that the main interface for this information will be under a new tab on the serverbrowser window. At the mod menu item for this mod you will add and remove buddys to and from a combolist controle that is saved to an ini file upon change. Here you will set you preferences for ignore, visible-to, allow pm's in game, that sort of thing.

Interested Scripters

If you are interested in developing this mod for UT then add your name to the list. Once you start development you should indicate that below (and hopefully include a link to a journal page). Before you start development you should also check this section to see if anyone else has started.

• (name in link form, please specify engine version)
• (name in link form, please specify engine version)

Discussion

Ch3z: Just throwing this idea out there. I have looked into some aspects of it, and so far have not coded any of it. The idea here is mold the structure into a plan before beginning to code it. Any and all usefull input is welcome here. I will come back perodically and factor the discussion into the structure section of this page until the plan becomes defined enough to continue. Don't let that stop you from starting the mod if you already have derived a direction to pull it off. The main goal here is that the mod becomes available.

Discussion other than that below this line has already been refactored into the proposed structure above (as will the discussion below at some point).

Past discussion offered different methodology, but was not supported by any suggestion of implementation. Discussion is still open here for the purpose of defining the structure of this project.