The use case is:

1. Player A uses the 'friend add' command to add Player B as a friend.
2. Player C, with the same (or similar) name as Player B, joins the server.
3. Player A uses the 'friend add' command to add Player C as a friend.
4. Player A uses the 'friend remove' command to remove Player C, by name, but Player B is removed.

A bit more than just adding their ID there. :P

I wouldn't use a new line over a comma, as a new line may not work across all games and could make the message quite lengthy if a player has a lot of friends. I'm not sure why you have the data handling moved outside of the switch as well, being as it still gets the data again for the add command and it isn't used outside of the switch.

The main purpuse is just to let the user know the ID of the friend, so they can remove the right one; you can replace the newlines with commas if you like.

I don't recall moving the data handling out. Pretty sure it's just the variable declaration, since it's used in two of the switch cases.

Right, but the declaration being moved doesn't change how it works still being as only one case would be called per use, just adds another line of code really.

Also, would it make it more useful to have GetFriendList return the info needed rather than creating a separate list for the command?

I had considered modifying that function, but opted out of it because it is published in the docs as an API call. I figured that other plugins may rely on the existing behavior and that a combined name and ID may break existing functionality.

Another approch that I considered was another API call named GetFriendListWithId or similar.

Plugins that I have written normally consume the result of GetFriends, and I use other means to get the player names, if those are needed. I can't speak for what other plugin writers are doing with the API. The ID in the friends list seems like a feature that pertains mainly to the Friends command output.

Merged post

I see also another possibility. In the TODO list is the separation of commands, and this thread is really about what happens when a user tries to 'remove' an entry with an ambiguous name.

The 'list' command can remain unchanged, if the 'remove' command doesn't stop at the first match in the list. With a single match, the player is removed from the list. When multiple matches are encountered, the 'remove' command can instead output a list of matches with IDs.

I'm not sure if I'll separate the commands or not. It really depends on what happens when I do the rewrite for uMod and the handling of sub commands with it. Multiple matches should be handled better in this, so that's probably the better option rather than assuming.

I agree. Disregard the earlier patch submission. I will look at the behavior of the FindFriend method.

Merged post

I submitted another patch (3.1.3-patch_69360) for consideration. It alters the behavior of FindFriend to return a list, and alters the 'remove' command to report multiple matches and to act only on exact match. Disregard patch numbers 66150 and 81263.