AlliedModders Wiki - User contributions [en]

KeyValues (SourceMod Scripting)

2015-12-05T23:51:52Z

Dr. Greg House: Added a small annotation in order to try to prevent wrong usage scenarios of keyvalues (i.e. for player stats), as threads have been appearing continuously over the years. Stop the madness! ToDo: Maybe a pro-con section or a better example?

KeyValues are simple, tree-based structures used for storing nested sections containing key/value pairs. Detailed information on KeyValues can be seen at the [http://developer.valvesoftware.com/wiki/KeyValues_class Valve Developer Wiki].

All KeyValues specific functions in this document are from <tt>public/include/keyvalues.inc</tt>.

''Note: While the following examples are correct code-wise, over the years they have occasionally led people to use KeyValues in cases where they really should be using a [https://wiki.alliedmods.net/SQL_%28SourceMod_Scripting%29 database] instead.''

=Introduction=
KeyValues consist of a ''nodes'', or ''sections'', which contain pairs of keys and values. A section looks like this:
<pre>"section"
{
"key" "value"
}</pre>

The <tt>"section"</tt> string denotes the section's name. The <tt>"key"</tt> string is the key name, and the <tt>"value"</tt>" string is the value.

KeyValues structures are created with <tt>CreateKeyValues()</tt>. The Handle must be freed when finished in order to avoid a memory leak.

=Files=
KeyValues can be exported and imported via KeyValues files. These files always consist of a root node and any number of sub-keys or sub-sections. For example, a file might look like this:
<pre>"MyFile"
{
"STEAM_0:0:7"
{
"name" "crab"
}
}</pre>

In this example, <tt>STEAM_0:0:7</tt> is a section under <tt>MyFile</tt>, the root node.

To load KeyValues from a file, use <tt>FileToKeyValues</tt> To save KeyValues to a file, use <tt>KeyValuesToFile</tt>. For both cases, you must already have a Handle to a KeyValues structure.

=Traversal=
SourceMod provides natives for traversing over a KeyValues structure. However, it is important to understand how this traversal works. Internally, SourceMod keeps track of two pieces of information:
*The root node
*A traversal stack

Since a KeyValues structure is inherently recursive (it's a tree), the ''traversal stack'' is used to save a history of each ''traversal'' made (a traversal being a recursive dive into the tree, where the current nesting level deepens by one section). The ''top'' of this stack is where all operations take place.

For example, <tt>kv.JumpToKey</tt> will attempt to find a sub-key under the current section. If it succeeds, the position in the tree has changed by moving down one level, and thus this position is pushed onto the traversal stack. Now, operations such as <tt>kv.GetString</tt> will use this new position.

There are natives which change the position but do not change the traversal stack. For example, <tt>kv.GotoNextKey</tt> will change the current section being viewed, but there are no push/pop operations to the traversal stack. This is because the nesting level did not change; it advances to the next section at the same level, rather than finding a section a level deeper.

More traversal natives:
*<tt>kv.GotoFirstSubKey</tt> - Finds the first sub-section under the current section. This pushes the section onto the traversal stack.
*<tt>kv.GoBack</tt> - Pops the traversal stack (moves up one level).
*<tt>kv.Rewind</tt> - Clears the traversal stack so the current position is the root node.

==Basic Lookup==
Let's take our <tt>MyFile</tt> example from above. How could we retrieve the name "crab" given the Steam ID?

<pawn>bool GetNameFromSteamID(const char[] steamid, char[] name, int maxlength)
{
KeyValues kv = new KeyValues("MyFile");
kv.ImportFromFile("myfile.txt");
if (!kv.JumpToKey(steamid))
{
return false;
}
kv.GetString("name", name, maxlength);
delete kv;
return true;
}</pawn>

'''Note:''' <tt>kv.JumpToKey</tt> is a traversal native that changes the nesting level of the traversal stack. However, <tt>delete</tt> will not accidentally close only the current level of the KeyValues structure. It will close the entire thing.

==Iterative Lookup==
Let's modify our previous example to use iteration. This has the same functionality, but demonstrates how to browse over many sections.

<pawn>bool GetNameFromSteamID(const char[] steamid, char[] name,int maxlength)
{
KeyValues kv = new KeyValues("MyFile");
kv.ImportFromFile("myfile.txt");

if (!kv.GotoFirstSubKey())
{
return false;
}

char buffer[255];
do
{
kv.GetSectionName(buffer, sizeof(buffer));
if (StrEqual(buffer, steamid))
{
kv.GetString("name", name, maxlength);
delete kv;
return true;
}
} while (kv.GotoNextKey());

delete kv;
return false;
}</pawn>

'''Note:''' In this example, note that <tt>kv.GotoNextKey</tt> is an iterative function, not a traversal one. Since it does not change the nesting level, we don't need to call <tt>kv.GoBack</tt> to return and continue iterating.

==Full Traversal==
Let's say we wanted to browse every section of a KeyValues file. An example of this might look like:
<pawn>BrowseKeyValues(KeyValues kv)
{
do
{
// You can read the section/key name by using KvGetSectionName here.

if (kv.GotoFirstSubKey(false))
{
// Current key is a section. Browse it recursively.
BrowseKeyValues(kv);
kv.GoBack(kv);
}
else
{
// Current key is a regular key, or an empty section.
if (kv.GetDataType(NULL_STRING) != KvData_None)
{
// Read value of key here (use NULL_STRING as key name). You can
// also get the key name by using kv.GetSectionName here.
}
else
{
// Found an empty sub section. It can be handled here if necessary.
}
}
} while (kv.GotoNextKey(false));
}</pawn>

This function will browse an entire KeyValues structure. Note that every successful call to <tt>kv.GotoFirstSubKey</tt> is paired with a call to <tt>kv.GoBack</tt>. This is because the former pushes onto the traversal stack. We must pop the position off so we can continue browsing from our old position.

Also note that <tt>keyOnly</tt> is set to false in both <tt>kv.GotoFirstSubKey</tt> and <tt>kv.GotoNextKey</tt> so that it will jump to regular keys and not just between sections. Because of this we also need to check if <tt>kv.GotoFirstSubKey</tt> succeeded moving to a regular key before we read the value. This is simply done by getting the data type of the current key. If <tt>kv.GotoFirstSubKey</tt> failed to move to any key (the section is empty), the cursor is still on the section, which doesn't have a data type. If there is a data type, we've confirmed that it's a regular key.

=Deletion=
There are two ways to delete sections from a KeyValues structure:
*<tt>kv.DeleteKey</tt> - Safely removes a named sub-section and any of its child sections/keys.
*<tt>kv.DeleteThis</tt> - Safely removes the current position if possible.

==Simple Deletion==
First, let's use our "basic lookup" example to delete a Steam ID section:
<pawn>
RemoveSteamID(const char[] steamid)
{
KeyValues kv = new KeyValues("MyFile");
kv.ImportFromFile("myfile.txt");
if (!kv.JumpToKey(steamid))
{
return;
}
kv.DeleteThis();
kv.Rewind();
kv.ExportToFile("myfile.txt");
delete kv;
}
</pawn>

'''Note:''' We called <tt>kv.Rewind</tt> so the file would be dumped from the root position, instead of the current one.

==Iterative Deletion==
Likewise, let's show how our earlier iterative example could be adapted for deleting a section. For this we can use <tt>kv.DeleteThis</tt>, which deletes the current position from the previous position in the traversal stack.

<pawn>RemoveSteamID(const char[] steamid)
{
KeyValues kv = new KeyValues("MyFile");
kv.ImportFromFile("myfile.txt");
if (!kv.JumpToKey(steamid))
{
return;
}

char buffer[255];
do
{
kv.GetSectionName(buffer, sizeof(buffer))
if (StrEqual(buffer, steamid))
{
kv.DeleteThis();
delete kv;
return;
}
} while (kv.GotoNextKey());

delete kv;
}</pawn>

==Full Deletion==
Now, let's take a look at how we would delete all (or some) keys. <tt>kv.DeleteThis</tt> has the special property that it can act as an automatic iterator. When it deletes a key, it automatically attempts to advance to the next one, as <tt>kv.GotoNextKey</tt> would. If it can't find any more keys, it simply pops the traversal stack.

An example of deleting all SteamIDs that have blank names:
<pawn>DeleteAll(KeyValues kv)
{
if (!kv.GotoFirstSubKey())
{
return;
}

for (;;)
{
char name[4];
kv.GetString(name, sizeof(name));
if (name[0] == '\0')
{
if (kv.DeleteThis() < 1)
{
break;
}
} else if (!kv.GotoNextKey()) {
break;
}
}
}</pawn>

While at first this loop looks infinite, it is not. If <tt>kv.DeleteThis</tt> fails to find a subsequent key, it will break out of the loop. Similarly, if <tt>kv.GotoNextKey</tt> fails, the loop will end.

==KeyValue Creation==
This is how you would create the <tt>MyFile</tt> example from above with the KeyValue API
<pawn>KeyValues kv = new KeyValues("MyFile");
kv.JumpToKey("STEAM_0:0:7", true);
kv.SetString("name", "crab");
kv.Rewind();
kv.ExportToFile("C:\javalia.txt");
delete kv;</pawn>

[[Category:SourceMod Scripting]]
{{LanguageSwitch}}

CSGO Quirks

2015-05-09T14:49:16Z

Dr. Greg House: Elaborating on what will happen if you dare to use fancy wavs.

''Others are encouraged to expand on this article with their findings or to clarify any information''

This article explains some of the quirks when coding for CS:GO and offers some workarounds when available and other information.

=Playing Custom Sounds=
Since Left 4 Dead, all normally played sounds must exist in the sound cache on the client. This is an issue for custom sounds as adding to the sound cache requires the client to run snd_rebuildaudiocache (not executable by the server), which also takes a sizable amount of time to run while otherwise locking up the game.

==Workarounds==
Note that with any of these methods, it is still required that you still add the sound to the download table if you need the client to download it from the server or "fastdl".

All of the listed workarounds involve explicitly telling the client to stream the sound directly from the disk rather than starting it from the cache. This is less than ideal, but seems to work well enough. These have only been made to work with mp3 files. A way to support wav files has not yet been found.

===The "play" client command===
If you don't need all of the flexibility that the EmitSound* natives expose and just need one or more clients to hear a sound, you can use the ClientCommand native with the 'play' command. The only difference from normal operation is the prefixing of an asterisk (*) to the path which denotes the sound to be streamed. For this method, you do not need to use PrecacheSound on the server.

Example:
for csgo/sound/custom/ur.mp3
<pawn>
ClientCommand( client, "play */custom/ur.mp3" );
</pawn>

===Fake precaching and EmitSound===
For this method, you also need to make use of the asterisk trick. Unfortunately, the EmitSound natives will fail if the file is not listed in the soundprecache table, and PrecacheSound will fail if the file does not exist, (which is won't, as it treats the asterisk as part of the path when doing the lookup).

Since the sound will be streamed, not needing to actually be precached other than to satisfy the check in EmitSound, we can work around this by manually adding the path, with the asterisk prefixed, directly to the soundprecache table. Then you use the EmitSound native of choice as usual with the exception of the asterisk.

Full plugin example:
<pawn>
#include <sourcemod>
#include <sdktools>

new const String:FULL_SOUND_PATH[] = "sound/custom/ur.mp3";
new const String:RELATIVE_SOUND_PATH[] = "*/custom/ur.mp3";

public OnPluginStart()
{
RegConsoleCmd( "sm_testsound", sm_testsound );
}

public OnMapStart()
{
AddFileToDownloadsTable( FULL_SOUND_PATH );
FakePrecacheSound( RELATIVE_SOUND_PATH );
}

public Action:sm_testsound( client, argc )
{
EmitSoundToClient( client, RELATIVE_SOUND_PATH );

return Plugin_Handled;
}

stock FakePrecacheSound( const String:szPath[] )
{
AddToStringTable( FindStringTable( "soundprecache" ), szPath );
}
</pawn>

Alternately, if you are going to have sounds in a plugin that supports multiple games, you should use the [https://forums.alliedmods.net/showthread.php?t=237045 EmitSoundAny snippets].

''Recent reports indicate that this only works for '''mp3'''s and not '''wav'''s. In the latter case nothing will happen apart from you experiencing puzzled facial expressions and headaches on yourself.''

===Using the music directory===
By adding your custom sounds under sound/music/, they will automatically be streamed from disk. They can also be used just like sounds in any other game with regard to PrecacheSound (albeit not necessary to be beyond adding to soundprecache table) and EmitSound.

This will have the side effect of your sounds volume being tied to the game's music volume, which many players turn down or off. For this reason, it's not recommended.

=Max Players, Clients=
CS:GO has four different values that all affect the maximum number of players that can join a game. The lowest one of the four determines the value used.

==The absolute maximum==
The current absolute maximum number of players for CS:GO, including GOTV is '''64'''. This is a compile-time maximum in the engine on both client and server and cannot be changed.

(This is the maximum value as returned by IServerGameClients::GetPlayerLimits).

==The engine's Maxclients==
This is the number known as gpGlobals->maxClients in SM extensions or MM:S plugins and MaxClients in SourcePawn.

It is able to be changed in other games, up to the maximum, by setting the -maxplayers command line parameter. As this doesn't exist in CS:GO, it acts like other games when not set and uses a hardcoded default, '''64''' for CS:GO.

(This is the default value as returned by IServerGameClients::GetPlayerLimits).

A gamemode's maxplayers can be overridden with the maxplayers parameter in the appropriate section of gamemodes_server.txt

To override maxplayers for all gamemodes, use the -maxplayers_override command line parameter. However, be aware that the game itself appears to enforce a 44 player maximum regardless of what you set this to.

==The GameTypes maxplayers==
CS:GO has a new "GameTypes" system with it's own set of game mode and type -specifec params. There is more on this below, but it also includes a maxplayers value, also referred to as numSlots or MaxHumanPlayers in some areas.

This is the value set in gamemodes.txt or overridden in gamemodes_server.txt or overridden by the new -maxplayer_override command line parameter.

It is used for showing the maxplayers listed in the output of the status command as well as the max count used for the server browser (unless overridden by sv_visiblemaxplayers).

This does not include the count set by the "extraspectators" value in the gamemodes.txt, but both maxplayers and extraspectators must be equal or less than the engine's Maxclients.

The GameTypes max can be retrieved in SourcePawn with the new GetMaxHumanPlayers native or in C++ with IServerGameClients::GetMaxHumanPlayers.

==Spawnpoint count==
Regardless of the above values, you're limited by the running map's number of spawnpoints, evenly split per team (30 for stock maps).

You can use a mod like [http://www.bailopan.net/stripper/ Stripper:Source] or [https://forums.alliedmods.net/showthread.php?p=1054201 Spawn Tools 7] to add more spawnpoint entities.

=Menus=
With SourceMod's "Radio-style" menus (ShowMenu / CHudMenu), the 0 key will cannot be detected due to the client never sending "menuselect 0". SourceMod works around this by limiting menus to 9.

The older "Valve-style" menus created by IServerPluginHelpers::CreateMessage with the DIALOG_MENU type aren't supported at all due at least to missing res file info on the client.

=GameTypes / GameModes=
CS:GO uses a new "GameTypes" system for coordinating server mode and type info between the server, client, and matchmaking, as well as for handling some server rules.

Some things handled by the GameTypes system:
*Game types
*Game modes
*Config to execute for each mode
*Weapon progression for applicable modes
*Maps and map order for each mode
*Maxplayers for each type and mode
*Player and view models for each map
*Bot difficulty
*ELO ranking data

gamemodes.txt is the main data file (in KeyValues format) holding the backing info, with an optional gamemodes_server.txt being merged into it.

The gamemodes data files should not be accessed directly, but rather through the IGameTypes interface. None of it is currently exposed in SourceMod but there are plans to add a new extension giving access to much of the data.

In C++, you can easily get a pointer to the gametypes interface with CreateInterfaceFn from the matchmaking_ds binary, looking up VENGINE_GAMETYPES_VERSION.

See: http://hg.alliedmods.net/hl2sdks/hl2sdk-csgo/file/tip/public/matchmaking/igametypes.h

Example for getting the gametypes ptr in an SM extension, courtesy of Drifter's work-in-progress gametypes extension:
<cpp>
IGameTypes *g_pGameTypes;

#define GET_V_IFACE_CURRENT_CUSTOM(v_factory, v_var, v_type, v_name) \
v_var = (v_type *)g_SMAPI->VInterfaceMatch(v_factory, v_name); \
if (!v_var) \
{ \
if (error && maxlen) \
{ \
g_SMAPI->Format(error, maxlen, "Could not find interface: %s", v_name); \
} \
return false; \
}

{
CreateInterfaceFn matchmakingDSFactory = NULL;
ILibrary *mmlib;
char path[PLATFORM_MAX_PATH];

libsys->PathFormat(path, sizeof(path), "%s/bin/matchmaking_ds%s.%s", g_SMAPI->GetBaseDir(), MATCHMAKINGDS_SUFFIX, MATCHMAKINGDS_EXT);

if ((mmlib = libsys->OpenLibrary(path, NULL, 0)))
{
matchmakingDSFactory = (CreateInterfaceFn)mmlib->GetSymbolAddress("CreateInterface");
mmlib->CloseLibrary();
}

if (!matchmakingDSFactory)
{
g_pSM->Format(error, maxlen, "Failed to find matchmakingDS factory");
return false;
}

GET_V_IFACE_CURRENT_CUSTOM(matchmakingDSFactory, g_pGameTypes, IGameTypes, VENGINE_GAMETYPES_VERSION);

if (!g_pGameTypes)
{
g_pSM->Format(error, maxlen, "Failed to find IGameTypes ptr");
return false;
}
}
</cpp>

=Coding=
There are exceptionalities for some of the SourcePawn coding conventions in CS:GO.

==Slaying players during player_hurt event==
CS:GO will crash if you attempt to call ForcePlayerSuicide() during a player_hurt callback. A timer can be used as a workaround.

Example for slaying a team attacker:

<pawn>
public OnPluginStart()
{
HookEvent("player_hurt", OnPlayerHurt);
}

public OnPlayerHurt(Handle:event, const String:name[], bool:dontBroadcast)
{
new victim = GetClientOfUserId(GetEventInt(event,"userid"));
new attacker = GetClientOfUserId(GetEventInt(event,"attacker"));
if(attacker > 0 && attacker <= MaxClients && IsPlayerAlive(attacker) && GetClientTeam(attacker) == GetClientTeam(victim))
CreateTimer(0.0, SlayTimer, attacker, TIMER_FLAG_NO_MAPCHANGE);
}

public Action:SlayTimer(Handle:timer, any:client)
{
ForcePlayerSuicide(client);
}
</pawn>

==Assists / Score==
Assists and score are not named entity properties in CS:GO. To view or alter assists or displayed score, you can use the following natives new in SM 1.5.0-hg3706:

CS_GetClientAssists
CS_SetClientAssists
CS_GetContributionScore
CS_SetContributionScore

==Denoting Text-Colors==
CSGO has a few odd requirements for properly coloring text in chat.

<pawn>
// \x01 is white.
// \x04 is green.

//These examples set the first half of the string green, and the second half white.

//Normal example:
new String:normalColoring = "\x04This half is green,\x01 This half is white.";

//CSGO example:
new String:csgoColoring = " \x01\x0B\x04This half is green,\x01 This half is white.";
</pawn>
Specific Quirks:
* The string must start with a space.
* Following the space there must be a white color-indicator (\x01).
* Following the \x01, there must be a printable character. \x0B works great because it does not appear in the message.
* After all of these steps you can treat the rest of the string like normal.

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

CSGO Quirks

2015-05-09T14:44:55Z

Dr. Greg House: Return of the evil slashes.

''Others are encouraged to expand on this article with their findings or to clarify any information''

This article explains some of the quirks when coding for CS:GO and offers some workarounds when available and other information.

=Playing Custom Sounds=
Since Left 4 Dead, all normally played sounds must exist in the sound cache on the client. This is an issue for custom sounds as adding to the sound cache requires the client to run snd_rebuildaudiocache (not executable by the server), which also takes a sizable amount of time to run while otherwise locking up the game.

==Workarounds==
Note that with any of these methods, it is still required that you still add the sound to the download table if you need the client to download it from the server or "fastdl".

All of the listed workarounds involve explicitly telling the client to stream the sound directly from the disk rather than starting it from the cache. This is less than ideal, but seems to work well enough. These have only been made to work with mp3 files. A way to support wav files has not yet been found.

===The "play" client command===
If you don't need all of the flexibility that the EmitSound* natives expose and just need one or more clients to hear a sound, you can use the ClientCommand native with the 'play' command. The only difference from normal operation is the prefixing of an asterisk (*) to the path which denotes the sound to be streamed. For this method, you do not need to use PrecacheSound on the server.

Example:
for csgo/sound/custom/ur.mp3
<pawn>
ClientCommand( client, "play */custom/ur.mp3" );
</pawn>

===Fake precaching and EmitSound===
For this method, you also need to make use of the asterisk trick. Unfortunately, the EmitSound natives will fail if the file is not listed in the soundprecache table, and PrecacheSound will fail if the file does not exist, (which is won't, as it treats the asterisk as part of the path when doing the lookup).

Since the sound will be streamed, not needing to actually be precached other than to satisfy the check in EmitSound, we can work around this by manually adding the path, with the asterisk prefixed, directly to the soundprecache table. Then you use the EmitSound native of choice as usual with the exception of the asterisk.

Full plugin example:
<pawn>
#include <sourcemod>
#include <sdktools>

new const String:FULL_SOUND_PATH[] = "sound/custom/ur.mp3";
new const String:RELATIVE_SOUND_PATH[] = "*/custom/ur.mp3";

public OnPluginStart()
{
RegConsoleCmd( "sm_testsound", sm_testsound );
}

public OnMapStart()
{
AddFileToDownloadsTable( FULL_SOUND_PATH );
FakePrecacheSound( RELATIVE_SOUND_PATH );
}

public Action:sm_testsound( client, argc )
{
EmitSoundToClient( client, RELATIVE_SOUND_PATH );

return Plugin_Handled;
}

stock FakePrecacheSound( const String:szPath[] )
{
AddToStringTable( FindStringTable( "soundprecache" ), szPath );
}
</pawn>

Alternately, if you are going to have sounds in a plugin that supports multiple games, you should use the [https://forums.alliedmods.net/showthread.php?t=237045 EmitSoundAny snippets].

''Recent reports indicate that this only works for '''mp3'''s and not '''wav'''s.''

===Using the music directory===
By adding your custom sounds under sound/music/, they will automatically be streamed from disk. They can also be used just like sounds in any other game with regard to PrecacheSound (albeit not necessary to be beyond adding to soundprecache table) and EmitSound.

This will have the side effect of your sounds volume being tied to the game's music volume, which many players turn down or off. For this reason, it's not recommended.

=Max Players, Clients=
CS:GO has four different values that all affect the maximum number of players that can join a game. The lowest one of the four determines the value used.

==The absolute maximum==
The current absolute maximum number of players for CS:GO, including GOTV is '''64'''. This is a compile-time maximum in the engine on both client and server and cannot be changed.

(This is the maximum value as returned by IServerGameClients::GetPlayerLimits).

==The engine's Maxclients==
This is the number known as gpGlobals->maxClients in SM extensions or MM:S plugins and MaxClients in SourcePawn.

It is able to be changed in other games, up to the maximum, by setting the -maxplayers command line parameter. As this doesn't exist in CS:GO, it acts like other games when not set and uses a hardcoded default, '''64''' for CS:GO.

(This is the default value as returned by IServerGameClients::GetPlayerLimits).

A gamemode's maxplayers can be overridden with the maxplayers parameter in the appropriate section of gamemodes_server.txt

To override maxplayers for all gamemodes, use the -maxplayers_override command line parameter. However, be aware that the game itself appears to enforce a 44 player maximum regardless of what you set this to.

==The GameTypes maxplayers==
CS:GO has a new "GameTypes" system with it's own set of game mode and type -specifec params. There is more on this below, but it also includes a maxplayers value, also referred to as numSlots or MaxHumanPlayers in some areas.

This is the value set in gamemodes.txt or overridden in gamemodes_server.txt or overridden by the new -maxplayer_override command line parameter.

It is used for showing the maxplayers listed in the output of the status command as well as the max count used for the server browser (unless overridden by sv_visiblemaxplayers).

This does not include the count set by the "extraspectators" value in the gamemodes.txt, but both maxplayers and extraspectators must be equal or less than the engine's Maxclients.

The GameTypes max can be retrieved in SourcePawn with the new GetMaxHumanPlayers native or in C++ with IServerGameClients::GetMaxHumanPlayers.

==Spawnpoint count==
Regardless of the above values, you're limited by the running map's number of spawnpoints, evenly split per team (30 for stock maps).

You can use a mod like [http://www.bailopan.net/stripper/ Stripper:Source] or [https://forums.alliedmods.net/showthread.php?p=1054201 Spawn Tools 7] to add more spawnpoint entities.

=Menus=
With SourceMod's "Radio-style" menus (ShowMenu / CHudMenu), the 0 key will cannot be detected due to the client never sending "menuselect 0". SourceMod works around this by limiting menus to 9.

The older "Valve-style" menus created by IServerPluginHelpers::CreateMessage with the DIALOG_MENU type aren't supported at all due at least to missing res file info on the client.

=GameTypes / GameModes=
CS:GO uses a new "GameTypes" system for coordinating server mode and type info between the server, client, and matchmaking, as well as for handling some server rules.

Some things handled by the GameTypes system:
*Game types
*Game modes
*Config to execute for each mode
*Weapon progression for applicable modes
*Maps and map order for each mode
*Maxplayers for each type and mode
*Player and view models for each map
*Bot difficulty
*ELO ranking data

gamemodes.txt is the main data file (in KeyValues format) holding the backing info, with an optional gamemodes_server.txt being merged into it.

The gamemodes data files should not be accessed directly, but rather through the IGameTypes interface. None of it is currently exposed in SourceMod but there are plans to add a new extension giving access to much of the data.

In C++, you can easily get a pointer to the gametypes interface with CreateInterfaceFn from the matchmaking_ds binary, looking up VENGINE_GAMETYPES_VERSION.

See: http://hg.alliedmods.net/hl2sdks/hl2sdk-csgo/file/tip/public/matchmaking/igametypes.h

Example for getting the gametypes ptr in an SM extension, courtesy of Drifter's work-in-progress gametypes extension:
<cpp>
IGameTypes *g_pGameTypes;

#define GET_V_IFACE_CURRENT_CUSTOM(v_factory, v_var, v_type, v_name) \
v_var = (v_type *)g_SMAPI->VInterfaceMatch(v_factory, v_name); \
if (!v_var) \
{ \
if (error && maxlen) \
{ \
g_SMAPI->Format(error, maxlen, "Could not find interface: %s", v_name); \
} \
return false; \
}

{
CreateInterfaceFn matchmakingDSFactory = NULL;
ILibrary *mmlib;
char path[PLATFORM_MAX_PATH];

libsys->PathFormat(path, sizeof(path), "%s/bin/matchmaking_ds%s.%s", g_SMAPI->GetBaseDir(), MATCHMAKINGDS_SUFFIX, MATCHMAKINGDS_EXT);

if ((mmlib = libsys->OpenLibrary(path, NULL, 0)))
{
matchmakingDSFactory = (CreateInterfaceFn)mmlib->GetSymbolAddress("CreateInterface");
mmlib->CloseLibrary();
}

if (!matchmakingDSFactory)
{
g_pSM->Format(error, maxlen, "Failed to find matchmakingDS factory");
return false;
}

GET_V_IFACE_CURRENT_CUSTOM(matchmakingDSFactory, g_pGameTypes, IGameTypes, VENGINE_GAMETYPES_VERSION);

if (!g_pGameTypes)
{
g_pSM->Format(error, maxlen, "Failed to find IGameTypes ptr");
return false;
}
}
</cpp>

=Coding=
There are exceptionalities for some of the SourcePawn coding conventions in CS:GO.

==Slaying players during player_hurt event==
CS:GO will crash if you attempt to call ForcePlayerSuicide() during a player_hurt callback. A timer can be used as a workaround.

Example for slaying a team attacker:

<pawn>
public OnPluginStart()
{
HookEvent("player_hurt", OnPlayerHurt);
}

public OnPlayerHurt(Handle:event, const String:name[], bool:dontBroadcast)
{
new victim = GetClientOfUserId(GetEventInt(event,"userid"));
new attacker = GetClientOfUserId(GetEventInt(event,"attacker"));
if(attacker > 0 && attacker <= MaxClients && IsPlayerAlive(attacker) && GetClientTeam(attacker) == GetClientTeam(victim))
CreateTimer(0.0, SlayTimer, attacker, TIMER_FLAG_NO_MAPCHANGE);
}

public Action:SlayTimer(Handle:timer, any:client)
{
ForcePlayerSuicide(client);
}
</pawn>

==Assists / Score==
Assists and score are not named entity properties in CS:GO. To view or alter assists or displayed score, you can use the following natives new in SM 1.5.0-hg3706:

CS_GetClientAssists
CS_SetClientAssists
CS_GetContributionScore
CS_SetContributionScore

==Denoting Text-Colors==
CSGO has a few odd requirements for properly coloring text in chat.

<pawn>
// \x01 is white.
// \x04 is green.

//These examples set the first half of the string green, and the second half white.

//Normal example:
new String:normalColoring = "\x04This half is green,\x01 This half is white.";

//CSGO example:
new String:csgoColoring = " \x01\x0B\x04This half is green,\x01 This half is white.";
</pawn>
Specific Quirks:
* The string must start with a space.
* Following the space there must be a white color-indicator (\x01).
* Following the \x01, there must be a printable character. \x0B works great because it does not appear in the message.
* After all of these steps you can treat the rest of the string like normal.

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

User Messages

2013-09-02T17:30:07Z

Dr. Greg House: Added L4D2 user messages with parameter types of some of them

This is just a dump of some stuff for now, needs a complete revamp later.
Here's a topic on the subject as well: https://forums.alliedmods.net/showthread.php?t=80256 and here http://forums.alliedmods.net/showthread.php?t=52777

=== Counter-Strike: Source User Messages ===
List obtained by using 'meta game' in the console

User Messages: Name Index Size
Geiger 0 1
Train 1 1
HudText 2 -1
SayText 3 -1
SayText2 4 -1
TextMsg 5 -1
HudMsg 6 -1
ResetHUD 7 1
GameTitle 8 0
ItemPickup 9 -1
ShowMenu 10 -1
Shake 11 13
Fade 12 10
VGUIMenu 13 -1
CloseCaption 14 7
SendAudio 15 -1
RawAudio 16 -1
VoiceMask 17 17
RequestState 18 0
BarTime 19 -1
Damage 20 -1
RadioText 21 -1
HintText 22 -1
ReloadEffect 23 2
PlayerAnimEvent 24 -1
AmmoDenied 25 2
UpdateRadar 26 -1
KillCam 27 -1
28 user messages in total

=== Left 4 Dead 2 User Messages ===

For vote specific user messages see http://wiki.alliedmods.net/Left_4_Voting_2

User Messages: Name Index Size Parameter types
SayText2 4 -1
TextMsg 5 -1
HudMsg 6 -1
ResetHUD 7 1
GameTitle 8 0
ItemPickup 9 -1
ShowMenu 10 -1
Shake 11 13
Fade 12 10
VGUIMenu 13 -1 string, bool, string (keyvalues)
Rumble 14 3
CloseCaption 15 -1
CloseCaptionDirect 16 -1
SendAudio 17 -1
RawAudio 18 -1
VoiceMask 19 9
RequestState 20 0
BarTime 21 -1
Damage 22 -1
RadioText 23 -1
HintText 24 -1
KeyHintText 25 -1
ReloadEffect 26 4
PlayerAnimEvent 27 -1
AmmoDenied 28 2
UpdateRadar 29 -1
KillCam 30 -1
MarkAchievement 31 -1
Splatter 32 1
MeleeSlashSplatter 33 1
MeleeClubSplatter 34 1
MudSplatter 35 1
SplatterClear 36 0
MessageText 37 -1
TransitionRestore 38 0
Spawn 39 1
CreditsLine 40 -1
CreditsMsg 41 0
JoinLateMsg 42 0
StatsCrawlMsg 43 0
StatsSkipState 44 2
ShowStats 45 -1
BlurFade 46 0
MusicCmd 47 -1
WitchBloodSplatter 48 -1 vec[3]
AchievementEvent 49 -1
PZDmgMsg 50 -1
AllPlayersConnectedGameStarting 51 0
VoteRegistered 52 1
DisconnectToLobby 53 0 empty
CallVoteFailed 54 1
SteamWeaponStatData 55 -1
CurrentTimescale 56 4
DesiredTimescale 57 16
PZEndGamePanelMsg 58 1
PZEndGamePanelVoteRegisteredMsg 59 1
PZEndGameVoteStatsMsg 60 8
VoteStart 61 -1
VotePass 62 -1
VoteFail 63 1

=== Fade Flags ===
These may not be correct...

FFADE_IN 0x0001 // Just here so we don't pass 0 into the function
FFADE_OUT 0x0002 // Fade out (not in)
FFADE_MODULATE 0x0004 // Modulate (don't blend)
FFADE_STAYOUT 0x0008 // ignores the duration, stays faded out until new ScreenFade message received
FFADE_PURGE 0x0010 // Purges all other fades, replacing them with this one

=== Fade Function ===
Example Fade function (be sure to define the Fade Flags!)

This Fades the clients screen to a specified color, and stays until you reset the color to {0,0,0,0}

To modify it to Fade the screen for a certain amount of time, remove the STAYOUT flag, and pass a value to "fade & hold"

PerformFade(target, 500, {0, 128, 255, 51})

PerformFade(client, duration, const color[4]) {
new Handle:hFadeClient=StartMessageOne("Fade",client)
BfWriteShort(hFadeClient,duration) // FIXED 16 bit, with SCREENFADE_FRACBITS fractional, milliseconds duration
BfWriteShort(hFadeClient,0) // FIXED 16 bit, with SCREENFADE_FRACBITS fractional, milliseconds duration until reset (fade & hold)
BfWriteShort(hFadeClient,(FFADE_PURGE|FFADE_OUT|FFADE_STAYOUT)) // fade type (in / out)
BfWriteByte(hFadeClient,color[0]) // fade red
BfWriteByte(hFadeClient,color[1]) // fade green
BfWriteByte(hFadeClient,color[2]) // fade blue
BfWriteByte(hFadeClient,color[3]) // fade alpha
EndMessage()
}

=== HudMsg Function ===
This does not work in CS:S.

This Draws a text Message to a specified players screen. This is just for educational purposes and there is a much easier way of doing this with native functions here: http://docs.sourcemod.net/api/index.php?fastload=show&id=846& & http://docs.sourcemod.net/api/index.php?fastload=show&id=842&

PerformHudMsg(client, "This is a Test")

PerformHudMsg(client, const String:szMsg[]) {
new Handle:hBf = StartMessageOne("HudMsg", client)
BfWriteByte(hBf, 3) //channel
BfWriteFloat(hBf, 0.0); // x ( -1 = center )
BfWriteFloat(hBf, -1); // y ( -1 = center )
// second color
BfWriteByte(hBf, 0); //r1
BfWriteByte(hBf, 0); //g1
BfWriteByte(hBf, 255); //b1
BfWriteByte(hBf, 255); //a1 // transparent?
// init color
BfWriteByte(hBf, 255); //r2
BfWriteByte(hBf, 0); //g2
BfWriteByte(hBf, 0); //b2
BfWriteByte(hBf, 255); //a2
BfWriteByte(hBf, 0); //effect (0 is fade in/fade out; 1 is flickery credits; 2 is write out)
BfWriteFloat(hBf, 1.0); //fadeinTime (message fade in time - per character in effect 2)
BfWriteFloat(hBf, 1.0); //fadeoutTime
BfWriteFloat(hBf, 15.0); //holdtime
BfWriteFloat(hBf, 5.0); //fxtime (effect type(2) used)
BfWriteString(hBf, szMsg); //Message
EndMessage();
}

=== HookUserMessage Fade ===
Some sample code to hook a UserMessage, In this case Fade.
You cannot send other UserMessages inside of a UserMessage Hook. Many simple functions such as PrintToChat call UserMessages.

public OnPluginStart() {
HookUserMessage(GetUserMessageId("Fade"),HookFade,true)
}

public Action:HookFade(UserMsg:msg_id, Handle:bf, const players[], playersNum, bool:reliable, bool:init) {
new duration = BfReadShort(bf)
new holdtime = BfReadShort(bf)
BfReadShort(bf) //You must read all of the bf values, even If you only want the last value such as this one.
new r = BfReadByte(bf) //You do NOT need to store their value though.
new g = BfReadByte(bf)
new b = BfReadByte(bf)
new a = BfReadByte(bf)

PrintToServer("Duration: %i, HoldTime: %i, rgba: %i %i %i %i",duration,holdtime,r,g,b,a)
}

[[Category:SourceMod Scripting]]

Generic Source Server Events

2013-08-01T17:17:43Z

Dr. Greg House: Pretty sure it's not "server_meSSSage" either :p

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

These '''should''' apply to all Source Engine Servers
=== server_spawn ===
{{qnotice|Send once a server starts (spawns)}} 
{{begin-hl2msg|server_spawn|string}}
{{hl2msg|string|hostname|public host name}}
{{hl2msg|string|address|hostame, IP or DNS name}}
{{hl2msg|string|port|server port}}
{{hl2msg|string|game|game dir}}
{{hl2msg|string|mapname|map name}}
{{hl2msg|long|maxplayers|max players}}
{{hl2msg|string|os|WIN32, LINUX}}
{{hl2msg|bool|dedicated|true if dedicated server}}
{{hl2msg|bool|password|true if password protected}}
{{end-hl2msg}}

=== server_shutdown ===
{{qnotice|Server shut down}}
{{begin-hl2msg|server_shutdown|string}}
{{hl2msg|string|reason|reason why server was shut down}}
{{end-hl2msg}}

=== server_cvar ===
{{qnotice|A server console var has changed}}
{{begin-hl2msg|server_cvar|string}}
{{hl2msg|string|cvarname|cvar name, eg "mp_roundtime"}}
{{hl2msg|string|cvarvalue|new cvar value}}
{{end-hl2msg}}

=== server_message ===
{{qnotice|A generic server message}}
{{begin-hl2msg|server_message|string}}
{{hl2msg|string|text|the message text}}
{{end-hl2msg}}

=== server_addban ===
{{qnotice|When the server has a ban added}}
{{begin-hl2msg|server_addban|string}}
{{hl2msg|string|name|player name}}
{{hl2msg|string|userid|user ID on server}}
{{hl2msg|string|networkid|player network (i.e steam) id}}
{{hl2msg|string|ip|IP address}}
{{hl2msg|string|duration|length of the ban}}
{{hl2msg|string|by|banned by...}}
{{hl2msg|bool|kicked|whether the player was also kicked}}
{{end-hl2msg}}

=== server_removeban ===
{{qnotice|When the server has a ban removed}}
{{begin-hl2msg|server_removeban|string}}
{{hl2msg|string|networkid|player network (i.e steam) id}}
{{hl2msg|string|ip|IP address}}
{{hl2msg|string|by|removed by...}}
{{end-hl2msg}}

=== player_connect ===
{{qnotice|A new client connected}}
{{begin-hl2msg|player_connect|string}}
{{hl2msg|string|name|player name}}
{{hl2msg|byte|index|player slot (entity index-1)}}
{{hl2msg|short|userid|user ID on server (unique on server)}}
{{hl2msg|string|networkid|player network (i.e steam) id}}
{{hl2msg|string|address|ip:port}}
{{hl2msg|short|bot|is a bot}}
{{end-hl2msg}}

=== player_info ===
{{qnotice|A player changed his name}}
{{begin-hl2msg|player_info|string}}
{{hl2msg|string|name|player name}}
{{hl2msg|byte|index|player slot (entity index-1)}}
{{hl2msg|short|userid|user ID on server (unique on server)}}
{{hl2msg|string|networkid|player network (i.e steam) id}}
{{hl2msg|bool|bot|true if player is a AI bot}}
{{end-hl2msg}}

=== player_disconnect ===
{{qnotice|A client was disconnected}}
{{begin-hl2msg|player_disconnect|string}}
{{hl2msg|short|userid|user ID on server}}
{{hl2msg|string|reason|"self", "kick", "ban", "cheat", "error"}}
{{hl2msg|string|name|player name}}
{{hl2msg|string|networkid|player network (i.e steam) id}}
{{hl2msg|short|bot|is a bot}}
{{end-hl2msg}}

=== player_activate ===
{{qnotice|A client has entered the game (connected and loaded)}}
{{begin-hl2msg|player_activate|string}}
{{hl2msg|short|userid|user ID on server}}
{{end-hl2msg}}

=== player_say ===
{{qnotice|When a client sends a message in chat}}
{{begin-hl2msg|player_say|string}}
{{hl2msg|short|userid|user ID on server}}
{{hl2msg|string|text|the say text}}
{{end-hl2msg}}

SQL (SourceMod Scripting)

2013-07-22T16:32:23Z

Dr. Greg House: API says "SQL_ConnectEx" is deprecated and that you should use "SQL_ConnectCustom" instead.

This article is an introduction to using SourceMod's SQL features. It is not an introduction or tutorial about SQL or any specific SQL implementation.

SourceMod's SQL layer is formally called ''DBI'', or the '''D'''ata'''b'''ase '''I'''nterface. The interface is a generic abstraction of common SQL functions. To connect to a specific database implementation (such as MySQL, or sqLite), a SourceMod DBI "driver" must be loaded. Currently, there are drivers for MySQL and SQLite

SourceMod automatically detects and loads drivers on demand (if they exist, of course). All database natives are in <tt>scripting/include/dbi.inc</tt>. The C++ API is in <tt>public/IDBDriver.h</tt>.

=Connecting=
There are two ways to connect to a database. The first is through named configurations. Named configurations are preset configurations listed in <tt>configs/databases.cfg</tt>. SourceMod specifies that if SQL is being used, there should always be one configuration named "default."

An example of such a configuration looks like:
<pre> "default"
{
"host" "localhost"
"database" "sourcemod"
"user" "root"
"pass" ""
//"timeout" "0"
//"port" "0"
}</pre>

Connections based on named configurations can be instantiated with either <tt>SQL_Connect</tt> or <tt>SQL_DefConnect</tt>.

The other option is to use <tt>SQL_ConnectCustom</tt> and manually specify all connection parameters by passing a keyvalue handle containing them.

Example of a typical connection:
<pawn>new String:error[255]
new Handle:db = SQL_DefConnect(error, sizeof(error))

if (db == INVALID_HANDLE)
{
PrintToServer("Could not connect: %s", error)
} else {
CloseHandle(db)
}</pawn>

=Queries=

==No Results==
The simplest queries are ones which do not return results -- for example, CREATE, DROP, UPDATE, INSERT, and DELETE. For such queries it is recommended to use <tt>SQL_FastQuery()</tt>. The name does not imply that the query will be faster, but rather, it is faster to write code using this function. For example, given that <tt>db</tt> is a valid database Handle:

<pawn>if (!SQL_FastQuery(db, "UPDATE stats SET players = players + 1"))
{
new String:error[255]
SQL_GetError(db, error, sizeof(error))
PrintToServer("Failed to query (error: %s)", error)
}</pawn>

==Results==
If a query returns a result set and the results must be processed, you must use <tt>SQL_Query()</tt>. Unlike <tt>SQL_FastQuery()</tt>, this function returns a Handle which must be closed.

An example of a query which will produce results is:
<pawn>new Handle:query = SQL_Query(db, "SELECT userid FROM vb_user WHERE username = 'BAILOPAN'")
if (query == INVALID_HANDLE)
{
new String:error[255]
SQL_GetError(db, error, sizeof(error))
PrintToServer("Failed to query (error: %s)", error)
} else {
/* Process results here!
*/

/* Free the Handle */
CloseHandle(query)
}</pawn>

=Prepared Statements=
Prepared statements are another method of querying. The idea behind a prepared statement is that you construct a query "template" once, and re-use it as many times as needed. Prepared statements have the following benefits:
*A good SQL implementation will be able to cache the query better if it is a prepared statement.
*You don't have to rebuild the entire query string every execution.
*You don't have to allocate a new query structure on every execution.
*Input is "always" secure (more on this later).

A prepared statement has "markers" for inputs. For example, let's consider a function that takes in a database Handle and a name, and retrieves some info from a table:
<pawn>GetSomeInfo(Handle:db, const String:name[])
{
new Handle:hQuery
new String:query[100]

/* Create enough space to make sure our string is quoted properly */
new buffer_len = strlen(name) * 2 + 1
new String:new_name[buffer_len]

/* Ask the SQL driver to make sure our string is safely quoted */
SQL_EscapeString(db, name, new_name, buffer_len)

/* Build the query */
Format(query, sizeof(query), "SELECT userid FROM vb_user WHERE username = '%s'", new_name)

/* Execute the query */
if ((hQuery = SQL_Query(query)) == INVALID_HANDLE)
{
return 0
}

/* Get some info here
*/

CloseHandle(hQuery)
}</pawn>

Observe a version with prepared statements:
<pawn>new Handle:hUserStmt = INVALID_HANDLE;
GetSomeInfo(Handle:db, const String:name[])
{
/* Check if we haven't already created the statement */
if (hUserStmt == INVALID_HANDLE)
{
new String:error[255]
hUserStmt = SQL_PrepareQuery(db, "SELECT userid FROM vb_user WHERE username = ?", error, sizeof(error));
if (hUserStmt == INVALID_HANDLE)
{
return 0;
}
}

SQL_BindParamString(hUserStmt, 0, name, false);
if (!SQL_Execute(hUserStmt))
{
return 0;
}

/**
* Get some info here
*/
}</pawn>

The important differences:
*The input string (<tt>name</tt>) did not need to be backticked (quoted). The SQL engine automatically performs all type safety and insertion checks.
*There was no need for quotation marks around the parameter marker, <tt>?</tt>, even though it accepted a string.
*We only needed to create the statement Handle once; after that it can live for the lifetime of the database connection.

=Processing Results=
Processing results is done in the same manner for both normal queries and prepared statements. The important functions are:
*<tt>SQL_GetRowCount()</tt> - Returns the number of rows.
*<tt>SQL_FetchRow()</tt> - Fetches the next row if one is available.
*<tt>SQL_Fetch[Int|String|Float]()</tt> - Fetches data from a field in the current row.

Let's consider a sample table that looks like this:
<pawn>CREATE TABLE users (
name VARCHAR(64) NOT NULL PRIMARY KEY,
age INT UNSIGNED NOT NULL
);</pawn>

The following example has code that will print out all users matching a certain age. There is an example for both prepared statements and normal queries.
<pawn>PrintResults(Handle:query)
{
/* Even if we have just one row, you must call SQL_FetchRow() first */
new String:name[65]
while (SQL_FetchRow(query))
{
SQL_FetchString(query, 0, name, sizeof(name))
PrintToServer("Name \"%s\" was found.", name)
}
}

bool:GetByAge_Query(Handle:db, age)
{
new String:query[100]
Format(query, sizeof(query), "SELECT name FROM users WHERE age = %d", age)

new Handle:hQuery = SQL_Query(db, query)
if (hQuery == INVALID_HANDLE)
{
return false
}

PrintResults(hQuery)

CloseHandle(hQuery)

return true
}

new Handle:hAgeStmt = INVALID_HANDLE
bool:GetByAge_Statement(Handle:db, age)
{
if (hAgeSmt == INVALID_HANDLE)
{
new String:error[255]
if ((hAgeStmt = SQL_PrepareQuery(db,
"SELECT name FROM users WHERE age = ?",
error,
sizeof(error)))
== INVALID_HANDLE)
{
return false
}
}

SQL_BindParamInt(hAgeStmt, 0, age)
if (!SQL_Execute(hAgeStmt))
{
return false
}

PrintResults(hAgeStmt)

return true
}</pawn>

Note that these examples did not close the statement Handles. These examples assume a global database instance that is only closed when the plugin is unloaded. For plugins which maintain temporary database connections, prepared statement Handles must be freed or else the database connection will never be closed.

=Threading=
SourceMod supports threaded SQL querying. That is, SQL operations can be completed in a separate thread from main gameplay. If your database server is remote or requires a network connection, queries can cause noticeable gameplay lag, and supporting threading is often a good idea if your queries occur in the middle of gameplay.

Threaded queries are ''asynchronous''. That is, they are dispatched and you can only find the results through a callback. Although the callback is guaranteed to fire eventually, it may not fire in any specific given timeframe. Certain drivers may not support threading; if this is the case, an RTE will be thrown. If the threader cannot start or the threader is currently disabled, SourceMod will transparently execute the query in the main thread as a fallback.

==Operations==
All threaded operations use the same callback for result notification: <tt>SQLTCallback</tt>. The parameters are:
*<tt>owner</tt> - The "owner" of the operation. For a query, this is a database. For a database, this is a driver. If the owner was not found or was invalidated, <tt>INVALID_HANDLE</tt> is passed.
*<tt>hndl</tt> - The object being requested. The value is defined by the SQL operation.
*<tt>error</tt> - An error string.
*<tt>data</tt> - Custom data that can be passed via some SQL operations.

The following operations can be done via threads:
*Connection, via <tt>SQL_TConnect</tt>.
*Querying, via <tt>SQL_TQuery()</tt>.
*''Note: prepared statements are not yet available for the threader.''

It is always safe to chain one operation from another.

===Connecting===
It is not necessary to make a threaded connection in order to make threaded queries. However, creating a threaded connection will not pause the game server if a connection cannot be immediately established.

The following parameters are used for the threaded connection callback:
*<tt>owner</tt>: A Handle to the driver, or <tt>INVALID_HANDLE</tt> if it could not be found.
*<tt>hndl</tt>: A Handle to the database, or <tt>INVALID_HANDLE</tt> if the connection failed.
*<tt>error</tt>: The error string, if any.
*<tt>data</tt>: Unused (0)

Example:
<pawn>new Handle:hDatabase = INVALID_HANDLE;

StartSQL()
{
SQL_TConnect(GotDatabase);
}

public GotDatabase(Handle:owner, Handle:hndl, const String:error[], any:data)
{
if (hndl == INVALID_HANDLE)
{
LogError("Database failure: %s", error);
} else {
hDatabase = hndl;
}
}</pawn>

===Querying===
Threaded queries can be performed on any database Handle as long as the driver supports threading. All query results for the first result set are retrieved while in the thread. If your query returns more than one set of results (for example, <tt>CALL</tt> on MySQL with certain functions), the behaviour of the threader is undefined at this time. Note that if you want to perform both threaded and non-threaded queries on the same connection, you MUST read the "Locking" section below.

Query operations use the following callback parameters:
*<tt>owner</tt>: A Handle to the database used to query. The Handle is not the same as the Handle originally passed; however, it will test positively with <tt>SQL_IsSameConnection</tt>. The Handle can be cloned but it cannot be closed (it is closed automatically). It may be <tt>INVALID_HANDLE</tt> in the case of a serious error (for example, the driver being unloaded).
*<tt>hndl</tt>: A Handle to the query. It can be cloned, but not closed (it is closed automatically). It may be <tt>INVALID_HANDLE</tt> if there was an error.
*<tt>error</tt>: Error string, if any.
*<tt>data</tt>: Optional user-defined data passed in through <tt>SQL_TQuery()</tt>.

Example, continuing from above:
<pawn>CheckSteamID(userid, const String:auth[])
{
decl String:query[255];
Format(query, sizeof(query), "SELECT userid FROM users WHERE steamid = '%s'", auth);
SQL_TQuery(hdatabase, T_CheckSteamID, query, userid)
}

public T_CheckSteamID(Handle:owner, Handle:hndl, const String:error[], any:data)
{
new client;

/* Make sure the client didn't disconnect while the thread was running */
if ((client = GetClientOfUserId(data)) == 0)
{
return;
}

if (hndl == INVALID_HANDLE)
{
LogError("Query failed! %s", error);
KickClient(client, "Authorization failed");
} else if (!SQL_GetRowCount(hndl)) {
KickClient(client, "You are not a member");
}
}
</pawn>

==Locking==
It is possible to run both threaded and non-threaded queries on the same connection. However, without the proper precautions, you could corrupt the network stream (even if it's local), corrupt memory, or otherwise cause a crash in the SQL driver. To solve this, SourceMod has ''database locking''. Locking is done via <tt>SQL_LockDatabase()</tt> and <tt>SQL_UnlockDatabase</tt>.

Whenever performing any of the following non-threaded operations on a database, it is absolutely necessary to enclose the entire operation with a lock:
*<tt>SQL_Query()</tt> (and <tt>SQL_FetchMoreResults</tt> pairings)
*<tt>SQL_FastQuery</tt>
*<tt>SQL_PrepareQuery</tt>
*<tt>SQL_Bind*</tt> and <tt>SQL_Execute</tt> pairings

The rule of thumb is: if your operation is going to use the database connection, it must be locked until the operation is fully completed.

Example:
<pawn>bool:GetByAge_Query(Handle:db, age)
{
new String:query[100]
Format(query, sizeof(query), "SELECT name FROM users WHERE age = %d", age)

SQL_LockDatabase(db);
new Handle:hQuery = SQL_Query(db, query)
if (hQuery == INVALID_HANDLE)
{
SQL_UnlockDatabase(db);
return false
}
SQL_UnlockDatabase(db);

PrintResults(hQuery)

CloseHandle(hQuery)

return true
}</pawn>

Note that it was only necessary to lock the query; SourceMod pre-fetches the result set, and thus the network queue is clean.

===Warnings===
*Never call <tt>SQL_LockDatabase</tt> right before a threaded operation. You will deadlock the server and have to terminate/kill it.
*Always pair every Lock with an Unlock. Otherwise you risk a deadlock.
*If your query returns multiple result sets, for example, a procedure call on MySQL that returns results, you must lock both the query and the entire fetch operation. SourceMod is only able to fetch one result set at a time, and all result sets must be cleared before a new query is started.

==Priority==
Threaded SQL operations are placed in a simple priority queue. The priority levels are <tt>High</tt>, <tt>Medium</tt>, and <tt>Low</tt>. Connections always have the highest priority.

Changing the priority can be useful if you have many queries with different purposes. For example, a statistics plugin might execute 10 queries on death, and one query on join. Because the statistics might rely on the join info, the join query might need to be high priority, while the death queries can be low priority.

You should never simply assign a high priority to all of your queries simply because you want them to get done fast. Not only does it not work that way, but you may be inserting subtle problems into other plugins by being greedy.

=SQLite=
==Introduction==
[http://www.sqlite.org/ SQLite] is a fast local-file SQL database engine and SourceMod provides a DBI driver for it. SQLite differs from MySQL, and thus MySQL queries may not work in SQLite. The driver type for connections is <tt>sqlite</tt>.

==Usage==
Since SQLite is local only, most of the connection parameters can be ignored. The only connection parameter required is <tt>database</tt>, which specifies the file name of the database. Databases are created on demand if they do not already exist, and are stored in <tt>addons/sourcemod/data/sqlite</tt>. An extension of ".sq3" is automatically appended to the file name.

Additionally, you can specify sub-folders in the database name. For example, "cssdm/players" will become <tt>addons/sourcemod/data/sqlite/cssdm/players.sq3</tt>.

SQLite supports the threading layer, and requires all of the same rules as the MySQL driver (including locks on shared connections).

==External Links==
*[http://www.sqlite.org SQLite Homepage]
*[http://sqlitebrowser.sourceforge.net/ SQLite Browser]

[[Category:SourceMod Scripting]]

{{LanguageSwitch}}

Commands (SourceMod Scripting)

2013-06-15T00:21:56Z

Dr. Greg House: Again, adding "Plugin_Handled"

[[SourceMod]] allows you to create console commands similar to [[AMX Mod X]]. There are two main types of console commands:
*'''Server Commands''' - 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''' - 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-bound "commands," such as +attack 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 defined in <tt>console.inc</tt>. When registering a server command, you may be hooking an already existing command, and thus the return value 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> - The 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);
}
return Plugin_Handled;
}
</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)
{
PrintToServer("Command from client: %N", 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);
}
return Plugin_Handled;
}</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>new Handle:ff = INVALID_HANDLE;

