AlliedModders Wiki - User contributions [en]

Translations (SourceMod Scripting)

2007-08-03T17:21:44Z

Teame06: /* Usage in a Plugin */

__FORCETOC__
[[SourceMod]], like its AMX Mod X predecessor, contains a built-in Multi-Lingual Translation layer ("ML"). The ML system is one of the secondary SourceMod systems designed to make the platform as flexible as possible. It fully supports UTF-8.

=Introduction=
The SourceMod ML System is based off the following terms:
*'''Languages''': Preset languages defined in <tt>configs\languages.cfg</tt>. If a language is not in this file, it cannot be translated until it is added and the in-memory translation cache rebuilt.
*'''Phrases'''/'''Translation Keys''': Short, generic key phrases used to identify a set of translations. These reside in configuration files in the <tt>translations</tt> folder. These are called <tt>translation files</tt>.
*'''Translations''': A given text translation of a phrase for a given language. These reside in a <tt>translation file</tt>.

'''Note''': Languages and Phrases are both case sensitive.

==File Format==
The ML Translation File format is in standard Valve configuration form. It is comprised of one master section, <tt>"Phrases</tt>,<tt>"</tt> which contains any number of named sub-sections. Each sub-section defines one named <tt>Phrase</tt>, which cannot itself have sub-sections. It allows the following properties:
*'''Key''': "#format"
**'''Value''': Comma-delimited, ordered pairs of indexes and format strings.
*'''Key''': Two-letter language code.
**'''Value''': Language translation string.

Example:
<pre>"Phrases"
{
"Welcome"
{
"en" "Welcome to SourceMod"
"es" "Bienvenidos a SourceMod"
}
}</pre>

In the above example, two translations are defined for the "Welcome" phrase - one for English, and one for Spanish. However, consider a phrase which needs certain words inserted, as in this contrived example:
<pre>"Phrases"
{
"Pants"
{
"en" "pants"
"es" "pantalones"
}
//INVALID EXAMPLE: "Bail's pants are on fire"
"OnFire_plural"
{
"en" "%s's %s are on fire!"
"es" "¡Los %s de %s están en llamas!"
}
}</pre>

In the above example, the word orders have changed. English inserts the subject first, and the direct object second. Spanish associates ownership differently -- literally, ''the pants of Bail are on fire.'' This poses a problem for scripters, who always pass format parameters in one order. To solve this, the <tt>#format</tt> property was introduced. This pre-defines the order of format parameters. Example:
<pre>"Phrases"
{
//Example: "Bail's pants are on fire"
"OnFire_plural"
{
"#format" "{1:s},{2:s}"
"en" "{1}'s {2} are on fire!"
"es" "¡Los {2} de {1} están en llamas"
}
//Example: "Hello, Bail!"
"Hello"
{
"#format" "{1:s}"
"en" "Hello, {1}"
"es" "Hola, {1}"
}
}</pre>

The format string is comprised of comma delimited sections, each section enclosed in brackets. Each section has an ''index'' and a ''format specifier'', which are separated with a colon. Format specifiers follow the general rules of [[Format Class Functions (SourceMod Scripting)|formatting]], however, only the following types are currently allowed:
*'''d'''/'''i''': Digits/Integer display
*'''x''': Hexadecimal display
*'''f''': Floating point display
*'''s''': String display
*'''c''': Character display (UTF-8 compatible)

Note that currently, the special "%T" format type is not allowed inside a language translation string.

=Usage in a Plugin=
Plugins must call <tt>LoadTranslations</tt> on each translation file they wish to use. Failure to do so will cause any translations to fail, even if another plugin loads the same file. This is to help prevent phrase-clashes between plugins.

Inline translation works in any [[Format Class Functions (SourceMod Scripting)|format-class]] of functions. A new format specifier, '%T', is introduced, which instructs the format routine to insert a translated phrase. Unlike all other format specifiers, this requires a minimum of two parameters:
*'''1st Parameter''': A string containing the phrase to be translated.
*'''2nd Parameter''': One of the following:
**The <tt>LANG_SERVER</tt> constant, which specifies a translation to the default language.
**A player ID constant, which specifies a translation to the player's set language.
*'''3rd Parameter and higher''': Inputs into the phrase's format specifiers, if necessary.

Examples of this are:
<pawn>new String:name[32], String:buffer[128];
GetClientName(client, name, sizeof(name));
PrintToChat(client, "[SourceMod] %T", "Hello", client, name);
Format(buffer, sizeof(buffer), "[SourceMod] %T", "Hello", LANG_SERVER, name);</pawn>

A breakdown of the format parameters:
*<tt>"Hello"</tt>: The phrase to translate.
*<tt>client/LANG_SERVER</tt>: Who to translate the phrase to.
*<tt>name</tt>: The "Hello" phrase requires one string, so this will appear in the translated phrase.

Lastly, there is a second form of inline translation, using '%t'. This is only allowed in functions which act directly on one or more clients. It eliminates the second parameter, and uses the original client specified. Example:
<pawn>PrintToChat(client, "[SourceMod] %t", "Hello", name);</pawn>

As you can see from this example, we did not have to specify the client index more than once. Thus, it is usually more convenient to use the limited '%t' version in functions such as <tt>PrintToChat</tt>. However, in functions which are not "player directed," such as <tt>Format</tt> or <tt>PrintToServer</tt>, only '%T' can be used.

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

SDKTools (SourceMod Scripting)

2007-06-16T22:28:49Z

Teame06: OnPluginInit to OnPluginStart

The SDKTools extension is an extension for various functions provided by the Source SDK. Additionally, it has the ability to dynamically call many C++ functions in the SDK, for example, from CBaseEntity or any derived class.

SDKTools contains simplified versions of SDK functions pre-written for ease of use. These can be found in the additional include files:
*<tt>sdktools_functions.inc</tt> - Popular functions from the SDK.

SDKTools is powered by "BinTools," a powerful extension for creating dynamic C/C++ calls. BinTools is automatically loaded by SDKTools.

=GameConfigs=
GameConfig files go into the "gamedata" folder under "sourcemod." In older revisions it was under "sourcemod/configs" which is now deprecated.

==Virtual Offsets==
For adding virtual offsets, add sub-sections to the "Offsets" section of your game config file. For example:

<pre>
"Games"
{
"cstrike"
{
"Offsets"
{
"GiveNamedItem"
{
"windows" "329"
"linux" "330"
}
"EyePosition"
{
"windows" "117"
"linux" "118"
}
}
}
}</pre>

==Signature Scans==
For automated signature scans, add sub-sections to the "Signatures" section of your game config file. There are three properties for a signature:
*<tt>library</tt>: Must be "server" right now.
*<tt>windows</tt>: A signature written in binary; for example, "\x56" instead of "0x56" -- the '*' character is a single byte wildcard.
*<tt>linux</tt>: Either a signature as with <tt>windows</tt>, or a named symbol. To use a named symbol, start the string with the '@' character. If a signature begins with '@', write the character in hexadecimal as above.

Example:
<pre>
"Games"
{
"cstrike"
{
"Signatures"
{
"RoundRespawn"
{
"library" "server"
"windows" "\x56\x8B\xF1\x8B\x06\xFF\x90*\x04\x00\x00\x8B\x86*\x0D\x00"
"linux" "@_ZN9CCSPlayer12RoundRespawnEv"
}
}
}
}</pre>

