PlaneShift

doesn't the guild window already provide it?

Of course, the guild window already provides that. But would you want to keep the big fat guild window open all day long? The buddy list instead is nicely narrow and doesn't hurt much at the border of the application window.

The disadvantage of a strict separation between guild members and buddies is: Currently you can only manually add guild members to the buddy list, one after another… And you would have to manually remove those who left the guild (if you don't want to keep them as buddy anymore).

My main point is the automation. A useful side effect, although rather marginal, may be a reduction of the size of the buddy table, which would then only need to contain buddies who are not guild members already.

And if you don't want it, keep this option disabled, and everything stays like in good old times.

but also if you do automagically move your guild members to the buddy list it defeats part of the purpose of having them automatically show if on/off in guild chat. part of the reason was to decrease the size of buddy lists stored in the db and save some network traffic. also if you do this you have to have a way to automatically remove the guild members if you leave the guild, which would be hard especially if the toggle to turn such feature on would be in the guild info window.

well if it was to be done it should be integrated when sending the list from the server which can be done on "runtime"

According to the replies to  FS#2297  you already implemented getting a notification when guild members join or leave. That means, (temporarily) displaying them in the Buddy List between other active buddies (or removing them there) requires no additional server calculation, at most a little for the client (in addition to printing a message in a channel). The additional initialising "list of present guild mates" on joining will usually be smaller than the "list of both present and absent buddies" by far, and therefore result in only little network overhead, and only once (while loading the game); the further changes are diffs.

Of course, those who once added guild members to their buddy lists, may have to remove them as buddies (manually?), when the "Show guild mates in buddy list" feature would be implemented, to avoid double entries. But just that would shrink the DB buddy table.

Making new because it's a feature request anyway :)

I would vote against automatic inclusion of guildmembers in the buddy-window (at the very least it should be optional). And these are the reasons I do not like that idea at all:

* Imagine being in a guild with several dozen or more members. It is highly unlikely that you know everybody in person then and I would not want to have anybody on my budy-list I only barely know, if at all.

* There is always the problem of synchronizing the buddy- with the guild-list. It would have to be checked that no members are in the buddy-list twice. The problem gets worse if one has changed a buddies name after adding him/her to the list. The routine to add would have to make sure that the changed name is kept and not replaced by the "standard" name.

* another question is: what happens if one leaves a guild? Imagine one has added people before manually which are guild-members, too. Should all those be removed? Definitely not. Leaving a guild doesn't automatically mean that one does not want to have some of the people in there on his/her buddy-list.

All in all, I would find it highly annoying if the game would mess around with my buddy-lis. The purpose of the buddy-list is *not* to show guildmembers, imho, but people I consider as buddies.

In reply to Mrokii's concerns, I'd suggest this approach:

* Continue to have a manual buddy list in the database

* [edit] Base the buddy list on player IDs. [Oops, PS#2587 indicates that the buddy list is based on something else than player IDs; this change would be useful for fixing PS#2587, too. Any list of players should really be based on player IDs IMHO, not on secondary attributes…]

* When the client displays the buddy list, it merges that with the list of online guild members. Eliminating duplicates from a list based on player IDs is really simple: sort the lists to be merged by player ID, process them in order, then sort the combined list by display buddy name for display.
I agree that automatic buddies should be distinguishable from manual ones. (Light green vs. dark green, or an indicator letter/icon, or whatever.)

* When opening an edit window for a buddy who is also a guild member, add a checkbox that says "This is a permanent buddy", indicating membership in the manual buddy list stored in the database, keeping the buddy in the list even if s/he or the player leaves the guild.

* The /buddy command would be unaffected, as it only affects manual buddying. However, a general command for activating and deactivating the option to display guild members as buddies would be useful.

On a tangent, I'm thinking about ways to add other kinds of player groups to the buddy list. Such as

/buddy *guild

to have all guild members in the buddy list, and

/buddy *guild off

to remove them (except those that are in the buddy list for other reasons).

Or

/buddy *guild Warrior

to have all members of all guilds that have "Warrior" in their name (similar to /who).

And

/buddy *group

to automatically add members of the group the player is in, and automatically remove them as the player leaves the group.

Can all be done by merging group lists; the list of manually added buddies would then be just one of several lists to be merged to populate the buddy window.
(Of course, distinguishing the various groups of buddies by color would become more difficult, so it would probably have to be an icon or indicator letter.)

2)absolutely not pids shouldn't be sent to players at all the guild listing (which is essentially the same thing) sends pids and it's wrong. Players should only receive names, ids shoulnd't get out of the server (admin commands excludes)
3) it's work on the server with big guilds the thing could be noticeable
4) the edit window doesn't allow this right now. it's a generic one and it has just a text box
6) the place should be the guild information window. in the place where you get the same exact list. and definitely not for other guilds