public OnPluginStart()
{
AddCommandListener(Command_Say, "say");
AddCommandListener(Command_Say, "say2");
AddCommandListener(Command_Say, "say_team");

ff = FindConVar("mp_friendlyfire");
}

public Action:Command_Say(client, const String:command[], argc)
{
decl String:text[192];
new startidx = 0;
if (GetCmdArgString(text, sizeof(text)) < 1)
{
return Plugin_Continue;
}

if (text[strlen(text)-1] == '"')
{
text[strlen(text)-1] = '\0';
startidx = 1;
}

if (strcmp(command, "say2", false) == 0)
startidx += 4;

if (strcmp(text[startidx], "ff", false) == 0)
{
if (ff != INVALID_HANDLE)
{
if (GetConVarBool(ff))
{
PrintToChat(client, "Friendly fire is enabled.");
} else {
PrintToChat(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], target = -1;
GetCmdArg(1, name, sizeof(name));

for (new i=1; i<=MaxClients; 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], target = -1;
GetCmdArg(1, name, sizeof(name));

for (new i=1; i<=MaxClients; 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. For example, if you create a console command called <tt>"sm_megaslap"</tt>, 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 Scripting]]

{{LanguageSwitch}}

Commands (SourceMod Scripting)

2013-06-15T00:20:53Z

Dr. Greg House: Returning Plugin_Handled to prevent "unknown command"-error after proper execution.

[[SourceMod]] allows you to create console commands similar to [[AMX Mod X]]. There are two main types of console commands:
*'''Server Commands''' - 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''' - 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-bound "commands," such as +attack 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 defined in <tt>console.inc</tt>. When registering a server command, you may be hooking an already existing command, and thus the return value 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> - The 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);
}
return Plugin_Handled;
}
</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)
{
PrintToServer("Command from client: %N", 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>new Handle:ff = INVALID_HANDLE;

public OnPluginStart()
{
AddCommandListener(Command_Say, "say");
AddCommandListener(Command_Say, "say2");
AddCommandListener(Command_Say, "say_team");

ff = FindConVar("mp_friendlyfire");
}

public Action:Command_Say(client, const String:command[], argc)
{
decl String:text[192];
new startidx = 0;
if (GetCmdArgString(text, sizeof(text)) < 1)
{
return Plugin_Continue;
}

if (text[strlen(text)-1] == '"')
{
text[strlen(text)-1] = '\0';
startidx = 1;
}

if (strcmp(command, "say2", false) == 0)
startidx += 4;

if (strcmp(text[startidx], "ff", false) == 0)
{
if (ff != INVALID_HANDLE)
{
if (GetConVarBool(ff))
{
PrintToChat(client, "Friendly fire is enabled.");
} else {
PrintToChat(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], target = -1;
GetCmdArg(1, name, sizeof(name));

for (new i=1; i<=MaxClients; 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], target = -1;
GetCmdArg(1, name, sizeof(name));

for (new i=1; i<=MaxClients; 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. For example, if you create a console command called <tt>"sm_megaslap"</tt>, 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 Scripting]]

{{LanguageSwitch}}

Left 4 Voting 2

2013-06-14T02:06:39Z

Dr. Greg House: /* Values for "issue" and "param1" in standard votes */

Left 4 Dead 2 has a VGUI voting system controller by a bunch of Events and UserMessages. You can use either a string from the resource file, or L4D_TargetID_Player which will let you create any vote you want.

== How voting works ==
# A client issues a callvote with the vote type and argument.
# The VoteStart User Message is sent.
# Clients use the "Vote" command to register their votes ("Yes" or "No"), after which the server sends a VoteRegistered UserMessage to that player to acknowledge their vote. A vote_changed event is sent to all players with updated numbers.
# When the vote is complete, the server sends either a VotePass or VoteFail UserMessage.

== Server Entity ==

The server should update this as appropriate. Unfortunately, the valid values for m_iActiveIssueIndex is unknown.

{{begin-hl2msg|vote_controller (CVoteController)|string}}
{{hl2msg|int|m_activeIssueIndex|Number of the active issue}}
{{hl2msg|int|m_onlyTeamToVote|Corresponds to VoteStart's team argument.}}
{{hl2msg|int|m_votesYes|Current Yes votes}}
{{hl2msg|int|m_votesNo|Current No votes}}
{{hl2msg|int|m_potentialVotes|Number of players eligible to vote}}
{{end-hl2msg}}

== Console Commands ==

=== Vote ===

{{qnotice|This command is only valid when a vote is ongoing.}} 
{{begin-hl2msg|Vote|string}}
{{hl2msg|string|option|"Yes" or "No"}}
{{end-hl2msg}}

== User Messages ==
{{qnotice|These user messages use unsigned bytes for the team number. Since Valve represents no team as -1, no team is instead represented as its two's complement, 255.}} 

===VoteStart===
{{qnotice|Sent to all players in the vote group, corresponding with teams. The default implementation also sends it to bots.}} 

{{begin-hl2msg|VoteStart|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{hl2msg|byte|initiator|Client index (NOT USERID) of person who started the vote, or 99 for the server.}}
{{hl2msg|string|issue|Vote issue translation string}}
{{hl2msg|string|param1|Vote issue text}}
{{hl2msg|string|initiatorName|Name of person who started the vote}}
{{end-hl2msg}}
====Values for "issue" and "param1" in standard votes====
{| class="wikitable"
|-
! Vote type !! issue !! param1
|-
| Kick || #L4D_vote_kick_player || Nickname of the person to be kicked without "#"
|-
| ReturnToLobby || #L4D_vote_return_to_lobby ||
|-
| ChangeCampaign || #L4D_vote_mission_change || #L4D360UI_CampaignName_C5
|-
| RestartChapter || #L4D_vote_passed_versus_level_restart ||
|-
| ChangeDifficulty (easy) || #L4D_vote_change_difficulty || #L4D_DifficultyEasy
|-
| ChangeDifficulty (hard) || #L4D_vote_change_difficulty || #L4D_DifficultyHard
|-
| Alltalk On || #L4D_vote_alltalk_change || #L4D_vote_alltalk_enable
|-
| Alltalk Off || #L4D_vote_alltalk_change || #L4D_vote_alltalk_disable
|}
*Campaigns aren't specified by map name but by the index the campaign's entry has in the game menus. Example: "5" specifies the campaign "The Parish"

===VoteRegistered===
{{qnotice|Only sent to player who voted}} 
{{begin-hl2msg|VoteRegistered|string}}
{{hl2msg|byte|vote|0 for No, 1 for Yes}}
{{end-hl2msg}}

===VotePass===
{{qnotice|Sent to all players after a vote passes.}} 

{{begin-hl2msg|VotePass|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{hl2msg|string|details|Vote success translation string}}
{{hl2msg|string|param1|Vote winner}}
{{end-hl2msg}}

===VoteFail===
{{qnotice|Sent to all players after a vote fails.}} 

{{begin-hl2msg|VoteFail|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{end-hl2msg}}

== Events ==
{{qnotice|team is -1 when sent to all players)}} 

=== vote_changed ===
{{begin-hl2msg|vote_changed|string}}
{{hl2msg|byte|yesVotes|}}
{{hl2msg|byte|noVotes|}}
{{hl2msg|byte|potentialVotes|}}
{{end-hl2msg}}
== Example voting plugin ==
This is a basic plugin that starts a vote, "Is gaben fat?". It does not ensure the same client does not vote multiple times, nor does it actually kick the user.

<pre>#include <sourcemod>

#define L4D2_TEAM_ALL -1

new yesvotes;
new novotes;
#define MAX_VOTES 4

public OnPluginStart()
{
RegConsoleCmd("testvote",Callvote_Handler);
RegConsoleCmd("Vote",vote);
}
public Action:Callvote_Handler(client, args)
{
new Handle:bf = StartMessageAll("VoteStart", USERMSG_RELIABLE);

BfWriteByte(bf, L4D2_TEAM_ALL);
BfWriteByte(bf, 0);
BfWriteString(bf, "#L4D_TargetID_Player");
BfWriteString(bf, "Is gaben fat?");
BfWriteString(bf, "Server");
EndMessage();

yesvotes = 0;
novotes = 0;
UpdateVotes();

return Plugin_Handled;
}
public UpdateVotes()
{
new Handle:msg = CreateEvent("vote_changed");
SetEventInt(msg,"yesVotes",yesvotes);
SetEventInt(msg,"noVotes",novotes);
SetEventInt(msg,"potentialVotes",MAX_VOTES);
FireEvent(msg);

if (yesvotes+novotes == MAX_VOTES)
{
PrintToServer("voting complete!");
if (yesvotes > novotes)
{
new Handle:bf = StartMessageAll("VotePass");
BfWriteByte(bf, L4D2_TEAM_ALL);
BfWriteString(bf, "#L4D_TargetID_Player");
BfWriteString(bf, "Gaben is fat");
EndMessage();
}
else
{
new Handle:bf = StartMessageAll("VoteFailed");
BfWriteByte(bf, L4D2_TEAM_ALL);
EndMessage();
}
}
}
public Action:vote(client, args)
{
new String:arg[8];
GetCmdArg(1,arg,8);
PrintToServer("Got vote %s from %i",arg,client);
if (strcmp(arg,"Yes",true) == 0)
{
yesvotes++;
}
else if (strcmp(arg,"No",true) == 0)
{
novotes++;
}

UpdateVotes();
return Plugin_Continue;
}</pre>

==See Also==
* [[Left 4 Voting]]
* [[TF2 Voting]]
* [https://forums.alliedmods.net/showthread.php?t=162164 BuiltinVotes], a SourceMod extension that exposes a voting API that uses this voting system.

Left 4 Voting 2

2013-06-14T00:57:21Z

Dr. Greg House: /* Values for "issue" and "param1" in standard votes */

Left 4 Dead 2 has a VGUI voting system controller by a bunch of Events and UserMessages. You can use either a string from the resource file, or L4D_TargetID_Player which will let you create any vote you want.

== How voting works ==
# A client issues a callvote with the vote type and argument.
# The VoteStart User Message is sent.
# Clients use the "Vote" command to register their votes ("Yes" or "No"), after which the server sends a VoteRegistered UserMessage to that player to acknowledge their vote. A vote_changed event is sent to all players with updated numbers.
# When the vote is complete, the server sends either a VotePass or VoteFail UserMessage.

== Server Entity ==

The server should update this as appropriate. Unfortunately, the valid values for m_iActiveIssueIndex is unknown.

{{begin-hl2msg|vote_controller (CVoteController)|string}}
{{hl2msg|int|m_activeIssueIndex|Number of the active issue}}
{{hl2msg|int|m_onlyTeamToVote|Corresponds to VoteStart's team argument.}}
{{hl2msg|int|m_votesYes|Current Yes votes}}
{{hl2msg|int|m_votesNo|Current No votes}}
{{hl2msg|int|m_potentialVotes|Number of players eligible to vote}}
{{end-hl2msg}}

== Console Commands ==

=== Vote ===

{{qnotice|This command is only valid when a vote is ongoing.}} 
{{begin-hl2msg|Vote|string}}
{{hl2msg|string|option|"Yes" or "No"}}
{{end-hl2msg}}

== User Messages ==
{{qnotice|These user messages use unsigned bytes for the team number. Since Valve represents no team as -1, no team is instead represented as its two's complement, 255.}} 

===VoteStart===
{{qnotice|Sent to all players in the vote group, corresponding with teams. The default implementation also sends it to bots.}} 

{{begin-hl2msg|VoteStart|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{hl2msg|byte|initiator|Client index (NOT USERID) of person who started the vote, or 99 for the server.}}
{{hl2msg|string|issue|Vote issue translation string}}
{{hl2msg|string|param1|Vote issue text}}
{{hl2msg|string|initiatorName|Name of person who started the vote}}
{{end-hl2msg}}
====Values for "issue" and "param1" in standard votes====
{| class="wikitable"
|-
! Vote type !! issue !! param1
|-
| Kick || #L4D_vote_kick_player || Nickname of the person to be kicked without "#"
|-
| ReturnToLobby || #L4D_vote_return_to_lobby ||
|-
| ChangeCampaign || #L4D_vote_mission_change || #L4D360UI_CampaignName_C5
|}
*Campaigns aren't specified by map name but by the index the campaign's entry has in the game menus. Example: "5" specifies the campaign "The Parish"

===VoteRegistered===
{{qnotice|Only sent to player who voted}} 
{{begin-hl2msg|VoteRegistered|string}}
{{hl2msg|byte|vote|0 for No, 1 for Yes}}
{{end-hl2msg}}

===VotePass===
{{qnotice|Sent to all players after a vote passes.}} 

{{begin-hl2msg|VotePass|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{hl2msg|string|details|Vote success translation string}}
{{hl2msg|string|param1|Vote winner}}
{{end-hl2msg}}

===VoteFail===
{{qnotice|Sent to all players after a vote fails.}} 

{{begin-hl2msg|VoteFail|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{end-hl2msg}}

== Events ==
{{qnotice|team is -1 when sent to all players)}} 

=== vote_changed ===
{{begin-hl2msg|vote_changed|string}}
{{hl2msg|byte|yesVotes|}}
{{hl2msg|byte|noVotes|}}
{{hl2msg|byte|potentialVotes|}}
{{end-hl2msg}}
== Example voting plugin ==
This is a basic plugin that starts a vote, "Is gaben fat?". It does not ensure the same client does not vote multiple times, nor does it actually kick the user.

<pre>#include <sourcemod>

#define L4D2_TEAM_ALL -1

new yesvotes;
new novotes;
#define MAX_VOTES 4

public OnPluginStart()
{
RegConsoleCmd("testvote",Callvote_Handler);
RegConsoleCmd("Vote",vote);
}
public Action:Callvote_Handler(client, args)
{
new Handle:bf = StartMessageAll("VoteStart", USERMSG_RELIABLE);

BfWriteByte(bf, L4D2_TEAM_ALL);
BfWriteByte(bf, 0);
BfWriteString(bf, "#L4D_TargetID_Player");
BfWriteString(bf, "Is gaben fat?");
BfWriteString(bf, "Server");
EndMessage();

yesvotes = 0;
novotes = 0;
UpdateVotes();

return Plugin_Handled;
}
public UpdateVotes()
{
new Handle:msg = CreateEvent("vote_changed");
SetEventInt(msg,"yesVotes",yesvotes);
SetEventInt(msg,"noVotes",novotes);
SetEventInt(msg,"potentialVotes",MAX_VOTES);
FireEvent(msg);

if (yesvotes+novotes == MAX_VOTES)
{
PrintToServer("voting complete!");
if (yesvotes > novotes)
{
new Handle:bf = StartMessageAll("VotePass");
BfWriteByte(bf, L4D2_TEAM_ALL);
BfWriteString(bf, "#L4D_TargetID_Player");
BfWriteString(bf, "Gaben is fat");
EndMessage();
}
else
{
new Handle:bf = StartMessageAll("VoteFailed");
BfWriteByte(bf, L4D2_TEAM_ALL);
EndMessage();
}
}
}
public Action:vote(client, args)
{
new String:arg[8];
GetCmdArg(1,arg,8);
PrintToServer("Got vote %s from %i",arg,client);
if (strcmp(arg,"Yes",true) == 0)
{
yesvotes++;
}
else if (strcmp(arg,"No",true) == 0)
{
novotes++;
}

UpdateVotes();
return Plugin_Continue;
}</pre>

==See Also==
* [[Left 4 Voting]]
* [[TF2 Voting]]
* [https://forums.alliedmods.net/showthread.php?t=162164 BuiltinVotes], a SourceMod extension that exposes a voting API that uses this voting system.

Left 4 Voting 2

2013-06-14T00:57:04Z

Dr. Greg House: Added subsection "Values for "issue" and "param1" in standard votes". More coming soon.

Left 4 Dead 2 has a VGUI voting system controller by a bunch of Events and UserMessages. You can use either a string from the resource file, or L4D_TargetID_Player which will let you create any vote you want.

== How voting works ==
# A client issues a callvote with the vote type and argument.
# The VoteStart User Message is sent.
# Clients use the "Vote" command to register their votes ("Yes" or "No"), after which the server sends a VoteRegistered UserMessage to that player to acknowledge their vote. A vote_changed event is sent to all players with updated numbers.
# When the vote is complete, the server sends either a VotePass or VoteFail UserMessage.

== Server Entity ==

The server should update this as appropriate. Unfortunately, the valid values for m_iActiveIssueIndex is unknown.

{{begin-hl2msg|vote_controller (CVoteController)|string}}
{{hl2msg|int|m_activeIssueIndex|Number of the active issue}}
{{hl2msg|int|m_onlyTeamToVote|Corresponds to VoteStart's team argument.}}
{{hl2msg|int|m_votesYes|Current Yes votes}}
{{hl2msg|int|m_votesNo|Current No votes}}
{{hl2msg|int|m_potentialVotes|Number of players eligible to vote}}
{{end-hl2msg}}

== Console Commands ==

=== Vote ===

{{qnotice|This command is only valid when a vote is ongoing.}} 
{{begin-hl2msg|Vote|string}}
{{hl2msg|string|option|"Yes" or "No"}}
{{end-hl2msg}}

== User Messages ==
{{qnotice|These user messages use unsigned bytes for the team number. Since Valve represents no team as -1, no team is instead represented as its two's complement, 255.}} 

===VoteStart===
{{qnotice|Sent to all players in the vote group, corresponding with teams. The default implementation also sends it to bots.}} 

{{begin-hl2msg|VoteStart|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{hl2msg|byte|initiator|Client index (NOT USERID) of person who started the vote, or 99 for the server.}}
{{hl2msg|string|issue|Vote issue translation string}}
{{hl2msg|string|param1|Vote issue text}}
{{hl2msg|string|initiatorName|Name of person who started the vote}}
{{end-hl2msg}}
====Values for "issue" and "param1" in standard votes====
Coming soon...
{| class="wikitable"
|-
! Vote type !! issue !! param1
|-
| Kick || #L4D_vote_kick_player || Nickname of the person to be kicked without "#"
|-
| ReturnToLobby || #L4D_vote_return_to_lobby ||
|-
| ChangeCampaign || #L4D_vote_mission_change || #L4D360UI_CampaignName_C5
|}
*Campaigns aren't specified by map name but by the index the campaign's entry has in the game menus. Example: "5" specifies the campaign "The Parish"

===VoteRegistered===
{{qnotice|Only sent to player who voted}} 
{{begin-hl2msg|VoteRegistered|string}}
{{hl2msg|byte|vote|0 for No, 1 for Yes}}
{{end-hl2msg}}

===VotePass===
{{qnotice|Sent to all players after a vote passes.}} 

{{begin-hl2msg|VotePass|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{hl2msg|string|details|Vote success translation string}}
{{hl2msg|string|param1|Vote winner}}
{{end-hl2msg}}

===VoteFail===
{{qnotice|Sent to all players after a vote fails.}} 

{{begin-hl2msg|VoteFail|string}}
{{hl2msg|byte|team|Team index or 255 for all}}
{{end-hl2msg}}

== Events ==
{{qnotice|team is -1 when sent to all players)}} 

=== vote_changed ===
{{begin-hl2msg|vote_changed|string}}
{{hl2msg|byte|yesVotes|}}
{{hl2msg|byte|noVotes|}}
{{hl2msg|byte|potentialVotes|}}
{{end-hl2msg}}
== Example voting plugin ==
This is a basic plugin that starts a vote, "Is gaben fat?". It does not ensure the same client does not vote multiple times, nor does it actually kick the user.

<pre>#include <sourcemod>

#define L4D2_TEAM_ALL -1

new yesvotes;
new novotes;
#define MAX_VOTES 4

public OnPluginStart()
{
RegConsoleCmd("testvote",Callvote_Handler);
RegConsoleCmd("Vote",vote);
}
public Action:Callvote_Handler(client, args)
{
new Handle:bf = StartMessageAll("VoteStart", USERMSG_RELIABLE);

BfWriteByte(bf, L4D2_TEAM_ALL);
BfWriteByte(bf, 0);
BfWriteString(bf, "#L4D_TargetID_Player");
BfWriteString(bf, "Is gaben fat?");
BfWriteString(bf, "Server");
EndMessage();

yesvotes = 0;
novotes = 0;
UpdateVotes();

return Plugin_Handled;
}
public UpdateVotes()
{
new Handle:msg = CreateEvent("vote_changed");
SetEventInt(msg,"yesVotes",yesvotes);
SetEventInt(msg,"noVotes",novotes);
SetEventInt(msg,"potentialVotes",MAX_VOTES);
FireEvent(msg);

if (yesvotes+novotes == MAX_VOTES)
{
PrintToServer("voting complete!");
if (yesvotes > novotes)
{
new Handle:bf = StartMessageAll("VotePass");
BfWriteByte(bf, L4D2_TEAM_ALL);
BfWriteString(bf, "#L4D_TargetID_Player");
BfWriteString(bf, "Gaben is fat");
EndMessage();
}
else
{
new Handle:bf = StartMessageAll("VoteFailed");
BfWriteByte(bf, L4D2_TEAM_ALL);
EndMessage();
}
}
}
public Action:vote(client, args)
{
new String:arg[8];
GetCmdArg(1,arg,8);
PrintToServer("Got vote %s from %i",arg,client);
if (strcmp(arg,"Yes",true) == 0)
{
yesvotes++;
}
else if (strcmp(arg,"No",true) == 0)
{
novotes++;
}

UpdateVotes();
return Plugin_Continue;
}</pre>

==See Also==
* [[Left 4 Voting]]
* [[TF2 Voting]]
* [https://forums.alliedmods.net/showthread.php?t=162164 BuiltinVotes], a SourceMod extension that exposes a voting API that uses this voting system.

Talk:Left 4 Voting 2

2013-06-13T07:39:06Z

Dr. Greg House:

Wouldn't it be a better idea to hook the user message "VoteRegistered" and use const players[] (which length would be 1 and would contain the userid or clientid(?)) to determine which player did the vote? This would be more accurate than parsing the vote command and filtering out who has already voted since "VoteRegistered" would only be sent when the vote was actually accepted and not when someone attempts to vote (again or isn't allowed to).
:If you're manually creating the vote, the game server won't handle the vote processing for you and ''you'' will be responsible for sending the VoteRegistered UserMessage yourself based on what Vote command they send to you.

:Granted, at this point you might as well use the SourceMod NativeVotes plugin as it's a wrapper for the L4D, L4D2, TF2, and CS:GO vote systems.
:--[[User:Powerlord|Powerlord]] ([[User talk:Powerlord|talk]]) 22:46, 12 June 2013 (CDT)

::You're right, it's already mentioned in the explanation on how it works. However, the usermessage is not created and sent in the example. At this point I'm wondering what might happen in that case considering visual acknowledgement aka box getting checked. Does the engine handle it automatically with/on each vote command that's been received, is it the "vote_changed"-event that checks the box or is there no box-checking at all (and it's the usermessage that actually triggers this)? I guess I'll just check that out by my own later when I'll have time to play around with the usermessages.
::And yes, your plugin should usually be used as a wrapper, however, I'm actually interested in making it possible for a plugin to register votes and their momentary status and parameters. I was only mentioning the above because it crossed my mind during the read.
::--[[User:Dr. Greg House|Dr. Greg House]] ([[User talk:Dr. Greg House|talk]]) 02:37, 13 June 2013 (CDT)

Talk:Left 4 Voting 2

2013-06-13T07:37:49Z

Dr. Greg House:

Wouldn't it be a better idea to hook the user message "VoteRegistered" and use const players[] (which length would be 1 and would contain the userid or clientid(?)) to determine which player did the vote? This would be more accurate than parsing the vote command and filtering out who has already voted since "VoteRegistered" would only be sent when the vote was actually accepted and not when someone attempts to vote (again or isn't allowed to).
:If you're manually creating the vote, the game server won't handle the vote processing for you and ''you'' will be responsible for sending the VoteRegistered UserMessage yourself based on what Vote command they send to you.

:Granted, at this point you might as well use the SourceMod NativeVotes plugin as it's a wrapper for the L4D, L4D2, TF2, and CS:GO vote systems.
:--[[User:Powerlord|Powerlord]] ([[User talk:Powerlord|talk]]) 22:46, 12 June 2013 (CDT)

:You're right, it's already mentioned in the explanation on how it works. However, the usermessage is not created and sent in the example. At this point I'm wondering what might happen in that case considering visual acknowledgement aka box getting checked. Does the engine handle it automatically with/on each vote command that's been received, is it the "vote_changed"-event that checks the box or is there no box-checking at all (and it's the usermessage that actually triggers this)? I guess I'll just check that out by my own later when I'll have time to play around with the usermessages.
And yes, your plugin should usually be used as a wrapper, however, I'm actually interested in making it possible for a plugin to register votes and their momentary status and parameters. I was only mentioning the above because it crossed my mind during the read.
--[[User:Dr. Greg House|Dr. Greg House]] ([[User talk:Dr. Greg House|talk]]) 02:37, 13 June 2013 (CDT)

Talk:Left 4 Voting 2

2013-06-13T03:23:40Z

Dr. Greg House: Use a hook into "VoteRegistered" instead of hooking the vote command?