==Inheritance==
If you wish for multiple mods to inherit from one block, you can add a special "#supported" section under a "#default" section. For example:

<pre>
"Games"
{
"#default"
{
"#supported"
{
"game" "dod"
}
}
}</pre>

This specifies that the given block will be read for Day of Defeat as well.

=Calling Functions=
Calling functions is complicated and requires strict attention to the C++ API you are trying to use. If you make a mistake, something bad '''will''' happen (and if not, you got lucky!) SDKTools is more complicated than PimpinJuice's "Hacks" extension because it precompiles all of the information needed to convert from Plugin memory to C++ types. This precompilation step ensures better safety and speed, but it lengthens the preparation process.

With that said, let's look at an overview of the call creation process. Before making calls, we must ''prepare'' the call. This will give us a <tt>Handle</tt> which will let us make as many calls as we like.
<ol>
<li>Init - The preparation must be initialized. Here we can specify the calling convention, which is either static, or BaseEntity/BasePlayer-based. BasePlayer should be used when only player entities should be allowed as the <tt>this</tt> pointer.</li>
<li>Destination - The call must have a destination address or virtual index to use. This is normally done via <tt>PrepSDKCall_SetFromConf</tt> which ties into gameconf files.</li>
<li>Return Info - If the call has return information, it must be set via <tt>PrepSDKCall_SetReturnInfo</tt>.</li>
<li>Parameters - Each parameter (if any) must be added with <tt>PrepSDKCall_AddParameter</tt>.</li>
<li>Finalize - The call must be finalized with <tt>EndPrepSDKCall</tt>, which will return a <tt>Handle</tt>. If it doesn't, one or more of the preparation operations failed.</li>
</ol>

For the examples below, consider a plugin called "sdkexamples.sp" which has a gamedata file of "plugin.sdkexamples.txt" containing the definitions in the first section.

==RoundRespawn Example==
CCSPlayer::RestartRound is a Counter-Strike Source function which respawns players. It used by CS:S DM. Prototype:
<pre>void CCSPlayer::RoundRespawn()</pre>

SDKCall example:
<pawn>#include <sourcemod>
#include <sdktools>

new Handle:hGameConf;
new Handle:hRoundRespawn;

public OnPluginStart()
{
hGameConf = LoadGameConfigFile("plugin.sdkexamples");
StartPrepSDKCall(SDKCall_Player);
PrepSDKCall_SetFromConf(hGameConf, SDKConf_Signature, "RoundRespawn");
hRoundRespawn = EndPropSDKCall();
}

RespawnPlayer(client)
{
SDKCall(hRoundRespawn, client);
}</pawn>

Note that we did not have to set any extra information for parameters or return info, since CCSPlayer::RoundRespawn has no parameters and has a void return.

==GiveNamedItem Example==
GiveNamedItem will give a player a named item. Prototype:
<pre>virtual CBaseEntity *CBasePlayer::GiveNamedItem(const char *item, int iSubType = 0);</pre>

<pawn>#include <sourcemod>
#include <sdktools>

new Handle:hGameConf;
new Handle:hGiveNamedItem;

public OnPluginStart()
{
hGameConf = LoadGameConfigFile("plugin.sdkexamples");

StartPrepSDKCall(SDKCall_Player);
PrepSDKCall_SetFromConf(hGameConf, SDKConf_Virtual, "GiveNamedItem");
PrepSDKCall_SetReturnInfo(SDKType_CBaseEntity, SDKPass_Pointer);
PrepSDKCall_AddParameter(SDKType_String, SDKPass_Pointer);
PrepSDKCall_AddParameter(SDKType_PlainOldData, SDKPass_Plain);
hGiveNamedItem = EndPropSDKCall();
}

GiveItem(client, const String:item[])
{
return SDKCall(hGiveNamedItem, client, item, 0);
}</pawn>

==GetEyePosition Example==
Prototype:
<pre>virtual Vector CBaseEntity::EyePosition();</pre>

<pawn>#include <sourcemod>
#include <sdktools>

new Handle:hGameConf;
new Handle:hGetEyePosition;

public OnPluginStart()
{
hGameConf = LoadGameConfigFile("plugin.sdkexamples");

StartPrepSDKCall(SDKCall_Player);
PrepSDKCall_SetFromConf(hGameConf, SDKConf_Virtual, "EyePosition");
PrepSDKCall_SetReturnInfo(SDKType_Vector, SDKPass_ByValue);
hGetEyePosition= EndPropSDKCall();
}

GetEyePosition(client, Float:pos[3])
{
SDKCall(hGetEyePosition, client, pos);
}</pawn>

Note that the vector is returned as the third parameter (first parameter after the <tt>this</tt> pointer).

=See Also=
*[[CCSPlayer_offset_list_(SourceMM)|CCSPlayer Offsets]]
*[[CBaseCombatWeapon_CSS_offset_list_(SourceMM)|CBaseCombatWeapon (CS:S) Offsets]]
*[[CDODPlayer_offset_list_%28SourceMM%29|CDODPlayer Offsets]]
*[[CHL2MP_Player_offset_list_%28SourceMM%29|CHL2MPPlayer Offsets]]
*[[HL2CTF_CHL2_Player_offset_list_%28SourceMM%29|CHL2Player (HL2CTF) Offsets]]
*[[Dystopia_CDYSPlayer_offset_list_%28SourceMM%29|CDYSPlayer (Dystopia) Offsets]]
*[[Empires_CSDKPlayer_offset_list_%28SourceMM%29|CSDKPlayer (Empires) Offsets]]
*[[Useful_Signatures_%28Source%29|Useful Signatures (Source)]]

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

Writing Extensions

2007-05-25T19:31:06Z

Teame06: /* External Interfaces */

SourceMod's Extension System is a powerful way to greatly enhance the flexibility of your SourceMod plugins. You can take full advantage of SourceMod's Core, using the interfaces it provides, to create C++ plugins, plugin events, plugin native functions, and shared interfaces. Extensions can also hook into Metamod:Source.

This article goes into the details of creating a SourceMod Extension. Knowledge of C++ is required.

=SDK Structure=
First, download the [[SourceMod SDK]] from the [[SourceMod]] website. The directory structure looks like this:
*<tt>extensions</tt>
**<tt>geoip/</tt> - Source code to the GeoIP extension
**<tt>mysql/</tt> - Source code to the MySQL extension
**<tt>threader/</tt> - Source code to the Threader extension
*<tt>plugins/</tt> - Source code to all of SourceMod's plugins
**<tt>include/</tt> - The include files which document plugin API
*<tt>public/</tt> - Interface files for SourceMod's Core Interfaces
**<tt>extensions/</tt> - Interfaces that are provided by extensions
**<tt>sample_ext/</tt> - The Sample Extension SDK
**<tt>sourcepawn</tt> - The include/interface files for SourcePawn
*<tt>sourcepawn/</tt>
**<tt>compiler/</tt> - The SourcePawn Compiler

