Feature Request: Log usernames of all players, not only those marked as cheaters

[Seercat3160]

If we're already locally logging the seen usernames of players marked as cheaters, why not record all other players too, or at least make it an option? It would make identifying certain players easier, and better allow keeping an eye on suspicious or disruptive players.

If this is already done on the backend, it should be exposed to the frontend for all players. Let me know and I'll make the issue there instead.

[Bash-09]

If a player has any info stored (e.g. a note attached, a custom alias, or a non-Player verdict like Cheater, Trusted, etc), their usernames will be logged when they change already. I personally think this is a preferable default, as logging usernames of all players will store a bunch of information that will likely never be needed and bloat the playerlist, although I don't object to this being added as feature (defaulting to off) if a user actually wants it.

If it's just the ability to track a particular player without the user having to add a note or alias or anything, I think that is more of a frontend concern. e.g. there could be an option to click on a user and start tracking them, and some variable is added to the custom data which will make the backend begin tracking.

[Seercat3160]

I was thinking it more like the first way, and I completely agree with the current behaviour being the default. I think, though, that there should be an option (default disabled) to log names of all players encountered, maybe with a warning in the UI that it will "store a bunch of information that will likely never be needed and bloat the playerlist" as you said. Personally, I would like to have that as I have plenty of disk space and think it's worth it.

[lili7h]

my suggestion was that since we load the whole file into memory when running the app anyway, we could gzip level 9 compress the history file on disk so as to save as much space as possible, since ya know, json isnt very space efficient but usually compresses pretty well
no idea if anyone wants to go for that though

[megascatterbomb]

my suggestion was that since we load the whole file into memory when running the app anyway, we could gzip level 9 compress the history file on disk so as to save as much space as possible, since ya know, json isnt very space efficient but usually compresses pretty well no idea if anyone wants to go for that though

If we compress the entire playerlist we need a method for graceful termination of the client; interrupting the compression half-way would most likely corrupt the user's playerlist.

[DireHydrant]

Is there a specific reason to be using JSON other than the files being human readable? If you're planning on using the web app to view everything, you could switch to a binary serialization/de-serialization since the client is already using serde.

Still, recording all player's usernames would definitely bloat the filesize quite a bit, but it would also allow us to see how often we've queued into games with the same people, which could be fun.

[Bash-09]

@DireHydrant

No specific reason, just that JSON is human-readable and easy for other people to use.

We very well could switch to a binary format for main persistence and provide some way (maybe args when running the program) to convert to/from or otherwise manipulate different formats (MAC-binary, MAC-json, TF2BD, etc).

[DireHydrant]

I definitely see the value in having a human readable file, but I don't think that many users are going to be interacting and editing the files by hand (although maybe there is a case I'm not considering). Either way, there's already an existing JSON import function that takes in a playerlist.json, so adding an arg or a button in the UI to export as a json would definitely work as an alternative.

[Bash-09]

but I don't think that many users are going to be interacting and editing the files by hand

Yeah that's definitely not the common case. It was mainly convenient while still developing stuff but really isn't very important anymore.

I would be perfectly happy for the storage medium to change format. I would just want to make sure that the functionality for converting to/from Json be exposed at the same time so it's still possible for people to make e.g. a python script to scrape data from somewhere to make a playerlist.

[NiXTheDev]

my suggestion was that since we load the whole file into memory when running the app anyway, we could gzip level 9 compress the history file on disk so as to save as much space as possible, since ya know, json isnt very space efficient but usually compresses pretty well no idea if anyone wants to go for that though

If we compress the entire playerlist we need a method for graceful termination of the client; interrupting the compression half-way would most likely corrupt the user's playerlist.

Possible solutions:

1. Put it in another thread?
2. Player list file versioning?

Cons to the solutions:

1. The thread could hang(memory leak?)
2. Hard to manage(?)