Thoughts about a 'command libary'

[Omega_K2]

I've been thinking about how the command libary implementation will be. When thinking about the ES one I have to say that I beleive it to be not really useful to me most of the time (so I actually wrote my own cmdlib in ES for personal needs.


EDIT: My approach to the command lib. I'll continue to update this occasionly - fine by me if it gets included into SP, otherwise I'll just ship this with my scripts :P
https://german-slaughterhouse.de/svn/k2tools/trunk/addons/source-python/_libs/k2tools/cmdlib.py


So here is what I think a command libary should or could do; stuff that has a common purpose:

SimpleCommandManger (possibly obsolete though c++ side of things):

• Only basic access for registering chat/console/server commands
• No fancy stuff = No overheard
• Should have one native python argument on the return method - a dictionary that contains the user, arguments and the command itself.

AdvancedCommandManager:

• Spam Protection
  
  • Defaults to ON
  • Should have configurable theresholds (for example, you can configure that people get kicked if they excute more then 5 commands within 1 second)
  • Should have configurable punishment actions (possibly just a function that does whatever is needed - by default "kick")
  • Reason: IMHO a must-have feature to prevent DoS exploits. Most scripters do not seem aware that their commands, if spammed, may cause the server to halt or crash - especailly if they are more expensive in nature
• Support for command aliases
  
  • Probably you can just define a list/tuple of command aliases you wish to have
  • When getting the command information, both, the 'real' command and the alias used could be returned to the KW dictionary
  • Reason: Often you want multiple commands to do the same thing. Good example is adding a command for accessing the community website which may be !community !home !motd !<yourcommunityname> !website !homepage or anything similar
• Support for registration of multiple types at once
  
  • You can choose whether your command should be registered as public say command, private say command, console command and/or server command
  • Registration of the same callback for multiple ways is possible
  • As for getting to know what type was used, another KW argument could be added ('type')
  • Reason: Often different types of the same command should do the same
• Prefix support (for specific types)
  
  • You can choosea list of prefixes for a specific command type
  • When returing, it still returns the command normally without the prefix. Again, a special KW word argument could be used to return if there was a prefix (and which)
  • Reason: Some plugins introduced 'command-type' prefixes, users are used to them and it allows for easy registration of 2 different things along side. A popular example would be sourcemod commands, usually you have a public command prefixed with ! (like !sm_admin) and a private one ( /sm_admin) and the console version without any prefixes (sm_admin). Another reason is that when you create your own game mode, you often want to prefix the commands (like rpg_admin).
• Command logging
  
  • You can choose to log the command and parameters BEFORE and AFTER the command execution
  • Reason: Generally useful for any kind of admin systems (so you know who did what) and also useful for debugging crashes [command executed -> server died. Without logging you may not know that the command was executed]
• Authentification support
  
  • Depending on how the auth implemenation will be, you can choose to implement authenficiation for that command
  • Assuming my system (or a similar one), you could choose to register/pass a permission which is checked when the command is accessed
  • Reason: Well obviously you often want to authentificate your users for certain commands. Especially if it is of 'admin' nature.
• Internal 'help'
  
  • Idea is to provide a translation file or section which provides help regarding the command
  • Help can be shown though sp_help <command>
  • Supports translations as opposed to the source engine built-in command description
  • Reason: Unified interface makes this easier for everyone
• Pre-'Hook' function(s)
  
  • List of methods that will be executed before the command
  • Command will only be executed if all of them return true
  • Arguments will be passed as if it was the real command
  • Reason: Basically allows custom authentification and other purposes such as checking whether the database is accessable (instead of doing this on a per-command basis)

These would a lot of 'batteries-included' things, but I think they are generally quite useful and it's better to have them centerally defined instead of having multiple scripts each with their own implementation.

Input appreciated again :P

[your-name-here]

I've been thinking about how the command libary implementation will be. When thinking about the ES one I have to say that I beleive it to be not really useful to me most of the time (so I actually wrote my own cmdlib in ES for personal needs.
So here is what I think a command libary should or could do; stuff that has a common purpose:

SimpleCommandManger (possibly obsolete though c++ side of things):