=Starting an Extension=
For simplicity, this article will assume you are using the SDK base files. These are:
*<tt>smsdk_config.h</tt> - Configuration settings (we will be editing this)
*<tt>smsdk_ext.h</tt> - Header for SDK wrappers (usually never needs to be edited)
**''Note: Sometimes, this may be updated by the SourceMod Dev Team. Using a newest version is recommended.'
*<tt>smsdk_ext.cpp</tt> - Source for SDK wrappers (usually never needs to be edited)
**''Note: Sometimes, this may be updated by the SourceMod Dev Team. Using a newest version is recommended.'
*<tt>extension.h</tt> - User file for main extension header
*<tt>extension.cpp</tt> - User file for main extension code

''The <tt>extension.*</tt> files are not technically part of the SDK. However, they are provided to give users a starting point and some documentation.''

'''Note:''' For help setting up Visual Studio, please see [[#Setting up Visual Studio|Setting up Visual Studio]].

The first step of creating your extension is to configure it. Open the <tt>smsdk_config.h</tt> file and edit each of the following defines. Use the information below to guide you.
*<tt>SMEXT_CONF_NAME</tt> - The general name for your Extension (should be short).
*<tt>SMEXT_CONF_DESCRIPTION</tt> - A short description of what your extension does.
*<tt>SMEXT_CONF_VERSION</tt> - A version number string. By convention, SourceMod uses the four set build number notation. I.e. for 1.2.3.4:
**<tt>1</tt> is the "Major" release version.
**<tt>2</tt> is the "Minor" release version.
**<tt>3</tt> is the "Maintenance" or "Revision" version.
**<tt>4</tt> is the "Build," usually an internal source control number.
*<tt>SMEXT_CONF_AUTHOR</tt> - Your name (or whoever/whatever authored the plugin).
*<tt>SMEXT_CONF_URL</tt> - The URL/homepage of this extension.
*<tt>SMEXT_CONF_LOGTAG</tt> - The logtag your extension will use for SourceMod logging. By convention, try to keep this under ten characters or so, and to make it all caps.
*<tt>SMEXT_CONF_LICENSE</tt> - Right now, the SourceMod Dev Team mandates that 3rd party extensions must be under an Open Source license. Putting a license abbreviation or very short message here is appropriate. For more information, see [[SourceMod License]].
*<tt>SMEXT_CONF_DATESTRING</tt> - You do not need to modify this.
*<tt>SMEXT_CONF_METAMOD</tt> - If your plugin requires using SourceHook or Metamod:Source, uncomment this line.

Next, you may want to change the name of the default class that <tt>extension.h</tt> declares. To do this...
<ul><li>Open <tt>extension.h</tt> and change "Sample" in this line:
<cpp>class Sample : public SDKExtension</cpp></li>
<li>Open <tt>extension.cpp</tt> and change the two lines to correspond to your new class name. You can also change the global singleton that's declared, although you cannot remove the <tt>SMEXT_LINK</tt> line (this lets SourceMod load your extension).</li>
</ul>

==Visual Studio Users==
Make sure you change the name of your <tt>.dll</tt> file. The naming convention for SourceMod extensions is <tt>name.ext.dll</tt>, where <tt>name</tt> is a short name for your extension. You are free to change this, but it is highly recommended that you keep the <tt>.ext.dll</tt> intact.

You can do this by going to <tt>Project</tt> -> <tt>Properties</tt> -> <tt>Configuration Properties</tt> -> <tt>Linker</tt> -> <tt>General</tt>. Set the <tt>Output File</tt> option appropriately.

==Linux Users==
Simply edit the <tt>Makefile</tt> and change the <tt>BINARY</tt> line near the top. Make sure you do not add any trailing spaces at the end of the name, or the build won't come out right.

You should now be able to compile a blank extension!

=Creating Native Functions=
''Main article: [[Natives (SourceMod Development)]]''

Most of the time, an extension exists to add "native functions" to the plugin system. Native functions are simply the functions that plugins can use in SourceMod. They are coded in C++ and have a short prototype declaration in an include file.

==Prototyping==
The first step to creating a native is to <tt>spec it</tt>, or <tt>prototype</tt> it. This is a simple but often time consuming process, but if you get in the habit of it, your documentation will be much better. Let's first create a very simply native. Here is a prototype for it, which we will place in <tt>sample.inc</tt>:
<pawn>/**
* Returns the square of a number.
*
* @param num Number to square.
* @return The square of num.
*/
native SquareNumber(num);</pawn>

The <tt>native</tt> keyword tells the compiler that this function exists in an outside source. The comment style is similar to [http://www.stack.nl/~dimitri/doxygen/ doxygen] or [http://java.sun.com/j2se/javadoc/ Javadoc], and is preferred by the SourceMod Development Team.

==Implementing==
Now that our function is documented, it's time to create it! Each native function is bound to a C++ function. The prototype for this function looks like:
<cpp>cell_t Function(IPluginContext *pContext, const cell_t *params);</cpp>

A quick explanation of these types:
*<tt>cell_t</tt> - This is a 32bit signed integer, the generic data type for Pawn.
*<tt>IPluginContext</tt> - This interface provides Virtual Machine functions for retrieving or modifying memory in the plugin.
*<tt>params</tt> - This is the "stack" of parameters that the plugin passed. It is an array from [0..N] where 0 contains N.
**For example, if one parameter was passed, and the parameter is 25:
***<tt>params[0]</tt> == 1
***<tt>params[1]</tt> == 25
**Even though it tells you how many parameters are passed, you do not need to verify this number. The compiler will always pass the correct number of parameters in. The only time you need to verify it is for backwards compatibility or variable parameter lists, which will be discussed later.

Now, let's write our native function:
<cpp>cell_t SquareNumber(IPluginContext *pContext, const cell_t *params)
{
cell_t number = params[1];
return number * number;
}</cpp>

==Binding==
Now, the final step is to bind our native. Natives are bound in ''native lists''. Each list must be terminated by a <tt>NULL</tt> bind. Example:
<cpp>const sp_nativeinfo_t MyNatives[] =
{
{"SquareNumber", SquareNumber},
{NULL, NULL},
};</cpp>

The first column/member is a string containing the name you've assigned to the native. The second column/member is the C++ function you're binding to. Here, both contain the same name, but it is certainly possible to bind a function to any valid Pawn function name, and likewise, you can bind one function to more than one name.

Lastly, you must tell Core about your native list. There are two places that are good to do this. Whichever you choose, you must uncomment the function in <tt>extension.h</tt> and implement it in <tt>extension.cpp</tt>.
*<tt>SDK_OnLoad</tt> - This is called when your extension is first loaded. If you do not require any outside interfaces, it is safe to add natives here.
*<tt>SDK_OnAllLoaded</tt> - This is called when all extensions have been loaded. This is generally a better place to add natives.

Let's say we choose <tt>SDK_OnAllLoaded</tt>, we'd then have code like this:
<cpp>void Sample::SDK_OnAllLoaded()
{
g_pShareSys->AddNatives(myself, MyNatives);
}</cpp>
''Note: <tt>myself</tt> is a global variable declared in the SDK. It is a pointer that identifies your extension.''

For more information on writing natives, see [[Natives (SourceMod Development)]].

=Creating Events/Forwards=
Events are an integral part to SourceMod. An Event is formally called a ''Forward''. Forwards are functions inside a plugin which are not called by the plugin itself, but are triggered from an external source. For example, <tt>OnClientConnect</tt> is a forward which is triggered when a player connects to a server.

There are two major types of forwards:
*'''Managed''': This forward is global and has a name. To use this forward, the function must be declared as <tt>public</tt> inside the user's script. Any plugin having this public function will receive the event.
*'''Unmanaged''': This forward is private in nature. For example, the <tt>HookUserMessage</tt> native lets users specify a function to be called when a specific user message is sent. This is done with an unmanaged forward, and adding functions to this forward is not automatic. In general, function calls for unmanaged forwards are not public, although they can be.

==Managed Forwards==
Let's say we want to create a forward that will be called when a player uses say chat. For simplicity, let's assume you already have a function that tells you when a player says say chat. We will just be creating the forward for it.

As we did before, first let's prototype our global forward. In our include file, we add this:
<pawn>/**
* @brief Called whenever a client says something in chat.
*
* @param client Index of the client.
* @param text String containing the say text.
* @return Pl_Handled to block text from printing, Pl_Continue otherwise.
*/
forward ResultType:OnPlayerSayChat(client, const String:text[]);</pawn>

The <tt>forward</tt> keyword tells the compiler that any function having this name must be declared exactly the same. In a plugin, this would

The next step is to declare your forward somewhere at the top of your <tt>extension.cpp</tt> file. This will look like:
<cpp>IForward *g_pSayChat = NULL</cpp>

Next, re-using our code from above, let's create this forward in <tt>SDK_OnAllLoaded</tt>:
<cpp>void Sample::SDK_OnAllLoaded()
{
g_pShareSys->AddNatives(myself, MyNatives);
g_pSayChat = g_pForwards->CreateForward(ET_Event, 2, NULL, Param_Cell, Param_String);
}</cpp>

Explanation of parameters:
*<tt>ET_Event</tt> - Since forwards can execute multiple functions in multiple scripts, this is one of the ways of specifying what to do with the return value of each function. <tt>ET_Event</tt> means "return the highest value, do not allow stops." A stop refers to <tt>Pl_Stop</tt>, which lets a plugin block the rest of the event chain.
*<tt>2</tt> - This is the number of parameters our forward will have.
*<tt>NULL</tt> - Not used in our example. This lets you pass parameters by array rather than variable arguments.
*<tt>Param_Cell</tt> - The first parameter is a cell (integer).
*<tt>Param_String</tt> - The second parameter is a string.

Now, we write a quick function in our module to call this forward:
<cpp>/** Fires the say chat event in plugins. Returns true to allow the text, false to block. */
bool FireChatEvent(int client, const char *text)
{
if (!g_pSayChat)
{
return true;
}

cell_t result = 0;
g_pSayChat->PushCell(client);
g_pSayChat->PushString(text);
g_pSayChat->Execute(&result);

if (result == Pl_Handled)
{
return false;
}

return true;
}</cpp>

As you can see, this was pretty simple. Each parameter is "pushed" one at a time, in ascending order. First we push the client index as a cell, then the text as a string. Once done, we execute, and the value will be returned by reference.

Lastly, there is a caveat. Unlike natives, SourceMod does not automatically clean up forwards for us when are done. We have to make sure we destroy them. Uncomment <tt>SDK_OnUnload</tt> from <tt>extension.h</tt> and implement it like so:
<cpp>void Sample::SDK_OnUnload()
{
g_pForwards->ReleaseForward(g_pSayChat);
}</cpp>

==Unmanaged Forwards==
Now things get a bit more complicated. However, unmanaged forwards are essentially the same -- they just give you more flexibility. Let's consider the managed example with a new twist. We want to let users add and remove hooks from their plugins, rather than having one global forward. The standard way to do this is with ''function IDs''.

Example prototype:
<pawn>funcenum SayChatHook
{
forward(client, const String:text[]);
}

native AddSayChatHook(SayChatHook:hook);
native RemoveSayChatHook(SayChatHook:hook);</pawn>

The <tt>funcenum</tt> syntax lets you define all the valid prototypes for your hook. In this example, the only valid method is a function declared like this (only MyHook can be changed):
<pawn>MyHook(client, const String:text[])</pawn>

How do we make such a beast? The first step is setting up our forward.
<cpp>IChangeableForward *g_pSayChat = NULL;
/* ... */
void Sample::SDK_OnAllLoaded()
{
g_pSayChat = g_pForwards->CreateForwardEx(NULL, ET_Hook, 2, NULL, Param_Cell, Param_String);
}</cpp>

Notice two big differences. We now use <tt>IChangeableForward</tt> instead of <tt>IForward</tt>, and we use <tt>CreateForwardEx</tt> instead. The initial first parameter specifies a name for our forward - we're going to ignore this.

Now, we need to create our natives. These will be fairly simple:
<cpp>cell_t AddSayChatHook(IPluginContext *pContext, const cell_t *params)
{
g_pSayChat->AddFunction(pContext, static_cast<funcid_t>(params[1]));
return 1;
}

cell_t RemoveSayChatHook(IPluginContext *pContext, const cell_t *params)
{
IPluginFunction *pFunction = pContext->GetFunctionById(static_cast<funcid_t>(params[1]));
g_pSayChat->RemoveFunction(pFunction);
return 1;
}</cpp>
''Note: These natives must be added -- that step is removed here and explained earlier.''

You do not need to worry about a plugin unloading - Core will automatically remove the functions for you. Since an <tt>IChangeableForward</tt> is also an <tt>IForward</tt>, the <tt>FireChatEvent</tt> function from earlier does not need to change. We're done!

==Creating Interfaces==
Do you want your extension to share an interface? If so, first you should create an ''interface file''. This file should contain everything your interface needs - this way other authors can easily reference it. Your interface must inherit the <tt>SMInterface</tt> class. It must also declare two global macros that uniquely identify your interface. It must also implement two functions: <tt>GetInterfaceName</tt> and <tt>GetInterfaceVersion</tt>.

The two defines must start with <tt>SMINTERFACE_</tt> and end with <tt>_NAME</tt> and <tt>_VERSION</tt> respectively. The first must be a string and the second must be an unsigned integer. This integer represents your interface's version number. While you are free to use it however you please, by default it should be linearly increased. If you make breaking changes or change the versioning scheme, you must overload the <tt>IsVersionCompat</tt> function in <tt>SMInterface</tt>.

Example:
<cpp>#ifndef _INCLUDE_MYINTERFACE_FILE_H_
#define _INCLUDE_MYINTERFACE_FILE_H_

#include <IShareSys.h>

#define SMINTERFACE_MYINTERFACE_NAME "IMyInterface"
#define SMINTERFACE_MYINTERFACE_VERSION 1

class IMyInterface : public SourceMod::SMInterface
{
public:
virtual const char *GetInterfaceName()
{
return SMINTERFACE_MYINTERFACE_NAME;
}
virtual unsigned int GetInterfaceVersion()
{
return SMINTERFACE_MYINTERFACE_VERSION;
}
public:
/**
* @brief This function does nothing.
*/
virtual void DoNothingAtAll() =0;
};

#endif //_INCLUDE_MYINTERFACE_FILE_H_</cpp>

Notice, of course, that our interface is ''pure virtual''. This means it must be implemented in the extension. Assuming you know C++, this should be fairly straight forward, so let's skip right to how to add this interface to the SourceMod shared system:
<cpp>bool Sample::SDK_OnLoad(char *error, size_t err_max, bool late)
{
g_pShareSys->AddInterface(myself, &g_MyInterface);
return true;
}</cpp>
''Note: We do this in <tt>SDK_OnLoad()</tT> instead of <tt>SDK_OnAllLoaded()</tt>. Otherwise, an extension might try to search for your interface during <tt>SDK_OnAllLoaded()</tt>, and it might fail depending on the load order.''

That simple? Yup! Now other extensions can use your interface.

=Using Interfaces/Other Extensions=
There are a variety of interfaces that are available, but not loaded by default in the Extension SDK. These interfaces can be retrieved and used in your extension.

==Core Interfaces==
If they are provided by Core, getting them is very simple. Most of the <tt>.h</tt> interface files in the root of the <tt>public</tt> folder in the SDK are Core interfaces. For example, code to use the IPluginManager interface might look like this:
<cpp>#include <IPluginSys.h>

IPluginManager *g_pPlugins = NULL;

bool Sample::SDK_OnLoad(char *error, size_t err_max, bool late)
{
SM_GET_IFACE(PLUGINSYSTEM, g_pPlugins);
return true;
}</cpp>

Where did we get <tt>PLUGINSYSTEM</tt> from? Observe the two lines in <tt>IPluginSys.h</tt>:
<cpp>#define SMINTERFACE_PLUGINSYSTEM_NAME "IPluginManager"
#define SMINTERFACE_PLUGINSYSTEM_VERSION 1</cpp>

The <tt>SM_GET_IFACE</tt> macro uses the text in between the <tt>SMINTERFACE_</tt> and the <tt>_NAME</tt> characters. It also uses the version for compatibility checking. If it can't find the interface, it automatically prints to the error buffer and returns false.

===Default Interfaces===
There are interfaces which are grabbed by the Extension SDK by default. You do not need to query for them on load, or even check if they are valid or not. They are:
*<tt>IShareSys</tt> - Exposed as <tt>g_pShareSys</tt>, found in <tt>IShareSys.h</tt>
*<tt>HANDLESYSTEM</tt> - Exposed as <tt>g_pHandleSys</tt>, found in <tt>IHandleSys.h</tt>
*<tt>SOURCEMOD</tt> - Exposed as <tt>g_pSM</tt>, found in <tt>ISourceMod.h</tt>
*<tt>FORWARDMANAGER</tt> - Exposed as <tt>g_pForwards</tt>, found in <tt>IForwardSys.h</tt>

==External Interfaces==
The situation changes if your extension requires ''another extension'', since extensions may load in a completely random order. The first step is to mark the other extension as a dependency. Let's say you want to use the <tt>IThreader.h</tt> interfaces from <tt>threader.ext.dll</tt>. First, we declare it as such:

<cpp>bool Sample::SDK_OnLoad(char *error, size_t err_max, bool late)
{
g_pShareSys->AddDependency(myself, "thread.ext", true, true);
return true;
}</cpp>

The two boolean parameters to <tt>AddDependency</tt> mean, respectively: "try to automatically load this extension" and "this extension cannot work without the dependency."

Second, we query for the interface in <tt>SDK_OnAllLoaded</tt>. Since we don't know when <tt>thread.ext</tt> will actually be loaded, we have to wait until everything is definitely loaded.
<cpp>IThreader *g_pThreader = NULL;
/* ... */
void Sample::SDK_OnAllLoaded()
{
SM_GET_LATE_IFACE(THREADER, g_pThreader);
}</cpp>

Third, we need to find a way to fail if this interface was never found. The way to do this is by uncommenting <tt>QueryRunning</tt> from <tt>extension.h</tt> and implementing it:
<cpp>bool Sample::QueryRunning(char *error, size_t err_max)
{
SM_CHECK_IFACE(THREADER, g_pThreader);
return true;
}</cpp>

When SourceMod queries your extension, the macro above will either validate the pointer or return false. If it returns false, SourceMod marks your extension as failed.

==Caveats==
===NULL Interfaces===
There are a few ways that external interfaces can make your code complicated. The first is simple but a common oversight. Don't assume interfaces will be okay. For example, say we want to create a thread once we get the <tt>IThreader</tt> interface. Our code should something like this:

<cpp>void Sample::SDK_OnAllLoaded()
{
SM_GET_IFACE(THREADER, g_pThreader);

if (QueryRunning(NULL, 0))
{
g_pThreader->MakeThread(/* stuff */);
}
}</cpp>

Note that we ''query ourself'' in order to find if it's safe to continue executing code. We could also have simply checked if <tt>g_pThreader</tt> is <tt>NULL</tt>, but self-querying has a bonus: if your extension continues to do things like hook events or add listeners, you will be preventing your extension from entirely initializing itself while one interface is bad. Always make sure you have sanity checks like this where needed.

===Dynamic Unloading===
The second major caveat is that extensions can be dynamically unloaded. If you specified yourself as having a dependency and that each dependency is required, you will have no problem. Your extension will be unloaded before the interface is removed, and you can clean up memory/hooks in your <tt>SDK_OnUnload()</tt> code. There are two situations where this is a different story.

====Optional Interfaces====
The first situation is if you are not requiring an extension that contains an interface. Now, when the extension unloads, your extension will not be unloaded first. This creates a small problem, as you must clean up without being unloaded. There are two functions you can implement in your extension class to resolve this, both documented in <tt>IExtensionSys.h</tt>:
*<tt>QueryInterfaceDrop</tt> - Allows you to request unloading when a specific interface is unloaded. This is the default behavior for all interfaces. If you want to block this functionality, continue reading.
*<tt>NotifyInterfaceDrop</tt> - This is called when an interface is dropped. If your plugin will not be unloaded, you can use this to clean up any resources on a specific interface being removed.

====Circular Dependencies====
The second situation is a bit more complicated. It is possible for two extensions to have circular dependencies. For example:
*Extension "A" requires extension "B."
*Extension "B" requires extension "A."

If either extension is unloaded, the opposite extension is unloaded normally. The first extension then receives the interface drop callbacks. In this situation, it is essential that the <tt>NotifyInterfaceDrop</tt> function be implemented and used with the circular interface. Otherwise, you risk crashing when your extension unloads (or at the very least, leaking memory). Since the actual drop order is undefined, it means both extensions must implement this function to be safe.

=Automatic Loading=
There are two types of automatic loading: Dynamic and Global. Dynamic loading means your extension is only loaded when a plugin requires it. Global loading means your extension loads no matter what.

==Dynamic Autoloading==
Dynamic loading requires that you create an include file for plugins. Plugins that include your file will automatically load your extension. This requires implementing the <tt>Extension</tt> structure found in <tt>core.inc</tt>. You must expose the structure as <tt>public</tt>, and the name must start with "<tt>__ext_</tt>".

<pawn>/**
* Do not edit below this line!
*/
public Extension:__ext_geoip =
{
name = "GeoIP",
file = "geoip.ext",
#if defined AUTOLOAD_EXTENSIONS
autoload = 1,
#else
autoload = 0,
#endif
#if defined REQUIRE_EXTENSIONS
required = 1,
#else
required = 0,
#endif
};
</pawn>

Explanations:
*name: The name of your module as written in <tt>SMEXT_CONF_NAME</tt>.
*file: The platform-inspecific portion of your extension's file name.
*autoload: Specifies that your module should always dynamically autoload by default. You can tweak this to either never autoload or always autoload (without letting the user toggle).
*required: Specifies whether or not this extension is '''required''' by your plugin. If for some reason your extension fails to load (or is not found), the plugin will also fail to load. This is changeable if you wish to override the default behavior.

You can copy and paste this example, but remember to modify the following portions:
*__ext_geoip: Change the "geoip" portion to your own unique variable name.
*"GeoIP: Change the GeoIP portion to your extension's name. This should match the name you chose as <tt>SMEXT_CONF_NAME</tt>.
*"geoip.ext": Change this to your extension's file name, without the .dll/.so portion.

==Global Autoloading==
To have your extension always autoload, you must create a ''.autoload'' file in the <tt>extensions</tt> folder. For example, to have the <tt>threader.ext.dll</tt> or <tt>threader.ext.so</tt> extensions autoload, you'd create the following file in <tt>extensions</tt>: <tt>threader.autoload</tt>.

A few notes:
*This only works for extensions using the .ext.<platform> convention. SourceMod cuts off the ".autoload" portion of the file, then adds on ".ext.dll" or ".ext.so" which will not work on custom files.
*The file does not need to contain anything, it simply needs to exist.

=Conventions=

==Designing API/Natives==
*Start interface names with the capital letter 'I'.
*Use a consistent naming convention. SourceMod uses [http://msdn2.microsoft.com/en-us/library/ms229002.aspx Microsoft/Pascal] naming. Avoid Java/Camel casing for both API and natives.
*When exposing interfaces, make sure your exposure defines start with <tt>SMINTERFACE_</tt> and end with <tt>_NAME</tt> and <tt>_VERSION</tt>

==External Naming==
*Logtags (<tt>SMEXT_CONF_LOGTAG</tt>) should be short names (under 10 characters or so) in all capital letters.
*Your extension file name should never have <tt>_i486</tt> or other unnecessary platform-specific notations in its name.
*Your extension file name should always end in <tt>.ext.so</tt> or <tt>.ext.dll</tt> depending on the platform. The <tt>.ext.</tt> is SourceMod convention.

=Setting up Visual Studio=
==Paths==
'''Visual Studio 2003''': Tools -> Options -> Projects, VC++ Directories

'''Visual Studio 2005''': Tools -> Options -> Projects and Solutions -> VC++ Directories

===Include Paths===
*SourceMod only:
**sdk\public\extensions
**sdk\public\sourcepawn
**sdk\public
*SourceMM (Note that sourcemm might be 'trunk' for you):
**sourcemm\sourcemm
**sourcemm\sourcehook
**sourcemm
*HL2SDK:
**game_shared
**public\vstdlib
**public\tier1
**public\tier0
**public\engine
**public\dlls
**public
**dlls

===Link Paths===
*HL2SDK:
**lib\public for version 2005
**lib-vc7\public for version 2003

==Compiler Options==
Note: These options are set by default in the sample Extension SDK. 
Note: These options should be set for every build (Release/Debug/others).

*General
**<tt>Character Set</tt>: '''Use Multi-Byte Character Set'''
*C/C++
**General
***<tt>Detect 64-bit Portability Issues</tt>: '''No'''
**Preprocessor
***<tt>Preprocessor Defines</tt>: Add <tt>_CRT_SECURE_NO_DEPRECATE</tt> and <tt>_CRT_NONSTDC_NO_DEPRECATE</tt> and <tt>SOURCEMOD_BUILD</tt>
**Code Generation
***<tt>Runtime Library</tt>: Multi-threaded or /MT (for Release), Multi-threaded Debug or /MTd (for Debug)
*Linker
**General
***<tt>Output File</tt>: Change <tt>$(ProjectName)</tt> to <tt>$(ProjectName).ext</tt>, or use your own custom string.
**Input
***<tt>Additional Dependencies</tt>: <tt>tier0.lib tier1.lib vstdlib.lib</tt> (for SourceMM attached extensions only)

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

Commands (SourceMod Scripting)

2007-04-01T00:27:07Z

Teame06: /* Client-Only Commands */

[[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 remove 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 hot dogs
*Argument count: 4
*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 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.

[[Category:SourceMod Development]]

Commands (SourceMod Scripting)

2007-03-20T05:32:29Z

Teame06:

[[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 remove 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 hot dogs
*Argument count: 4
*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 OnClientCommand(client, args)
{
new String:cmd[16]
GetCmdArg(0, cmd, sizeof(16)); /* 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.

[[Category:SourceMod Development]]

Half-Life 1 Game Events

2006-03-18T05:14:17Z

Teame06: /* Half-Life Events */

[[Category:Half-Life 1]]
[[Category:Scripting (AMX Mod X)]]
= Half-Life Events =
Description here

== ADStop ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ADStop}}
{{end-hl1msg}}

== AllowSpec ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|AllowSpec}}
{{end-hl1msg}}

== AmmoPickup ==
Temporary draws ammo amount and ammo type HUD icons in the middle of the right side of the screen (draw time depends on ''hud_drawhistory_time'' client CVAR value)
{{begin-hl1msg|AmmoPickup|byte, byte}}
{{hl1msg|byte|Ammo ID}}
{{hl1msg|byte|Ammount}}
{{end-hl1msg}}

== AmmoX ==
Updates green bar indicator in weapon HUD-list and ammo amount in lower right corner of the screen (in case current weapon uses given ammo type)
{{begin-hl1msg|AmmoX|byte, byte}}
{{hl1msg|byte|Ammo ID}}
{{hl1msg|byte|Ammount}}
{{end-hl1msg}}

== BarTime ==
Leave the 2nd byte as 0, to turn off a BarTime that you started just send a duration of 0.
{{begin-hl1msg|BarTime|byte, byte}}
{{hl1msg|byte|Duration}}
{{hl1msg|byte|Unknown}}
{{end-hl1msg}}

== BarTime2 ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BarTime2}}
{{end-hl1msg}}

== Battery ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Battery|short}}
{{hl1msg|byte|Armor}}
{{end-hl1msg}}

== BlinkAcct ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BlinkAcct}}
{{end-hl1msg}}

