Page 1 of 1


Posted: Thu May 19, 2016 8:26 am
by iPlayer
SpamProofCommands (custom package)
GitHub repo:
Download latest release:

Ever been worried of binding some resource-consuming callbacks to server, client and say (chat) commands?
Possibility of bad Russian guys coming to spam your server won't let you sleep?

Fear no more! SpamProofCommands custom package restricts your callbacks to be executed by each player only after some cooldown delay.


Syntax: Select all

from core import echo_console
from messages import SayText2

from spam_proof_commands.client import ClientCommand
from spam_proof_commands.say import SayCommand
from spam_proof_commands.server import ServerCommand

TEST_TEXT = "You've just executed a command"

test_message = SayText2(message=TEST_TEXT)

# This command will only be executed once every 3 seconds
@SayCommand(3, "!spamtest")
def say_spamtest(command, index, team_only):

# Same with client command
@ClientCommand(3, "spamtest_client")
def client_spamtest_client(command, index):

# And server command
@ServerCommand(3, "spamtest_server")
def server_spamtest_server(command):


Hope somebody finds this useful.

Re: SpamProofCommands

Posted: Thu May 19, 2016 9:31 am
by Mahi
Good idea and package iPlayer, nice job! There are a few improvements I'd make though.

First of all, you seem to define a common base class in the which is then used in the other files of your package. This is rather bad practice, as should contain as little as possible. It's often used for stuff like forward importing the "important" classes (important for the target group of your package) from your package. will get executed everytime someone imports something from your package. So, I would suggest you to move the stuff in your into a "" or similar, and import that in your client, server, and say files.

Next up you could forward import your "important" classes in the

Code: Select all

from .client import ClientCommand
from .say import SayCommand
from .server import ServerCommand
Now when someone wants to use your package, they can still use the "from spam_proof_commands.client import ClientCommand", but they can also shorten it down to "from spam_proof_commands import ClientCommand". You could also leave the empty if you don't want forward importing. Most files in general are empty, and it's considered really good practice to keep it that way.

An other thing that caught my eye is ANTI_SPAM_TEXT. SP's translations use dictionaries, so the lookup operations take insignificant time and processing power. We're talking about micro seconds here, this is nothing but premature optimization to get rid of an useful feature.

Other than that, it looks really nice :)!

Re: SpamProofCommands

Posted: Thu May 19, 2016 9:37 am
by iPlayer
Thanks for the feedback, Mahi.

I should probably move base class to
I did not forward any classes from, and to look as close as possible to original SP commands package. It doesn't forward them.

As for translations, I didn't use them not because of retrieving a translated string by language, but because of every time you use translations, SP first things first tries to determine client's language - and it does it by retrieving cl_language cvar from client - thus network overhead.

Re: SpamProofCommands

Posted: Thu May 19, 2016 9:53 am
by Mahi
Yeah seems like a good idea since you're mimicing SP's commands package. And thus leave the empty.

As far as I understand (without super in-depth familiarization to the translations package), the LangStrings class uses dict's normal __getitem__ so there's nothing done with cl_language out there. Messages on the other hand seem to categorize players by language anyways, so there's no noticeable difference between using translations or not. Also, seems like cl_language is cached, so the networking is done only once anyways! :) Translations should be fine as far as I can see.

Re: SpamProofCommands

Posted: Thu May 19, 2016 11:48 am
by iPlayer
I've made a new release. Moved contents of to, removed and added English and Russian translations for the anti-spam message.

Thanks again, Mahi, for your feedback.