• Only basic access for registering chat/console/server commands
• No fancy stuff = No overheard
• Should have one native python argument on the return method - a dictionary that contains the user, arguments and the command itself.

AdvancedCommandManager:

• Spam Protection
  
  • Defaults to ON
  • Should have configurable theresholds (for example, you can configure that people get kicked if they excute more then 5 commands within 1 second)
  • Should have configurable punishment actions (possibly just a function that does whatever is needed - by default "kick")
  • Reason: IMHO a must-have feature to prevent DoS exploits. Most scripters do not seem aware that their commands, if spammed, may cause the server to halt or crash - especailly if they are more expensive in nature
• Support for command aliases
  
  • Probably you can just define a list/tuple of command aliases you wish to have
  • When getting the command information, both, the 'real' command and the alias used could be returned to the KW dictionary
  • Reason: Often you want multiple commands to do the same thing. Good example is adding a command for accessing the community website which may be !community !home !motd !<yourcommunityname> !website !homepage or anything similar
• Support for registration of multiple types at once
  
  • You can choose whether your command should be registered as public say command, private say command, console command and/or server command
  • Registration of the same callback for multiple ways is possible
  • As for getting to know what type was used, another KW argument could be added ('type')
  • Reason: Often different types of the same command should do the same
• Prefix support (for specific types)
  
  • You can choose the prefix for a specific command type
  • When returing, it still returns the command normally without the prefix. Again, a special KW word argument could be used to return if there was a prefix (and which)
  • Reason: Some plugins introduced 'command-type' prefixes, users are used to them and it allows for easy registration of 2 different things along side. A popular example would be sourcemod commands, usually you have a public command prefixed with ! (like !sm_admin) and a private one ( /sm_admin) and the console version without any prefixes (sm_admin)
• Command logging
  
  • You can choose to log the command and parameters BEFORE and AFTER the command execution
  • Reason: Generally useful for any kind of admin systems (so you know who did what) and also useful for debugging crashes [command executed -> server died. Without logging you may not know that the command was executed]
• Authentification support
  
  • Depending on how the auth implemenation will be, you can choose to implement authenficiation for that command
  • Assuming my system (or a similar one), you could choose to register/pass a permission which is checked when the command is accessed
  • Reason: Well obviously you often want to authentificate your users for certain commands. Especially if it is of 'admin' nature.
• Internal 'help'
  
  • Idea is to provide a translation file or section which provides help regarding the command
  • Help can be shown though sp_help <command>
  • Supports translations as opposed to the source engine built-in command description
  • Reason: Unified interface makes this easier for everyone
• Pre-'Hook' function(s)
  
  • List of methods that will be executed before the command
  • Command will only be executed if all of them return true
  • Arguments will be passed as if it was the real command
  • Reason: Basically allows custom authentification and other purposes such as checking whether the database is accessable (instead of doing this on a per-command basis)

These would a lot of 'batteries-included' things, but I think they are generally quite useful and it's better to have them centerally defined instead of having multiple scripts each with their own implementation.

Input appreciated again :P

From the C++ perspective, this sounds fine to me. The only issue we are going to hit is the construction of commands. You can't directly instantiate a ConCommand because it requires a C++ callback function. To get around this, I plan to provide Cvar.RegisterCommand and Cvar.UnregisterCommand functions, so your library will have to call down to those. I do think I can wrap ConCommand's attributes however, which should help make your life easier.

[stonedegg]

One thing to your sourcemod example:
The general console command is sm_admin for example. ! or / is taking the place of sm_, so its just !admin or /admin in chat.

But I like the thoughts of this cmdlib.

[Omega_K2]

One thing to your sourcemod example:
The general console command is sm_admin for example. ! or / is taking the place of sm_, so its just !admin or /admin in chat.

But I like the thoughts of this cmdlib.

Both works. SM just shortens the commands. With that cmdlib a similar implementation could be to use !sm_ and ! as prefix for example.

[Omega_K2]

My go at the cmdlib. Look at the todo to see what's missing so far :P
As for public_say commands it actually works

http://pastebin.com/9EpAEDVj

[Woody]

You made the paste private :P

[Omega_K2]

Dammit. Fixed :P

[Woody]

Coming along nice! Looking forward to a finished version!

[satoon101]