== BombDrop ==
The first three arguments are the origin of the dropped bomb. The last argument is set to 1 if the bomb has been planted. It is 0 if the bomb was dropped due to voluntary dropping or death. Setting the last argument 1, will also trigger the round timer to hide. It also will show the dropped bomb on the Terrorist team's radar in the location specified by the first three arguments.
{{begin-hl1msg|BombDrop|coord, coord, coord, byte}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{hl1msg|byte|Domb Droped?}}
{{end-hl1msg}}

== BombPickup ==
This message just tells the game that the bomb has been picked up. It will cause the dropped bomb to disappear from the Terrorist team's radar.
{{begin-hl1msg|BombPickup}}
{{end-hl1msg}}

== BotProgress ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BotProgress}}
{{end-hl1msg}}

== BotVoice ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BotVoice|byte, byte}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== Brass ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Brass}}
{{end-hl1msg}}

== BuyClose ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BuyClose}}
{{end-hl1msg}}

== ClCorpse ==
The model name does not have .mdl at the end
{{begin-hl1msg|ClCorpse|string, long, long, long, coord, coord, coord, long, byte, byte, byte, byte}}
{{hl1msg|string|model}}
{{hl1msg|long|unknown}}
{{hl1msg|long|unknown}}
{{hl1msg|long|unknown}}
{{hl1msg|coord|unknown}}
{{hl1msg|coord|unknown}}
{{hl1msg|coord|unknown}}
{{hl1msg|long|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== Crosshair ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Crosshair|byte}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== CurWeapon ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|CurWeapon|byte, byte, byte}}
{{hl1msg|byte|isActive}}
{{hl1msg|byte|WeaponID}}
{{hl1msg|byte|Ammo in weapon}}
{{end-hl1msg}}

