Improved chat + Fix #460 (Chat messages sent twice)

[Nico8340]

A completely new and configurable solution has been added to admin and admin2.

It is possible to turn off Anti-Spam, edit monitoring and suspension times, disable word repetition, enable linking with playercolors and allow players to use custom HEX color codes. (And it fixes #460)

[0xHexadecimal]

This breaks playercolors if you want to use it independently of freeroam. The reason chat messages are sent twice now is because playercolors got added to mtaserver.config as a default starting resource where this wasn't this case before.

[Nico8340]

This breaks playercolors if you want to use it independently of freeroam. The reason chat messages are sent twice now is because playercolors got added to mtaserver.config as a default starting resource where this wasn't this case before.

I misunderstood things a bit, now I went over everything again. It is true that if we want to use it without freeroam, it will not work properly because of this commit. However, the solution is not to remove it from mtaserver.conf, since playerblips needs the playercolors resource to work properly.

[Nico8340]

Now playercolors work properly even if freeroam is not running.

[0xHexadecimal]

I misunderstood things a bit, now I went over everything again. It is true that if we want to use it without freeroam, it will not work properly because of this commit. However, the solution is not to remove it from mtaserver.conf, since playerblips needs the playercolors resource to work properly.

having playercolors running does nothing other than suppress a warning from playerblips. It might make more sense to change playerblips to ignore the running of playercolors if freeroam is running or remove the functionality from freeroam that already assigns random player nametag colours.

[Nico8340]

having playercolors running does nothing other than suppress a warning from playerblips. It might make more sense to change playerblips to ignore the running of playercolors if freeroam is running or remove the functionality from freeroam that already assigns random player nametag colours.

In this case, I think it is simpler and more meaningful to modify playerblips, since freeroam's onPlayerChat event handler contains other things, such as word repetition checking and spam protection. For this reason, playercolors must be removed again from mtaserver.conf.

[Nico8340]

The changes have been made, if they are accepted in their current form, a pull request will be created in the main repository regarding the removal of the playercolors resource from mtaserver.conf.

[jlillis]

The proper fix (imo, which I was working on) is the following:

• Remove all onPlayerChat handlers from playercolors and freeroam
• Re-implement their logic in admin and admin2, providing settings to control behavior (anti-spam parameters, color codes, etc)
• (optional) Submit PR to mtasa-blue to make the chatbox respect nametag colors by default.

[Nico8340]

The proper fix (imo, which I was working on) is the following:

• Remove all onPlayerChat handlers from playercolors and freeroam
• Re-implement their logic in admin and admin2, providing settings to control behavior (anti-spam parameters, color codes, etc)
• (optional) Submit PR to mtasa-blue to make the chatbox respect nametag colors by default.

It's ok, I'll work on the solution.

[Nico8340]

The new implementation is ready, the onPlayerChat event handlers have been removed from all gamemodes -- A completely new and configurable solution has been added to admin and admin2.

It is possible to turn off Anti-Spam, edit monitoring and suspension times, disable word repetition, enable linking with playercolors and allow players to use custom HEX color codes.

[Dutchman101]

It would be nice to use this opportunity for blocking common spam characters (like Bismillah).. there is a way to select by charset to stop weird characters like that, if you don't know how i will post it soon

[0xHexadecimal]

Strongly disagree. Anti-spam is a basic security task and the admin panel is the best place to do it. It also happens to be a convenient place to add the logic needed to handle player nametag colors and color codes in chat rather than having it re-implemented multiple times across other resources. If server owners already have their own systems in place, they can turn these features off.

I am not against having admin filter chat messages that may be considered harmful. But having a chat-system which cancels the original chat just to display coloured name tags which are set in a different resource, just seems out of place for an admin system. At that point why not just set the random coloured name tags in admin? Along side attaching coloured blips? Why are those not in admin but having a coloured names chatbox is?

[PlatinMTA]

The filtering should be done inside the chat resource and not the admin resource (unless you want to have all the chat resource in the admin panel) (exports are slow). The admin panel does not handle the chat. If you want the admin panel to have an option to enable or disable the chat maybe add a setting to the meta.xml for the filtering or create some exports.

[Nico8340]

The filtering should be done inside the chat resource and not the admin resource (unless you want to have all the chat in the admin panel). The admin panel does not handle the chat. If you want the admin panel to have an option to enable or disable the chat maybe add a setting to the meta.xml for the filtering or create some exports.

This implementation handles the chat in the admin resources. (admin and admin2) (see conversation history)

[Nico8340]

I fixed the errors in the review and added the option to completely disable the chat handler. If anyone has an idea for implementing the spam filter mentioned by Dutchman, feel free to share it.

[Dutchman101]

It would be nice to use this opportunity for blocking common spam characters (like Bismillah).. there is a way to select by charset to stop weird characters like that, if you don't know how i will post it soon

How do you imagine the implementation? Ban certain keywords or limit the message to a certain character set? (a-Z, 0-9, etc)

@Nico8340

This will eliminate a bunch of spam characters:

function removeChatSpam(msg)
	local newMsg = ""
	for i = 1, utfLen(msg) do
		local char = utfCode(utfSub(msg,i,i))
		if(not (char >= 768 and char <= 879)) then
			newMsg = newMsg .. utfSub(msg,i,i)
		end
	end
	return newMsg
end

I didn't test it with Bismillah, you may want to do that and handle it with match if not covered

[Dutchman101]

There's a conflict with d8834a8 (i dont know why it's not been detected)

[Nico8340]

There's a conflict with d8834a8 (i dont know why it's not been detected)

I see that the whole Pull Request is bugged, but since there are still a lot of unnecessary commits and I messed up the whole branching, I'm closing this PR and opening a new PR soon.

[Dutchman101]

How about some advanced anti-spam features, like:

• Configurable limits with action, like: mute, kick, or ban player for x duration if they repeatedly get flagged for spamming. Mute is the first line defense, to store serials of repeat offenders for persisting spamming rap sheet, an SQLite .db can be used. The more times they get a lighter automatic punishment (mute, kick), the sooner it will escalate to a more severe punishment, Mute > kick > 30 mins ban > longer bans as defined in meta.xml. In this case, also add a toggle for automatic .db clearing (choice between interval or to do it on server launch)

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

• If chat activity exceeds a certain amount (specified in meta.xml) of messages per the polling window (specified in meta.xml, default: 10 secs), an abnormality has started and the system will offer a meta.xml toggle-based resolution: slowmode (limit chat messages globally, from anyone.. and return "You need to wait, slowmode has been activated due to possible spam" to anyone that tries to talk while it's still active

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.

@Nico8340

[Nico8340]

How about some advanced anti-spam features, like:

• Configurable limits with action, like: mute, kick, or ban player for x duration if they repeatedly get flagged for spamming. Mute is the first line defense, to store serials of repeat offenders for persisting spamming rap sheet, an SQLite .db can be used. The more times they get a lighter automatic punishment (mute, kick), the sooner it will escalate to a more severe punishment, Mute > kick > 30 mins ban > longer bans as defined in meta.xml. In this case, also add a toggle for automatic .db clearing (choice between interval or to do it on server launch)

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

• If chat activity exceeds a certain amount (specified in meta.xml) of messages per the polling window (specified in meta.xml, default: 10 secs), an abnormality has started and the system will offer a meta.xml toggle-based resolution: slowmode (limit chat messages globally, from anyone.. and return "You need to wait, slowmode has been activated due to possible spam" to anyone that tries to talk while it's still active

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)

@Nico8340

It's fine by me, please copy this message to the new PR when i open it, and continue any future conversation there.