User-toggleable message filtering

[Parsonswy]

Is your feature request related to a problem? Please describe.
Feature request. We have a maturity-diverse community on our server. Some want to be able to swear, some don't care, and some are young shouldn't see it or just don't want to see it. We'd like a tool that caters towards nuance rather than filtering all swearing / censored topics and people run free.

Describe the solution you'd like
User-togglable message filtering. Our solution to this was allowing users to individually toggle whether they see blacklisted words in chat messages, or if they get censored. This would only impact the message they see. So if I have the censor on, I see ******, but if someone else has the censor off, they see whatever the original word or phrase was.

We were thinking of just having a static blacklist in a config file. Nothing fancy or dynamic for users to add or remove their own words.

There would be a configuration option in a file for enabling censorship by default. Player's could use an in-game command like /censor to toggle message censoring on and off.

Describe alternatives you've considered
Given that we want to modify the message conditionally for each player, intercepting the PlayerChatEvent before MultiChat doesn't work. I don't think the MultiChat API currently has a way to do this now. That said, I don't think there are any other options short of forking MultiChat and running our own custom build.

Additional context
I put this in as a feature request, but recognize it is arguably beyond the scope of a chat plugin's core. If it's something deemed beyond the scope of something that should be core to MultiChat, I think it could instead serve as a use case to consider whenever there is time to build out a more robust API.

If the MultiChat dev team thinks this is worth adding to MultiChat natively, I'd be willing to work on a PR for it.

[akshualy]

Hey there,

I believe this is a perfectly fine request to make of a chat plugin, especially since we already provide some capability of censoring through our integrated chat control. However, judging from experience, I highly doubt that this will get a high priority and be done in any reasonable amount of time in the near future for you to wait for it.

But, I also have good news for you. MultiChat is designed with other plugins that need to use the chat in mind. (i.e. chat games, captcha, town chat, etc.) I prepared a gist for you to take a look at, how you could implement that feature in your own local plugin and still have it work with MultiChat (click here).

I hope this helps you. If you have any more questions feel free to ask them here or simply join our Discord :)

[Parsonswy]

Hello, thank you for the expedient response.

We'd considered such an implementation, but I don't think that can work because I'd need to modify the message conditionally per the player's preference so I can't modify the message before it gets to MultiChat, it's more of an issue of message distribution.

If I intercept the chat event after MultiChat has applied formatting, that would work for local messages only. I don't think an event gets emitted for messages that were relayed between servers on the global channel, nor does it address private messages or group chats.

[akshualy]

Hey again,

sorry, it was a bit early and I completely forgot about the per-player setting while writing my answer. Here is an updated Gist. Please take note of the comments I left. It's a bit "hacky", but I doubt it'll get much better without proper API support whenever we can get to add it.

[Parsonswy]

Thank you again, but I didn't think messages sent over global chat generated any chat events on the servers they were relayed to. As in, if a message is set by a player on server1, the event fires on server1, but MultiChat does not generate any chat events on server2, server3, etc. so the filter would seem really inconsistent for players because it would only work if they were on the server that the message was sent from.

Has the way MultiChat relays messages changed or did I miss something in the src?

[akshualy]

I think you're right, but I have no means to test that right now. If that doesn't work, it might be smarter to fork the repository and modify the distribution method of messages to facilitate your specific means until we have better API.