== CZCareer ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|CZCareer}}
{{end-hl1msg}}

== CZCareerHUD ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|CZCareerHUD}}
{{end-hl1msg}}

== Damage ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Damage|byte, byte, long, coord, coord, coord}}
{{hl1msg|byte|Damage save (armor)}}
{{hl1msg|byte|Damage take (health)}}
{{hl1msg|long|Damage type}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{end-hl1msg}}

== DeathMsg ==
Fired to all players (MSG_ALL or MSG_BROADCAST) to notify them of a death.
This generates the [[HUD]] message the client sees in the upper right corner of their screen.

{{begin-hl1msg|DeathMsg|byte, byte, byte, string}}
{{hl1msg|byte|killer}}
{{hl1msg|byte|victim}}
{{hl1msg|byte|headshot}}
{{hl1msg|string|weapon}}
{{end-hl1msg}}

== FlashBat ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|FlashBat|byte}}
{{hl1msg|byte|Amount}}
{{end-hl1msg}}

== Flashlight ==
Flag would be 1 for turning the flashlight on or 0 for turning it off. In my testing the 2nd argument was always 100.
{{begin-hl1msg|Flashlight|byte, byte}}
{{hl1msg|byte|Flag}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== Fog ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Fog}}
{{end-hl1msg}}