the problem with this is the slim use and quite substancial cpu load on the server to update lists (including sending of data. maybe some guilds are slim but others are on the 100-200 members)

Re 2: What's the problem with pids on the client side?

Re 3: Not really. Guild lists are already being sent whenever somebody updates the Members tab in the Guild window.

Re 4: Use a non-generic window then. Generic code is useful only when things don't vary, in this case they do (well, should).
(I agree that this aspect may make postponing the whole thing more likely.)

Re 6 "the place should be the guild information window": This has already been answered, the buddy list is far less obtrusive to keep open. And even with the "xyz just joined PS" messages, it can be useful to have guild members on the buddy list anyway. (My buddy list has 50 extra members just because I find it useful. You may find that useless, but that's just the way I like it configured.)

Re 6 "definitely not for other guilds": The information as such is available, just do a /who <guildname>. In fact I added enemy guild members to my buddy list during a war, to keep an eye on them (our opposition doubtlessly did the same).
The one difference is that the offline members aren't known, and while I'm undecided whether that's important or not, I agree they shouldn't be listed unless there's a specific reason to. However, for those people added to the buddy list through some other list, it doesn't make much sense to display them in red anyway: you added the *list*, not the members, and this would keep the red portion of the buddy list short, too (just the individually added players).

Re "the problem with this is the slim use": Please substantiate. E.g. take a look at the database and check how many players have added a substantial portion of their guild members to their buddy lists.

Re "quite substancial cpu load on the server to update lists": I'm not sure I follow.
Would the load be more than the following?
* During start-up (or when opening the buddy list), a single SQL query to find all the members of the subscribed guilds, trimmed down to those online or from the manual list. Few people will crowd their buddy list with more than they can see at once, so the list shouldn't cover more than 50 names online plus a handful manually-added offline ones, so let's say 100 players with an average name length of 20, meaning 2000 bytes plus overhead to send.
* Whenever somebody goes online or offline, another query to find those who need to get notified. (This is already present actually.)

I don't see that this is creating a noticeable extra load on the server.
The only thing that *could* impact the server is the extra join needed on the database queries to pull in multiple lists. It *should* be unnoticeable if the proper indexes are in place, but checking doesn't hurt.
Do an "explain plan" to check whether it's using the indexes that it should, check how much longer the new query takes, *then* decide whether it incurs a load problem :)

2) because pids are supposed to stay only on the server and be private quite simple. when i get the chance i will epurate them from the guild listing as they are not used yet they are sent. clients are supposed to know only EIDs AFAIK 3) i was talking of server cpu/ram load not of bandwidth which is going to not really change much
6) so we add additional checkings about private guilds…

— fortunately it isn't query based else i would say forget it. things are loaded in ram yes but i need to iterate the entire guild listing each time someone logs in logs out to update your buddy list this isn't something slim to do it means executing a loop from 10 to 200 times depending on the guild size. then for each i must repopulate your buddy list and the same thing goes each time you open your buddy list or modify it in either way.

and sql hit in the server are bad (we can kick everyone out by just listing some info from the webconsole…) fortunately this isn't the case

and there is difference from that one as that one does only one iteration when someone logins logsout while with the buddy list i do continuous iteration each time you request your buddy… and trust me it happens a lot

and if i add other guild checking or even wildcard checking i must iterate the entire server players each time someone opens a buddy list or logins or logouts

Yeah, can't you just use your techity skills to make the names that show on the Member Tab in the Guild Window appear simultaneously at the buddy list? (Without keeping the name in the list if the member goes offline and wasn't added and making the name yellow or something.)

This wouldn't be bad to see around, specially for mass recruiting guilds.

The idea is not to include all guild members into the buddy list, but to show an icon next to the buddy to know he is also a guild member.