Skip to content

RFC: Logging and persisting game chat through client quits #270

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

Open
allejo opened this issue Dec 25, 2020 · 6 comments
Open

RFC: Logging and persisting game chat through client quits #270

allejo opened this issue Dec 25, 2020 · 6 comments

Comments

@allejo
Copy link
Member

allejo commented Dec 25, 2020

This feature request was brought up on Discord by samson1. The BZFlag client has the -e flag, which allows us to forward messages in the client console to the command line allowing players to store copies of their logs via > or >>.

bzflag -e >> /path/to/logs.txt

There are a few feature requests in this idea:

  1. Add an option to the configuration file that will allow players to specify a directory and have logs written to these folders automatically (without needing to use the -e flag manually)
  2. Read from these logs at client startup and load in N amount messages (configurable via the configuration file) from these logs into the console so players can see messages from their last session
@allejo allejo added this to the 2.4.22 milestone Dec 25, 2020
@allejo
Copy link
Member Author

allejo commented Dec 25, 2020

My thoughts:

  1. I like the idea and it's something we could do. My only concern would be: do we just infinitely continue writing new log files every day like we do with screenshots? Are there any concerns about writing too much data?
  2. I personally don't see the need for reading in older messages. I personally wouldn't open my client to scroll up in the console to see logs, I'd just open the .txt logs manually.

@jwmelto
Copy link
Member

jwmelto commented Dec 26, 2020

That’s about what I was thinking

@kongr45gpen
Copy link
Member

I don't think I've seen many online games keeping chat history (perhaps command history would actually be more important). While this feature would be very useful for admins, I don't see much need for typical players to have the previous messages in the logs.

However, maybe storing (but not reading) such logs to a file by default would be useful, for those users who want to go back to a specific conversation or event.

Also, while the data volume from chat should be small enough, it makes sense to use at least some large limit as a sanity check and to avoid log files getting over 100 MB long 😛 (Maybe giving some insight to the user that hey this file is limited so they don't lose 10-year-old conversations)

@blast007
Copy link
Member

I don't think it should default to on, but an option to enable it would be fine. My thought would be to open a new file each time the client launches (or when the option is toggled on), named based on the current date/time. That way multiple clients running are unlikely to clobber their own files, though we could also add a check to make sure the file doesn't already exist.

I don't think we need to put any limits on sizes. Text doesn't take up that much space. For context, my IRC chat log for the main BZFlag channel is only 95MB, and that goes all the way back to 2006 and has 1.3 million lines.

As for loading previous chat, I'd say no to that. That complicates things with little gain since you then may also need to write out additional information to be able to recreate the data in the client.

As a related change, we should split up the configuration directory so that content like screenshots and chat logs are in a location the user can easily find. Such as the My Documents folder on Windows.

@allejo
Copy link
Member Author

allejo commented Dec 29, 2020

As a related change, we should split up the configuration directory so that content like screenshots and chat logs are in a location the user can easily find. Such as the My Documents folder on Windows.

Should this be done in 2.4 or wait until 2.6? Also, should we have some automatic migration for moving existing screenshots?

@blast007
Copy link
Member

For splitting the configuration directory, I'd say for 2.6. I'm almost inclined to think that this feature should wait until then as well. At some point we need to stop adding new features to 2.4 and focus on just fixes/polish.

Sorry, something went wrong.

@allejo allejo modified the milestones: 2.4.22, 2.6 Release Dec 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants