search

multitheftauto / mtasa-resources

This project maintains a list of up-to-date resources that come with Multi Theft Auto.
https://multitheftauto.com
MIT License
150 stars 146 forks source link

Chat #463

Closed Nico8340 closed 5 days ago

Nico8340 commented 5 months ago

Chat

This Pull Request removes chat management from all game modes and adds a new, separate solution that is highly configurable and customizable, with automatic moderation by today's standards.

Fixes #460 Follows #461

Preps

Tasks

Backlog

There was discussion that it would be nice to include a user interface in the existing admin panel to configure moderation. This will be implemented optionally after the later works.

Dutchman101 commented 5 months ago

Copying over my proposal from the previous PR..

How about some advanced anti-spam features, like:

Measures against coordinated spamming, like: Multiple players are sending the same or similar message (not a single source, but it'll be big) or different ones; measures like anti-repeat or chat limits per player won't be effective

Server owners can tweak the # of messages/polling interval based on what's normal for their server. For example, if it's a gamemode some people can get hyped up and send a burst of happy messages, like end-of-round, they would need to make the polling interval longer. If the server gets more popular (leading to increased chat activity), they would need a higher message count tolerance.

So a spamming incident can be resolved without the presence of a server admin. If one is present when slowmode is activated, they should be able to use a command to lift it if they go to manually resolve it (like: ban the coordinated spammers)

Bonus points: every time slowmode has been applied, automatically send a "suspected spamming incident report" into the admin panel reports list (submitter: not player, but system) eventually with a recap of the chat lines ( + author) around the time it got triggered. Using the same functionality that already captures a player's last chat messages if they got reported with /report & selected in the target player dropdown.

Dutchman101 commented 5 months ago

In the upcoming code reviews (when all commits are added to the new PR), there should be extra attention for conditions/optimal branching of the code in onPlayerChat, to ensure that there's no grave performance consequences that comes with complexity; ideally, most chat messages (to say: ones that don't trigger any detection or additional checks) shouldn't take much more CPU time/be slower than 'clean' onPlayerChat handlers present in various gamemodes before this.

I didn't review or test this, but we need to keep our eye on this aspect, it has to be checked off on when the PR is in its final state.

Nico8340 commented 5 months ago

A few people said it during the previous PR and also on Discord, they think it's not a good solution to implement the chat in the admin resource, since quite a lot of people use the admin resource in their own projects, so they need to turn off the chat or change the code if the latest version is used. In addition, if we want to implement all of this in the admin, two resources must be managed at the same time.

What do you think, wouldn't it be easier to create a new resource called 'chat' for this? @Dutchman101

Dutchman101 commented 5 months ago

What do you think, wouldn't it be easier to create a new resource called 'chat' for this? @Dutchman101

yes. Then also output a console warning if one of the gamemodes are running (that now rely on the chat resource) but the chat resource isn't.. or even preserve the original chat handlers in those resources, but attach/detach them based on whether or not the new chat resource is in use; this will provide server owners the freedom which road to walk entirely. It can also be compounded with an opt-in or opt-out (meta.xml) above the running state of 'chat', and since the old chat handlers containin the old code will be present as well, it can just fall back on it. Any server owners that run into issues can conveniently return to the old behavior.

jlillis commented 5 months ago

A few people said it during the previous PR and also on Discord, they think it's not a good solution to implement the chat in the admin resource, since quite a lot of people use the admin resource in their own projects, so they need to turn off the chat or change the code if the latest version is used. In addition, if we want to implement all of this in the admin, two resources must be managed at the same time.

What do you think, wouldn't it be easier to create a new resource called 'chat' for this? @Dutchman101

I think if you are going to go forward with these expanded features it makes sense for it to be in a separate resource. However, I would personally like to see a section in the admin2 panel added to interface with chat and manage these settings in a way that gives appears to the user that it is part of the admin panel rather than an add-on. I think that can be covered as a separate scope of work in a later PR.

Nico8340 commented 5 months ago

I think if you are going to go forward with these expanded features it makes sense for it to be in a separate resource. However, I would personally like to see a section in the admin2 panel added to interface with chat and manage these settings in a way that gives appears to the user that it is part of the admin panel rather than an add-on. I think that can be covered as a separate scope of work in a later PR.

It's a good idea, I'll think about it after completing the remaining tasks.

Fernando-A-Rocha commented 3 weeks ago

Ok so a new chat resource needs to be created with Meta xml settings to manage the moderation and spam features.

I don't see the need for a special panel in admin2 to control the settings because the admin panel already has a resource settings editing panel. You just double click the resource name in the list and it shows a pretty list of settings.

Fernando-A-Rocha commented 3 weeks ago

I'm willing to finish this asap if y'all agree with above ,

jlillis commented 3 weeks ago

I don't see the need for a special panel in admin2 to control the settings because the admin panel already has a resource settings editing panel. You just double click the resource name in the list and it shows a pretty list of settings.

My argument here is that because the chat is a "core functionality" and this resource is replacing functionality that was previously in admin, so it would be convenient for admins to have access to these settings directly in the main part of the admin panel rather than having to dig into resource settings.

I would be fine with omitting it for now. Perhaps it could be saved as a new feature just for admin2 in the future.

Fernando-A-Rocha commented 3 weeks ago

I don't see the need for a special panel in admin2 to control the settings because the admin panel already has a resource settings editing panel. You just double click the resource name in the list and it shows a pretty list of settings.

My argument here is that because the chat is a "core functionality" and this resource is replacing functionality that was previously in admin, so it would be convenient for admins to have access to these settings directly in the main part of the admin panel rather than having to dig into resource settings.

I would be fine with omitting it for now. Perhaps it could be saved as a new feature just for admin2 in the future.

For the sake of pushing progress to fix the chat bug ASAP, I think this main panel for configuring chat should be done in another PR for admin2 indeed.

Nico8340 commented 2 weeks ago

I'm willing to finish this asap if y'all agree with above ,

I can continue working with it from today, so I will finish it soon.

Nico8340 commented 2 weeks ago

For the sake of pushing progress to fix the chat bug ASAP, I think this main panel for configuring chat should be done in another PR for admin2 indeed.

I think that the admin2 user interface for configuration is an important and good feature, and since its implementation does not take much time, it fits in this pull request. If anyone has an idea about it, feel free to share.

Fernando-A-Rocha commented 2 weeks ago

For the sake of pushing progress to fix the chat bug ASAP, I think this main panel for configuring chat should be done in another PR for admin2 indeed.

I think that the admin2 user interface for configuration is an important and good feature, and since its implementation does not take much time, it fits in this pull request. If anyone has an idea about it, feel free to share.

Okey, we can brainstorm ideas for the admin2 chat control panel.

Nico8340 commented 1 week ago

I was busy earlier.. I will continue working on this pull request this week 🚀

Nico8340 commented 1 week ago

I need some advice on how to store message logs. I thought of using an SQLite database, but the table cannot be filled with messages indefinitely, there should be a limit.

jlillis commented 1 week ago

SQL will be your best option. Add a column to the table for the timestamp of each message. In the resource, have a function to DELETE FROM messages WHERE timestamp < [whatever the limit is]. Execute this function on resource start and set a timer to trigger it from time to time.

Fernando-A-Rocha commented 1 week ago

@Nico8340 I suggest logging to an SQLite DB, and periodically running a query that deletes log entries that are older than X days (e.g. 30 days). Alternatively, to keep a maximum number of rows in the table, you can save the last row ID and run this query to periodically delete the rows with IDs inferior to the lastRowID - Y: DELETE FROM yourtable WHERE rowid < (last_row_id - 1000)

Nico8340 commented 5 days ago

I'm going to open a new pull request, because the preps weren't right, since we agreed to leave the old handlers as a fallback option, and with this modification I would completely overturn the current structure. In order to preserve the conversation, I will link this pr to the new one.