I thought I would finally post my opinions on each of these points:

• Spam Protection
  • Defaults to ON
  • Should have configurable theresholds (for example, you can configure that people get kicked if they excute more then 5 commands within 1 second)
  • Should have configurable punishment actions (possibly just a function that does whatever is needed - by default "kick")
  • Reason: IMHO a must-have feature to prevent DoS exploits. Most scripters do not seem aware that their commands, if spammed, may cause the server to halt or crash - especailly if they are more expensive in nature

Spam protection is definitely something we are considering adding. I'm not sure how it will be implemented, yet, but we will be looking into it.

• Support for command aliases
  • Probably you can just define a list/tuple of command aliases you wish to have
  • When getting the command information, both, the 'real' command and the alias used could be returned to the KW dictionary
  • Reason: Often you want multiple commands to do the same thing. Good example is adding a command for accessing the community website which may be !community !home !motd !<yourcommunityname> !website !homepage or anything similar

We already have support for adding multiple commands. Since we return the CCommand instance, you can easily get the command used. If you really want there to be a "real" command, I would hope your script knows, by which function is called, what the "real" command for that function is without having to pass it back.

• Support for registration of multiple types at once
  • You can choose whether your command should be registered as public say command, private say command, console command and/or server command
  • Registration of the same callback for multiple ways is possible
  • As for getting to know what type was used, another KW argument could be added ('type')
  • Reason: Often different types of the same command should do the same

The only difference between "public" and "private" with this plugin, is whether or not the return value from any callback is False. You can easily register the same callback to all 3 command types, but keep in mind that each of the 3 has different arguments passed. It will be up to your script to handle those differences. This should be easy, anyway, as each has a different number of arguments (server - 1, client - 2, say - 3). The decorator system, obviously, does not allow adding multiple types, but you can always use the CommandRegistry classes.

• Prefix support (for specific types)
  • You can choosea list of prefixes for a specific command type
  • When returing, it still returns the command normally without the prefix. Again, a special KW word argument could be used to return if there was a prefix (and which)
  • Reason: Some plugins introduced 'command-type' prefixes, users are used to them and it allows for easy registration of 2 different things along side. A popular example would be sourcemod commands, usually you have a public command prefixed with ! (like !sm_admin) and a private one ( /sm_admin) and the console version without any prefixes (sm_admin). Another reason is that when you create your own game mode, you often want to prefix the commands (like rpg_admin).

I really do not see a need for this to be included within the plugin itself. If you wish for your scripts to utilize different prefixes, your scripts should be designed to handle that themselves.

• Command logging
  • You can choose to log the command and parameters BEFORE and AFTER the command execution
  • Reason: Generally useful for any kind of admin systems (so you know who did what) and also useful for debugging crashes [command executed -> server died. Without logging you may not know that the command was executed]

The logging system, overall, has yet to really be designed. I really do not think we need as robust of a logging system as what you previously designed. At some point I do intend on getting back into working on that, though.

• Authentification support
  • Depending on how the auth implemenation will be, you can choose to implement authenficiation for that command
  • Assuming my system (or a similar one), you could choose to register/pass a permission which is checked when the command is accessed
  • Reason: Well obviously you often want to authentificate your users for certain commands. Especially if it is of 'admin' nature.

This is clearly a no-brainer. It is already implemented, and works fine with the one auth provider we have included so far. Once we get more auth providers setup, we will obviously need to re-test to verify this system is working properly.

• Internal 'help'
  • Idea is to provide a translation file or section which provides help regarding the command
  • Help can be shown though sp_help <command>
  • Supports translations as opposed to the source engine built-in command description
  • Reason: Unified interface makes this easier for everyone

I'm not sure how much this is even needed. Proper documentation on your script's commands should suffice.

• Pre-'Hook' function(s)
  • List of methods that will be executed before the command
  • Command will only be executed if all of them return true
  • Arguments will be passed as if it was the real command
  • Reason: Basically allows custom authentification and other purposes such as checking whether the database is accessable (instead of doing this on a per-command basis)

I really do not believe this is necessary. It would add an unnecessary layer on the command system that probably very few scripters would use. You can always call your own "pre" function prior to the real function within your own script.

Satoon