== ForceCam ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ForceCam}}
{{end-hl1msg}}

== HostageK ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|HostageK}}
{{hl1msg|Byte|unknown}}
{{end-hl1msg}}

== HostagePos ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|HostagePos}}
{{hl1msg|Byte|unknown}}
{{hl1msg|Byte|unknown}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{end-hl1msg}}

== NVGToggle ==
{{qnotice| 1 is on, 2 is off}}
{{begin-hl1msg|NVGToggle}}
{{hl1msg|byte|flag}}
{{end-hl1msg}}

== ResetHUD ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ResetHUD}}
{{end-hl1msg}}

== RoundTime ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|RoundTime}}
{{hl1msg|short|Time in Seconds}}
{{end-hl1msg}}

== SayText ==
{{qnotice| The destination can be 1 is notify, 2 is console, 3 is chat, or 4 is center. Some values of the predifined string: #Cstrike_Chat_AllDead, #Cstrike_Chat_All}}
{{begin-hl1msg|SayText}}
{{hl1msg|byte|Destination}}
{{hl1msg|string|Predefined String}}
{{hl1msg|string|Unknown}}
{{hl1msg|string|Text said}}
{{end-hl1msg}}

== Scenario ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Scenario}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== ScoreAttrib ==
{{qnotice|For the 2nd Argument, 0 is nothing, 1 is dead, 2 is bomb, 3 is VIP}}
{{begin-hl1msg|ScoreAttrib}}
{{hl1msg|byte|Id}}
{{hl1msg|byte|Flag}}
{{end-hl1msg}}

== StatusIcon ==
{{qnotice|For Status, 0 is Hide Icon, 1 is Show Icon, 2 is Flash Icon. A list of usable sprites are in listed at a link below: [Link is missing]}}
{{begin-hl1msg|StatusIcon}}
{{hl1msg|byte|Status}}
{{hl1msg|string|Sprite name}}
{{hl1msg|byte|Red}}
{{hl1msg|byte|Green}}
{{hl1msg|byte|Blue}}
{{end-hl1msg}}

== StatusText ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ScoreAttrib}}
{{hl1msg|byte|Line Number}}
{{hl1msg|string|Text}}
{{end-hl1msg}}

== StatusValue ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|StatusValue}}
{{hl1msg|byte|}}
{{hl1msg|short|Predefined String}}
{{hl1msg|short|Unknown}}
{{hl1msg|short|Unknown}}
{{hl1msg|short|Unknown}}
{{end-hl1msg}}

== TaskTime ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TaskTime}}
{{end-hl1msg}}

== TeamInfo ==
{{qnotice|Team name is either CT or TERRORIST}}
{{begin-hl1msg|TeamInfo}}
{{hl1msg|byte|ID}}
{{hl1msg|string|Team Name}}
{{end-hl1msg}}

== TeamScore ==
{{qnotice|Team name is either CT or TERRORIST}}
{{begin-hl1msg|TeamScore}}
{{hl1msg|string|Team Name}}
{{hl1msg|short|Score}}
{{end-hl1msg}}

== TextMsg ==
{{qnotice|There does not necessarily have to be a total of 6 arguments, there could be as little as 2. For example you can send a message with the following: 
Arg1: 1 
Arg2: #Game_join_ct 
Arg3: 4HM | Pimp Daddy }}
{{begin-hl1msg|TextMsg}}
{{hl1msg|byte|ID}}
{{hl1msg|string|Message}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{end-hl1msg}}

== Train ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Train}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== TutorClose ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorClose}}
{{end-hl1msg}}

== TutorLine ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorLine}}
{{end-hl1msg}}

== TutorState ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorState}}
{{end-hl1msg}}

== TutorText ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorText}}
{{end-hl1msg}}

== VGUIMenu ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|VGUIMenu}}
{{hl1msg|byte|unknown}}
{{hl1msg|short|unknown}}
{{hl1msg|char|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|string|unknown}}
{{end-hl1msg}}

== ViewMode ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ViewMode}}
{{end-hl1msg}}

== VoiceMask ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|VoiceMask}}
{{hl1msg|long|unknown}}
{{hl1msg|long|unknown}}
{{end-hl1msg}}

== WeapPickup ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|WeapPickup}}
{{hl1msg|byte|Weapon ID}}
{{end-hl1msg}}

Half-Life 1 Game Events

2006-03-18T04:21:37Z

Teame06: /* Half-Life Events */

[[Category:Half-Life 1]]
[[Category:Scripting (AMX Mod X)]]
= Half-Life Events =
Description here

== ADStop ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ADStop}}
{{end-hl1msg}}

== AllowSpec ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|AllowSpec}}
{{end-hl1msg}}

== AmmoPickup ==
Temporary draws ammo amount and ammo type HUD icons in the middle of the right side of the screen (draw time depends on ''hud_drawhistory_time'' client CVAR value)
{{begin-hl1msg|AmmoPickup|byte, byte}}
{{hl1msg|byte|Ammo ID}}
{{hl1msg|byte|Ammount}}
{{end-hl1msg}}

== AmmoX ==
Updates green bar indicator in weapon HUD-list and ammo amount in lower right corner of the screen (in case current weapon uses given ammo type)
{{begin-hl1msg|AmmoX|byte, byte}}
{{hl1msg|byte|Ammo ID}}
{{hl1msg|byte|Ammount}}
{{end-hl1msg}}

== BarTime ==
Leave the 2nd byte as 0, to turn off a BarTime that you started just send a duration of 0.
{{begin-hl1msg|BarTime|byte, byte}}
{{hl1msg|byte|Duration}}
{{hl1msg|byte|Unknown}}
{{end-hl1msg}}

