PazerOP / tf2_bot_detector

Automatically detects and votekicks cheaters/bots in TF2 casual.
MIT License
403 stars 55 forks source link

Use Steam API to mark friend groups in player list #217

Open Kenajcrap opened 3 years ago

Kenajcrap commented 3 years ago

Using the API call http://api.steampowered.com/ISteamUser/GetFriendList/v0001/?key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&steamid=76561197960435530&relationship=friend it's possible to get a list of friends to search through and find other players in the same match, and label them as a party.

This is useful to help figure out who is most likely preventing a cheater from being kicked or who else to keep an eye on after noticing a cheater.

Here is how I think this could look like in the tool: tf2bd_idea Differently colored "party" icons for each party.

A possible enhancement to this feature would be to represent the "closeness" of the party members (# of friend bonds per # of players in the party) as the alpha value of their icon. Ex.; If there is a party of 5 players, but one of them is only friends with 2 others, the alpha value of his "party" icon would be 40%.

Something else that may be implemented but is more controversial is automatically marking a player's friends that are present in the match as suspect when said player is marked as a cheater. Maybe add this as a setting? Off by default?

Edit: I forgot to add that, of course, this only works if the player's profile has friends list set to public. However, while the cheater himself may not have a public friends list, the cheater friends are more likely to, making chains/groups of friends still likely to form. even though not every member has a public friends list. thanks @ClusterConsultant

ClusterConsultant commented 3 years ago

This would only work if the friends list of the target profile is public. Relevant docs here

Kenajcrap commented 3 years ago

@ClusterConsultant Was this added to the right milestone? I think it would fit better under 1.7 or 1.3. But maybe its just a question of it not being a very high priority compared to the stuff slated for those versions.

ClusterConsultant commented 3 years ago

Tag update is semi feature frozen and this is less ui and more logic. I picked 1.6 since that will likely include other detection changes. If @PazerOP wants to throw it into 1.3, I have no objections. There is also the matter of trying to keep 1.3 a reasonable amount of time away