AlliedModders Wiki - User contributions [en]

Generic Source Events

2007-08-14T16:22:26Z

AlicanC: /* round_start */

:''Refer back to [[Game Events (Source)]] for more events.''

These '''should''' apply to all Source engine games
=== team_info ===
{{qnotice|Info about team}} 
{{begin-hl2msg|team_info|string}}
{{hl2msg|byte|teamid}}
{{hl2msg|string|teamname}}
{{end-hl2msg}}

=== team_score ===
{{qnotice|Team score changed}} 
{{begin-hl2msg|team_info|string}}
{{hl2msg|byte|teamid}}
{{hl2msg|short|score}}
{{end-hl2msg}}

=== player_team ===
{{qnotice|Player change his team}} 
{{begin-hl2msg|player_team|string}}
{{hl2msg|short|userid}}
{{hl2msg|byte|team}}
{{hl2msg|byte|oldteam}}
{{hl2msg|bool|disconnect}}
{{end-hl2msg}}

=== player_class ===
{{qnotice|A player changed his class}} 
{{begin-hl2msg|player_class|string}}
{{hl2msg|short|userid}}
{{hl2msg|string|class}}
{{end-hl2msg}}

=== player_death ===
{{qnotice|A game event, name may be 32 charaters long}} 
{{begin-hl2msg|player_death|string}}
{{hl2msg|short|userid}}
{{hl2msg|short|attacker}}
{{end-hl2msg}}

=== player_hurt ===
{{qnotice|A player was hurt}} 
{{begin-hl2msg|player_hurt|string}}
{{hl2msg|short|userid}}
{{hl2msg|short|attacker}}
{{hl2msg|byte|health}}
{{end-hl2msg}}

=== player_chat ===
{{qnotice|A public player chat}} 
{{begin-hl2msg|player_chat|string}}
{{hl2msg|bool|teamonly}}
{{hl2msg|short|userid}}
{{hl2msg|string|text}}
{{end-hl2msg}}

=== player_score ===
{{qnotice|Players scores changed}} 
{{begin-hl2msg|player_score|string}}
{{hl2msg|short|userid}}
{{hl2msg|short|kills}}
{{hl2msg|short|deaths}}
{{hl2msg|short|score}}
{{end-hl2msg}}

=== player_spawn ===
{{qnotice|player spawned in game}} 
{{begin-hl2msg|player_spawn|string}}
{{hl2msg|short|userid}}
{{end-hl2msg}}

=== player_shoot ===
{{qnotice|Player shoot his weapon}} 
{{begin-hl2msg|player_shoot|string}}
{{hl2msg|short|userid}}
{{hl2msg|byte|weapon}}
{{hl2msg|byte|mode}}
{{end-hl2msg}}

=== player_use ===
{{qnotice|When a player uses an option}} 
{{begin-hl2msg|player_use|string}}
{{hl2msg|short|userid}}
{{hl2msg|short|entity}}
{{end-hl2msg}}

=== player_changename ===
{{qnotice|Player changed name}} 
{{begin-hl2msg|player_changename|string}}
{{hl2msg|string|userid}}
{{hl2msg|string|oldname}}
{{hl2msg|string|newname}}
{{end-hl2msg}}

=== game_newmap ===
{{qnotice|Send when new map is completely loaded}} 
{{begin-hl2msg|game_newmap|string}}
{{hl2msg|string|mapname}}
{{end-hl2msg}}

=== game_start ===
{{qnotice|A new game starts}} 
{{begin-hl2msg|game_start|string}}
{{hl2msg|long|roundslimit}}
{{hl2msg|long|timelimit}}
{{hl2msg|long|fraglimit}}
{{hl2msg|string|objective}}
{{end-hl2msg}}

=== game_end ===
{{qnotice|A game ended}} 
{{begin-hl2msg|game_end|string}}
{{hl2msg|byte|winner}}
{{end-hl2msg}}

=== round_start ===
{{qnotice|The round started}} 
{{begin-hl2msg|round_start|string}}
{{hl2msg|long|timelimit}}
{{hl2msg|long|fraglimit}}
{{hl2msg|string|objective}}
{{end-hl2msg}}

=== round_end ===
{{qnotice|The round ended}} 
{{begin-hl2msg|round_end|string}}
{{hl2msg|byte|winner}}
{{hl2msg|byte|reason}}
{{hl2msg|string|message}}
{{end-hl2msg}}

=== game_message ===
{{qnotice|A game message}} 
{{begin-hl2msg|game_message|string}}
{{hl2msg|byte|target}}
{{hl2msg|string|text}}
{{end-hl2msg}}

=== break_breakable ===
{{qnotice|A breakable (func_break) is broken.}} 
{{begin-hl2msg|break_breakable|string}}
{{hl2msg|long|entindex}}
{{hl2msg|short|userid}}
{{hl2msg|byte|material}}
{{end-hl2msg}}

=== break_prop ===
{{qnotice|A breakable prop is broken.}} 
{{begin-hl2msg|break_prop|string}}
{{hl2msg|long|entindex}}
{{hl2msg|short|userid}}
{{end-hl2msg}}

SQL Admins (SourceMod)

2007-08-14T11:46:45Z

AlicanC: /* Frequently Asked Questions */

SourceMod has support for loading and managing admins via SQL, using any of the supported SQL drivers provided (currently, MySQL and SQLite). This can be very advantageous if you have a large number of admins, you wish to manage your admins via external tools, or you wish to share admins across servers.

This article will explain how to set up your server to use admins through SQL. No knowledge of SQL is required for basic administration; however, by using this feature you should realize that SourceMod does not provide easy functionality for full SQL control. You will need to use a third party tool or learn SQL yourself if you need greater functionality.

However, it is assumed that you:
*Have access to an SQL database;
*Know how to access the SQL database;
*Know how to execute commands or scripts on the SQL database.

=Database Setup=
==MySQL==
If you have not already created a database on your MySQL server, do so.

Find the script <tt>configs/sql-init-scripts/admins-mysql.sql</tt> in the SourceMod distribution. Then, using either the command line or a tool such as [http://www.phpmyadmin.net/ phpMyAdmin], run its contents. This will create the necessary tables.

Next, open <tt>configs/databases.cfg</tt> on your server. You should see a section called <tt>"default"</tt>. You can either use this section, or create a new one called <tt>"admins"</tt> if you wish to separate your connections. You must fill out the <tt>driver</tt>, <tt>host</tt>, <tt>database</tt>, <tt>user</tt>, and <tt>pass</tt> fields. If you do not need a field, use empty quotation marks as the value (<tt>""</tt>).

Example:
<pre>
"default"
{
"driver" "mysql"
"host" "localhost"
"database" "sourcemod"
"user" "myaccount"
"pass" "mypassword"
}
</pre>

==SQLite==
SourceMod distributes a pre-made SQLite database file with all of the admin tables created. If you with to manually create a database or add tables to a pre-existing database, use the contents of the <tt>configs/sql-init-scripts/admins-sqlite.sql</tt> script.

Copy the <tt>configs/sql-init-scripts/admins-sqlite.sq3</tt> binary from the SourceMod distribution into your server's <tt>data/sqlite</tt> folder. Then, add a section to your server's <tt>configs/databases.cfg</tt> file as follows:

<pre>
"admins"
{
"driver" "sqlite"
"database" "admins-sqlite"
}
</pre>

You may choose to rename the database file, or to use the file as your default database instead.

=Enabling Plugins=
By default, all of the SQL plugins are located in the <tt>plugins/disabled</tt> folder on your server -- they are not loaded by default. To enable plugins, move them from the <tt>plugins/disabled</tt> folder and into <tt>plugins</tt>.

You will usually want to enable <tt>sql-admin-manager.smx</tt>. This plugin adds some helpful console commands for very basic admin management. However, you should only enable '''ONE''' of the other two SQL plugins:

<ol>
<li><tt>admin-sql-prefetch.smx</tt>: This plugin is ideal for small to medium sized databases without much connection lag. It loads the entire database admin contents at map load (or whenever a refresh is requested). If you have serious database delay or want to be able to add/delete/edit admins without refreshing the per-map cache on each server, this isn't the plugin for you.
<ul>
<li>PROS: Very simple plugin with no extra complexity.</li>
<li>*CONS: Gameserver will stall whenever the cache is refreshed (mapload or when using <tt>sm_reloadadmins</tt>). If you add, remove, or edit admins, the changes are not reflected until the cache is refreshed.</li>
</ul>
</li>

<li><tt>admin-sql-threaded.smx</tt>: This plugin is completely threaded. This makes it much more complex, and thus it is currently "experimental" (although it has been tested to work fine). It pre-caches all group and override information. Admin-lookup is done completely dynamically.
<ul>
<li>PROS: A faulty/slow database connection will never halt the server. If you add/remove/edit admins, the changes will be reflected as soon as the player connects to the server.</li>
<li>CONS: It is very complex and thus not trivial to edit for custom changes. It also may have unexpected functionality (for example, <tt>sm_reloadadmins</tt> will have a slight delayed reaction because the plugin is multi-threaded).</li>
</ul>
</li>
</ol>

Once you have enabled the manager, and enabled ONE of the <tt>admin-sql</tt> plugins, you are ready to go!

=Management Commands=
As a convenience, SourceMod provides a few basic SQL admin management commands via the <tt>sql-admin-manager.smx</tt> plugin. All of the commands require the <tt>root</tt> admin flag.

The following conventions are used:
*When <authtype> is requested, it means one of the following three values: <tt>steam</tt>, <tt>ip</tt>, or <tt>name</tt>.
*When <identity> is requested, it should be the unique string to be paired with the <tt>authtype</tt>. For example, a <tt>steam</tt> identity would be a Steam ID. An <tt>ip</tt> identity would be an IP address, and a <tt>name</tt> identity would be a Half-Life 2 player name.
*When [immunity] is requested, it means one of the following three values: <tt>none</tt>, <tt>default</tt>, or <tt>global</tt>.

Note: if a string has spaces, it must be in quotes!

Note: A colon is a break character and Steam IDs must be in quotes!

:{|
|- class="t2th"
| Command
| Format
| Description
|- class="t2td"
| sm_sql_addadmin
| <nowiki><alias> <authtype> <identity> <flags> [password]</nowiki>
| Adds a new entry to the <tt>sm_admins</tt> table. The <tt>alias</tt> can be any value and is usually used to assign a readable name to an IP/SteamID.
|- class="t2td"
| sm_sql_deladmin
| <nowiki><authtype> <identity></nowiki>
| Removes an admin.
|- class="t2td"
| sm_sql_addgroup
| <nowiki><name> <flags> [immunity]</nowiki>
| Adds a new group with the specified flags and immunity/
|- class="t2td"
| sm_sql_delgroup
| <nowiki><name></nowiki>
| Removes the specified group. Quotation marks are optional if the name has odd characters.
|- class="t2td"
| sm_sql_setadmingroups
| <nowiki><authtype> <identity> [group1] ... [group N]</nowiki>
| Sets an admin's group list. The inheritance order is the order the groups are specified in. This sets, and does not add; thus specifying no groups removes the user from all groups. Example:
<tt>sm_sql_setadmingroups steam "STEAM_0:1:16" "Full Admins"</tt>
|}

=Frequently Asked Questions=
Q: Can I use <tt>admin-sql</tt> and <tt>admin-flatfile</tt> at the same time?
A: Yes. The data will be merged together in SourceMod's cache.

Q: Can I use both the <tt>threaded</tt> and <tt>prefetch</tt> SQL plugins at the same time?
A: No.

Q: Can duplicate groups/admins be in the flat files and the SQL database?
A: Yup. They will be merged safely.

=Schemas=
This section documents the required portions of the admin table schema. You do not need to read or learn this unless you plan to use SQL directly.

The exact schemas for each driver are located in <tt>configs/sql-init-scripts</tt>. The purpose of this document is to explain the fields rather than list the exact structures.

==sm_admins==
This table is used to store administrators. Although the primary key is <tt>id</tt>, applications should enforce that <tt>authtype</tt> and <tt>identity</tt> have no combined duplicates.

Primary key: <tt>id</tt> (auto increments).

:{|
|- class="t2th"
| Field
| Type
| Purpose
|- class="t2td"
| id
| integer
| Unique integer identifying the row.
|- class="t2td"
| authtype
| string NOT NULL
Constrained to 'steam', 'name', or 'ip'
| Authentication type the identity is against.
|- class="t2td"
| identity
| string NOT NULL
| Steam ID, name, or IP address.
|- class="t2td"
| password
| string
| Password, if any, the admin must use.
|- class="t2td"
| flags
| string NOT NULL
| Permission flag string.
|- class="t2td"
| name
| string NOT NULL
| Alias used for external tools (all but ignored in SourceMod).
|}

==sm_groups==
This table is used to store all groups entries. Although the primary key is <tt>id</tt>, applications should enforce that the <tt>name</tt> field stays unique.

Primary key: <tt>id</tt> (auto increments).

:{|
|- class="t2th"
| Field
| Type
| Purpose
|- class="t2td"
| id
| integer
| Unique integer identifying the row.
|- class="t2td"
| immunity
| string NOT NULL
Constrained to 'none', 'global', or 'default'
| Immunity level the group gets.
|- class="t2td"
| flags
| string NOT NULL
| Permissions flag string.
|- class="t2td"
| name
| string NOT NULL
| Unique name of the group.
|}

==sm_admins_groups==
This table is used to map admins to the groups they will inherit.

Primary key: <tt>admin_id</tt>, <tt>group_id</tt>

:{|
|- class="t2th"
| Field
| Type
| Purpose
|- class="t2td"
| admin_id
| integer
| Reference to the <tt>sm_admins.id</tt> field. Specifies the admin inheriting the group.
|- class="t2td"
| group_id
| integer
| Reference to the <tt>sm_groups.id</tt> field. Specifies the group the admin is inheriting.
|- class="t2td"
| inherit_order
| integer NOT NULL
| Order of inheritance for the given admin. Lower means earlier inheritance.
|}

==sm_group_immunity==
This table is used to map which groups are immune from other groups.

Primary key: <tt>group_id</tt>, <tt>other_id</tt>

:{|
|- class="t2th"
| Field
| Type
| Purpose
|- class="t2td"
| group_id
| integer
| Reference to the <tt>sm_groups.id</tt> field. Specifies the group gaining immunity.
|- class="t2td"
| other_id
| integer
| Reference to the <tt>sm_groups.id</tt> field. Specifies who <tt>group_id</tt> is becoming immune from.
|}

==sm_group_overrides==
This table is used to specify group-based command overrides.

Primary key: <tt>group_id</tt>, <tt>type</tt>, <tt>name</tt>

:{|
|- class="t2th"
| Field
| Type
| Purpose
|- class="t2td"
| group_id
| integer
| Reference to the <tt>sm_groups.id</tt> field. Specifies the group the override is for.
|- class="t2td"
| type
| string NOT NULL
Constrained to 'command' or 'group'.
| Specifies whether the override is a command or a command group.
|- class="t2td"
| name
| string NOT NULL
| Command name.
|- class="t2td"
| access
| string NOT NULL
Constrained to 'allow' or 'deny'.
| Whether the command is allowed or denied to this group.
|}

==sm_overrides==
This table is used to specify global command overrides.

Primary key: <tt>type</tt>, <tt>name</tt>

:{|
|- class="t2th"
| Field
| Type
| Purpose
|- class="t2td"
| type
| string NOT NULL
Constrained to 'command' or 'group'.
| Specifies whether the override is a command or a command group.
|- class="t2td"
| name
| string NOT NULL
| Command name.
|- class="t2td"
| flags
| string NOT NULL
| Permissions flag string.
|}

[[Category:SourceMod Documentation]]

Commands (SourceMod Scripting)

2007-06-10T16:23:44Z

AlicanC: "remove console" -> "remote console"

[[SourceMod]] allows you to create console commands similar to [[AMX Mod X]]. There are two main types of console commands:
*'''Server Commands''', which are fired from one of the following input methods:
**the server console itself;
**the remote console (RCON);
**the ServerCommand() function, either from SourceMod or the [[Half-Life 2]] engine.
*'''Console Commands''', which are fired from one of the following input methods:
**a client's console
**any of the server command input methods

For server commands, there is no client index. For console/client commands, there is a client index, but it may be 0 to indicate that the command is from the server.

Note that button "commands," such as +attach and +duck, are not actually console commands. They are a separate command stream sent over the network, as they need to be tied to a specific frame.

=Server Commands=
As noted above, server commands are fired through the server console, whether remote, local, or through the Source engine. There is no client index associated with a server command.

Server commands are registered through the <tt>RegServerCmd()</tt> function, listed in <tt>console.inc</tt>. When registering a server command, you may be hooking an already existing command, and thus whether you return <tt>Plugin_Handled</tt> or <tt>Plugin_Continue</tt> is important.
*<tt>Plugin_Continue</tt>: The original server command will be processed, if there was one. If the server command was created by a plugin, this has no effect.
*<tt>Plugin_Handled</tt>: The original server command will not be processed, if there was one. If the server command was created by a plugin, this has no effect.
*<tt>Plugin_Stop</tt>: This original server command will not be processed, if there was one. Additionally, no further hooks will be called for this command until it is fired again.

==Adding Server Commands==
Let's say we want to add a test command to show how Half-Life 2 breaks down command arguments. A possible implementation might be:
<pawn>public OnPluginStart()
{
RegServerCmd("test_command", Command_Test)
}

public Action:Command_Test(args)
{
new String:arg[128]
new String:full[256]

GetCmdArgString(full, sizeof(full))

PrintToServer("Argument string: %s", full)
PrintToServer("Argument count: %d", args)
for (new i=1; i<=args; i++)
{
GetCmdArg(i, arg, sizeof(arg))
PrintToServer("Argument %d: %s", i, arg)
}
}</pawn>

==Blocking Server Commands==
Let's say we wanted to disable the "kickid" command on the server. There's no real good reason to do this, but for example's sake:
<pawn>public OnPluginStart()
{
RegServerCmd("kickid", Command_KickId)
}

public Action:Command_Kickid(args)
{
return Plugin_Handled
}</pawn>

=Console Commands=
Unlike server commands, console commands can be triggered by either the server or the client, so the callback function receives a client index as well as the argument count. If the server fired the command, the client index will be 0.

When returning the <tt>Action</tt> from the callback, the following effects will happen:
*<tt>Plugin_Continue</tt>: The original functionality of the command (if any) will still be processed. If there was no original functionality, the client will receive "Unknown command" in their console.
*<tt>Plugin_Handled</tt>: The original functionality of the command (if any) will be blocked. If there was no functionality originally, this prevents clients from seeing "Unknown command" in their console.
*<tt>Plugin_Stop</tt>: Same as <tt>Plugin_Handled</tt>, except that this will be the last hook called.

Note that, unlike AMX Mod X, SourceMod does not allow you to register command filters. I.e., there is no equivalent to this notation:
<pawn>register_clcmd("say /ff", "Command_SayFF");</pawn>

This notation was removed to make our internal code simpler and faster. Writing the same functionality is easy, and demonstrated below.

==Adding Commands==
Adding client commands is very simple. Let's port our earlier testing command to display information about the client as well.

<pawn>public OnPluginStart()
{
RegConsoleCmd("test_command", Command_Test)
}

public Action:Command_Test(client, args)
{
new String:arg[128]
new String:full[256]

GetCmdArgString(full, sizeof(full))

if (client)
{
new String:name[32]
GetClientName(client, name, sizeof(name))
PrintToServer("Command from client: %s", name);
} else {
PrintToServer("Command from server.");
}

PrintToServer("Argument string: %s", full)
PrintToServer("Argument count: %d", args)
for (new i=1; i<=args; i++)
{
GetCmdArg(i, arg, sizeof(arg))
PrintToServer("Argument %d: %s", i, arg)
}
}</pawn>

==Hooking Commands==
A common example is hooking the say command. Let's say we want to tell players whether FF is enabled when they say '/ff' in game.

Before we implement this, a common point of confusion with the 'say' command is that Half-Life 2 (and Half-Life 1), by default, send it with the text in one big quoted string. This means if you say "I like hot dogs," your command will be broken down as such:
*Argument string: "I like hot dogs"
*Argument count: 1
*Argument #1: I like hot dogs

However, if a player types this in their console: <tt>say I like yams</tt>, it will be broken up as:
*Argument string: I like yams
*Argument count: 3
*Argument #1: I
*Argument #2: like
*Argument #3: yams

Thus, to take into account both of these situations, we are going to use <tt>GetCmdArgString</tt> and manually parse the input.

<pawn>public OnPluginStart()
{
RegConsoleCmd("say", Command_Say)
}

public Action:Command_Say(client, args)
{
new String:text[192]
GetCmdArgString(text, sizeof(text))

new startidx = 0
if (text[0] == '"')
{
startidx = 1
/* Strip the ending quote, if there is one */
new len = strlen(text);
if (text[len-1] == '"')
{
text[len-1] = '\0'
}
}

if (StrEqual(text[startidx], "/ff"))
{
new Handle:ff = FindConVar("mp_friendlyfire")
if (GetConVarInt(ff))
{
PrintToConsole(client, "Friendly fire is enabled.")
} else {
PrintToConsole(client, "Friendly fire is disabled.")
}
/* Block the client's messsage from broadcasting */
return Plugin_Handled
}

/* Let say continue normally */
return Plugin_Continue
}</pawn>

==Creating Admin Commands==
Let's create a simple admin command which kicks another player by their full name.

<pawn>public OnPluginStart()
{
RegAdminCmd("admin_kick",
Command_Kick,
ADMFLAG_KICK,
"Kicks a player by name")
}

public Action:Command_Kick(client, args)
{
if (args < 1)
{
PrintToConsole(client, "Usage: admin_kick <name>")
return Plugin_Handled
}

new String:name[32], maxplayers, target = -1
GetCmdArg(1, name, sizeof(name))

maxplayers = GetMaxClients()
for (new i=1; i<=maxplayers; i++)
{
if (!IsClientConnected(i))
{
continue
}
decl String:other[32]
GetClientName(i, other, sizeof(other))
if (StrEqual(name, other))
{
target = i
}
}

if (target == -1)
{
PrintToConsole(client, "Could not find any player with the name: \"%s\"", name)
return Plugin_Handled
}

ServerCommand("kickid %d", GetClientUserId(target));

return Plugin_Handled
}</pawn>

==Immunity==
In our previous example, we did not take immunity into account. Immunity is a much more complex system in SourceMod than it was in AMX Mod X, and there is no simple flag to denote its permissions. Instead, two functions are provided:
*<tt>CanAdminTarget</tt>: Tests raw AdminId values for immunity.
*<tt>CanUserTarget</tt>: Tests in-game clients for immunity.

While immunity is generally tested ''player versus player'', it is possible you might want to check for immunity and not have a targetting client. While there is no convenience function for this yet, a good idea might be to check for either ''default'' or ''global'' immunity on the player's groups (these can be user-defined for non-player targeted scenarios).

When checking for immunity, the following heuristics are performed in this exact order:
<ol><li>If the targeting AdminId is <tt>INVALID_ADMIN_ID</tt>, targeting fails.</li>
<li>If the targetted AdminId is <tt>INVALID_ADMIN_ID</tt>, targeting succeeds.</li>
<li>If the targeting admin has <tt>Admin_Root</tt> (<tt>ADMFLAG_ROOT</tt>), targeting succeeds.</li>
<li>If the targetted admin has global immunity, targeting fails.</li>
<li>If the targetted admin has default immunity, and the targeting admin belongs to no groups, targeting fails.</li>
<li>If the targetted admin has specific immunity from the targeting admin via group immunities, targeting fails.</li>
<li>If no conclusion is reached via the previous steps, targeting succeeds.</li>
</ol>

So, how can we adapt our function about to use immunity?

<pawn>public Action:Command_Kick(client, args)
{
if (args < 1)
{
PrintToConsole(client, "Usage: admin_kick <name>")
return Plugin_Handled
}

new String:name[32], maxplayers, target = -1
GetCmdArg(1, name, sizeof(name))

maxplayers = GetMaxClients()
for (new i=1; i<=maxplayers; i++)
{
if (!IsClientConnected(i))
{
continue
}
decl String:other[32]
GetClientName(i, other, sizeof(other))
if (StrEqual(name, other))
{
target = i
}
}

if (target == -1)
{
PrintToConsole(client, "Could not find any player with the name: \"%s\"", name)
return Plugin_Handled
}

if (!CanUserTarget(client, target))
{
PrintToConsole(client, "You cannot target this client.")
return Plugin_Handled
}

ServerCommand("kickid %d", GetClientUserId(target))

return Plugin_Handled
}</pawn>

=Client-Only Commands=
SourceMod exposes a forward that is called whenever a client executes any command string in their console, called <tt>OnClientCommand</tt>. An example of this looks like:

<pawn>public Action:OnClientCommand(client, args)
{
new String:cmd[16]
GetCmdArg(0, cmd, sizeof(cmd)); /* Get command name */

if (StrEqual(cmd, "test_command"))
{
/* Got the client command! Block it... */
return Plugin_Handled
}

return Plugin_Continue
}</pawn>

It is worth noting that not everything a client sends will be available through this command. Command registered via external sources in C++ may not be available, especially if they are created via <tt>CON_COMMAND</tt> in the game mod itself. For example, "say" is usually implemented this way, because it can be used by both clients and the server, and thus it does not channel through this forward.

=Chat Triggers=
SourceMod will automatically create chat triggers for every command you make (as of revision 900). For example, if you create a console command called "sm_megaslap," administrators will be able to type any of the following commands in <tt>say</tt>/<tt>say_team</tt> message modes:
<pre>!sm_megaslap
!megaslap
/sm_megaslap
/megaslap</pre>

SourceMod then executes this command and its arguments as if it came from the client console.
*"<tt>!</tt>" is the default ''public'' trigger (<tt>PublicChatTrigger</tt> in <tt>configs/core.cfg</tt>) and your entry will be displayed to all clients as normal.
*"<tt>/</tt>" is the default ''silent'' trigger (<tt>SilentChatTrigger</tt> in <tt>configs/core.cfg</tt>) and your entry will be blocked from being displayed.

SourceMod will only execute commands registered with <tt>RegConsoleCmd</tt> or <tt>RegAdminCmd</tt>, and only if those commands are not already provided by Half-Life 2 or the game mod. If the command is prefixed with "sm_" then the "sm_" can be omitted from the chat trigger.

Console commands which wish to support usage as a chat trigger should not use <tt>PrintTo*</tt> natives. Instead, they should use <tt>ReplyToCommand()</tt>, which will automatically print your message either as a chat message or to the client's console, depending on the source of the command.

[[Category:SourceMod Development]][[Category:SourceMod Scripting]]