In order to ensure that players get the message a warning is supposed to bring across, I had the idea to disable chat/commands for a warned player until he types the exact reason into the chat. I had it many times that players did not quite understand why/that they got warned (despite the huge red chat message) or they just didn't understand why. Forcing them to actually read the reason and retype it should reconsider their behaviour. It would also decrease spamming directly, as a spamming player would be immediately muted, until he acknowledged his warning, or just leaves.

To make sure the warned player understands his task, it would obviously also be repeated why he can't chat right now and what he is supposed to do.

Discuss your opinions.

It would also decrease spamming directly, as a spamming player would be immediately muted, until he acknowledged his warning, or just leaves.

If players work out that simply rejoining the server bypasses it (which they will), they'll start a habit of seeing a message in chat saying they can't talk, or use a particular command, and rejoining, without having actually read the reason.

What I meant by leaving is that if a player's solely reason to join the server is to spam, he would just leave after doing some spams afterwards, with the immediate warn it would also make it easier to migitate the spam. A reconnect would still require for him to input the reason.

I'm on the fence with this still. I can see where you're coming from and can see that it may be useful. However, it could be more than irritating to players, especially players who may not speak/understand the language the warning message is in.

First of all this would need to be togglable.

I don't think the language is a big deal. If you have a German server in most cases you will have your warning reasons in German or well known English equivalents. The only issue I could image is that the warned player does not understand that he has to type the reason or whatever in the chat to be able to send other messages again. But I hardly guess that this particular phrase will be translatable too :P

Whenever BM denies the chat message, clear instructions should be repeated to the user.

I still think that this would be an amazing addition. The amount of times I warned a spamming player and he just kept spamming/insulting or whatever is pretty high. The fact that a player really needs to acknowledge what he has done wrong would greatly reduce time spent moderating.

Amazing, will check that out!

tested and it's awesome, thank you so much!

Two things:

• I see that you have added the removal of the necessity to type in the command on dis/reconnect, I don't think that this would be necessary
• Maybe also block commands, to really force the player to acknowledge his warn?

Could you elaborate on why you would consider that a memory leak?
Yes, the data could theoretically be stored in memory forever (until server restart), but why would that even matter? It's just a UUID and it's not even an unnecessary store, hence why I would not call that a classic memory leak. I thought those were defined by the property that the data still stored will no longer be used at all. That may be the case here, but doesn't have to be.

I see that you have added the removal of the necessity to type in the command on dis/reconnect, I don't think that this would be necessary

Unfortunately it's necessary as there's no guarantee they'll come back. If they aren't removed on disconnect, it'll be classified as a memory leak.

Maybe also block commands, to really force the player to acknowledge his warn?

All commands?

Would not make much sense to just partially block various commands I guess?

It's not just a UUID, it contains the warning data as well. Compared to when Minecraft first started, servers these days don't need restarting often. Some are online for over a month without any restarts; some even longer. Not removing the UUID on leave would be considered a memory leak in these cases, as it would slowly over time eat more and more memory.

Then how about calling Bukkit scheduler in for example 1hr after logout to remove said data?

Won't be efficient. It'd be better to use Guava's caching class (but I need to double check I can use it without causing backwards incompatibility issues due to package name changes between Spigot/Bukkit versions). The 1h time limit will also need a config option as well.

Sounds fine, although I really don't think that efficiency is any bottleneck here. Seems a bit overoptimized to me.