== BarTime2 ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BarTime2}}
{{end-hl1msg}}

== Battery ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Battery|short}}
{{hl1msg|byte|Armor}}
{{end-hl1msg}}

== BlinkAcct ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BlinkAcct}}
{{end-hl1msg}}

== BombDrop ==
The first three arguments are the origin of the dropped bomb. The last argument is set to 1 if the bomb has been planted. It is 0 if the bomb was dropped due to voluntary dropping or death. Setting the last argument 1, will also trigger the round timer to hide. It also will show the dropped bomb on the Terrorist team's radar in the location specified by the first three arguments.
{{begin-hl1msg|BombDrop|coord, coord, coord, byte}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{hl1msg|byte|Domb Droped?}}
{{end-hl1msg}}

== BombPickup ==
This message just tells the game that the bomb has been picked up. It will cause the dropped bomb to disappear from the Terrorist team's radar.
{{begin-hl1msg|BombPickup}}
{{end-hl1msg}}

== BotProgress ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BotProgress}}
{{end-hl1msg}}

== BotVoice ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BotVoice|byte, byte}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== Brass ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Brass}}
{{end-hl1msg}}

== BuyClose ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BuyClose}}
{{end-hl1msg}}

== ClCorpse ==
The model name does not have .mdl at the end
{{begin-hl1msg|ClCorpse|string, long, long, long, coord, coord, coord, long, byte, byte, byte, byte}}
{{hl1msg|string|model}}
{{hl1msg|long|unknown}}
{{hl1msg|long|unknown}}
{{hl1msg|long|unknown}}
{{hl1msg|coord|unknown}}
{{hl1msg|coord|unknown}}
{{hl1msg|coord|unknown}}
{{hl1msg|long|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== Crosshair ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Crosshair|byte}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== CurWeapon ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|CurWeapon|byte, byte, byte}}
{{hl1msg|byte|isActive}}
{{hl1msg|byte|WeaponID}}
{{hl1msg|byte|Ammo in weapon}}
{{end-hl1msg}}

== CZCareer ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|CZCareer}}
{{end-hl1msg}}

== CZCareerHUD ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|CZCareerHUD}}
{{end-hl1msg}}

== Damage ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Damage|byte, byte, long, coord, coord, coord}}
{{hl1msg|byte|Damage save (armor)}}
{{hl1msg|byte|Damage take (health)}}
{{hl1msg|long|Damage type}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{end-hl1msg}}

== DeathMsg ==
Fired to all players (MSG_ALL or MSG_BROADCAST) to notify them of a death.
This generates the [[HUD]] message the client sees in the upper right corner of their screen.

{{begin-hl1msg|DeathMsg|byte, byte, byte, string}}
{{hl1msg|byte|killer}}
{{hl1msg|byte|victim}}
{{hl1msg|byte|headshot}}
{{hl1msg|string|weapon}}
{{end-hl1msg}}

== FlashBat ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|FlashBat|byte}}
{{hl1msg|byte|Amount}}
{{end-hl1msg}}

== Flashlight ==
Flag would be 1 for turning the flashlight on or 0 for turning it off. In my testing the 2nd argument was always 100.
{{begin-hl1msg|Flashlight|byte, byte}}
{{hl1msg|byte|Flag}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== Fog ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Fog}}
{{end-hl1msg}}

== ForceCam ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ForceCam}}
{{end-hl1msg}}

== HostageK ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|HostageK}}
{{hl1msg|Byte|unknown}}
{{end-hl1msg}}

== HostagePos ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|HostagePos}}
{{hl1msg|Byte|unknown}}
{{hl1msg|Byte|unknown}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{end-hl1msg}}

== NVGToggle ==
{{qnotice| 1 is on, 2 is off}}
{{begin-hl1msg|NVGToggle}}
{{hl1msg|byte|flag}}
{{end-hl1msg}}

== ResetHUD ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ResetHUD}}
{{end-hl1msg}}

== RoundTime ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|RoundTime}}
{{hl1msg|short|Time in Seconds}}
{{end-hl1msg}}

== SayText ==
{{qnotice| The destination can be 1 is notify, 2 is console, 3 is chat, or 4 is center. Some values of the predifined string: #Cstrike_Chat_AllDead, #Cstrike_Chat_All}}
{{begin-hl1msg|SayText}}
{{hl1msg|byte|Destination}}
{{hl1msg|string|Predefined String}}
{{hl1msg|string|Unknown}}
{{hl1msg|string|Text said}}
{{end-hl1msg}}

== Scenario ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Scenario}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== ScoreAttrib ==
{{qnotice|For the 2nd Argument, 0 is nothing, 1 is dead, 2 is bomb, 3 is VIP}}
{{begin-hl1msg|ScoreAttrib}}
{{hl1msg|byte|Id}}
{{hl1msg|byte|Flag}}
{{end-hl1msg}}
StatusValue byte, short, short, short, short
== TaskTime ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TaskTime}}
{{end-hl1msg}}

== TeamInfo ==
{{qnotice|Team name is either CT or TERRORIST}}
{{begin-hl1msg|TeamInfo}}
{{hl1msg|byte|ID}}
{{hl1msg|string|Team Name}}
{{end-hl1msg}}

== TeamScore ==
{{qnotice|Team name is either CT or TERRORIST}}
{{begin-hl1msg|TeamScore}}
{{hl1msg|string|Team Name}}
{{hl1msg|short|Score}}
{{end-hl1msg}}

== TextMsg ==
{{qnotice|There does not necessarily have to be a total of 6 arguments, there could be as little as 2. For example you can send a message with the following: 
Arg1: 1 
Arg2: #Game_join_ct 
Arg3: 4HM | Pimp Daddy }}
{{begin-hl1msg|TextMsg}}
{{hl1msg|byte|ID}}
{{hl1msg|string|Message}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{end-hl1msg}}

== Train ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Train}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== TutorClose ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorClose}}
{{end-hl1msg}}

== TutorLine ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorLine}}
{{end-hl1msg}}

== TutorState ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorState}}
{{end-hl1msg}}

== TutorText ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorText}}
{{end-hl1msg}}

== VGUIMenu ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|VGUIMenu}}
{{hl1msg|byte|unknown}}
{{hl1msg|short|unknown}}
{{hl1msg|char|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|string|unknown}}
{{end-hl1msg}}

== ViewMode ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ViewMode}}
{{end-hl1msg}}

== VoiceMask ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|VoiceMask}}
{{hl1msg|long|unknown}}
{{hl1msg|long|unknown}}
{{end-hl1msg}}

== WeapPickup ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|WeapPickup}}
{{hl1msg|byte|Weapon ID}}
{{end-hl1msg}}

Half-Life 1 Game Events

2006-03-17T10:55:31Z

Teame06: /* Half-Life Events */

Half-Life 1 Game Events

2006-03-17T10:53:40Z

Teame06: /* Half-Life Events */

Half-Life 1 Game Events

2006-03-17T10:51:30Z

Teame06: /* SayText */

Half-Life 1 Game Events

2006-03-17T10:50:23Z

Teame06: /* NVGToggle */

Half-Life 1 Game Events

2006-03-17T10:32:35Z

Teame06: