Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Player Schema V4 Changes Proposal #69

Open
leighmacdonald opened this issue Apr 23, 2024 · 0 comments
Open

Player Schema V4 Changes Proposal #69

leighmacdonald opened this issue Apr 23, 2024 · 0 comments

Comments

@leighmacdonald
Copy link
Owner

The current TF2BD player schema (v3) limits how much we can really store about a player.

These are some current thoughts about updates that could be made to the schema.

  • players[].attributes[]: It currently only defines: cheater/suspicious/exploiter/racist. I think this should be extended to include arbitrary options defined by the user. For example, the current list does not distinguish between regular cheaters and bots. I do think there is value in keeping a minimum base set of attributes though and including at least bot within that set.

  • players[].name or players[].label: This can be used to label a user with a custom value so its easier to track users who are changing their names.

  • players[].note: Add a field where people can expand on the reasoning for the addition. Or otherwise just document them with whatever they want.

  • players[].count_seen How many times you have seen that player.

  • players[].last_seen.region Add a region that the user was seen in. This could be taken either from the casual server names, or possibly sv_region value but i think that's not directly query able on the the player and just returns -1.

The last 2 items could potentially be merged and the players[].last_seen struct could be turned into an array players[].last_seen[] and then have its children counted. This would balloon the file size somewhat however.

The following items could probably be placed in their own schema, but maybe there is value in including it in here as well, not 100% convinced though.

  • players[].N.action[] Define what actions to take when you see this player. For example kick/notify_lobby/notify_team/notify_all/none. This might make more sense to be placed in a separate local file that is not necessarily designed to be shared.

  • attributes[].action Similar to the previous action: kick/notify_lobby/notify_team/notify_all/none, but instead will defined defaults for the attributes globally. The players attribute under players[].action[] if defined should override the global action.

  • players[].whitelist if this is set to true, override any lists actions, ignoring any actions defined in either your own or 3rd party lists. If set to notify, do not perform any actions other than lobby notifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant