Ru:Introduction to SourceMod Plugins

Это руководство даст Вам основные понятия о написании SourceMod плагинов. Если вы не знакомы с языком SourcePawn, то Мы настоятельно рекомендуем ознакомиться со статьей Ru:Introduction to SourcePawn (Введение в SourcePawn).

Для получения информации о компиляции плагинов см. Compiling SourceMod Plugins (Компиляция SourceMod плагинов). Автор настоящей статьи использует редактор Crimson Editor для написания плагинов. Вы можете использовать PSPad, UltraEdit, Notepad++, TextPad, SourceMod IDE или любой другой текстовый редактор.

Начиная с нуля

Откройте Ваш любимый текстовый редактор и создайте новый пустой файл. Теперь Вы можете начать писать код, используя основные функции языка, однако, Вы не можете использовать любые функции и особенности самого SourceMod, потому что компилятор ничего не знает о них. Это сделано специально, чтобы было возможно использовать SourcePawn отдельно от SourceMod. Но так как мы пишем плагин именно для SourceMod, самая лучшая идея - это в первую очередь получить доступ к оособенностям SourceMod. Этой цели можно достичь с помощью директивы #include. Она сообщает компилятору, что содержимое указанного файла нужно вставить в Ваш при компиляции.

#include <sourcemod>

Как это работает? Сначала обратите внимание, что имя файла мы обрамили в угловые скобки. Угловые скобки сообщают компилятору, что указанный файл нужно поискать в стандартных директориях подключаемых файлов. По-умолчанию, такая директория одна, и это scripting/include. Вы можете открыть эту папку и увидеть множество файлов с расширением .inc здесь. Всё это - подключаемые файлы SourceMod, которые включают в себя описание множества функций, тегов и других особенностей, доступных плагинам SourceMod. Подключаемые файлы, по сути, это такой же обычный текст, как и сам код плагинов, потому Вы можете без проблем открыть его любым текстовым редактором и прочитать. Вы можете обратить внимание, однако, что здесь не так много кода, чтобы эти функции SourceMod вообще работали, так как же оно работает? Они реализованы внутри ядра самого SourceMod и написаны на C++, и скомпилированы в двоичные исполняемые файлы, которые размещаются в папке bin. Так как SourcePawn-код и SourceMod-код связываются между собой, если компилятор ничего не знает о существовании последнего? Подключаемые файлы SourceMod реализованы таким образом, чтобы компилятор понимал, что реализация функций будет где-то в другом месте. Компилятор понимает это, и генерирует специальный код, который вызовет внешнюю функцию. Когда SourceMod загружает Ваш плагин, он анализирует этот код и заменяет на вызов своих внутренних функций. Это называется динамическим связыванием.

Устанавливаем информацию о плагине

Теперь, когда мы получили доступ к "фичам" SourceMod, самое время установить информацию, которая отображается через команду sm plugins list. Там нет ни одного "безымянного" плагина. Чтобы сделать это, заглянем внутрь sourcemod.inc и увидим там формат, в котором информация о плагине должна быть объявлена. Всегда полезно заглядывать внутрь включаемых файлов SM, чтобы найти неизвестную Вам информацию. Так же есть документация по API, но она может быть устаревшей, и там есть только файлы ядра SM, так что если Ваш плагин использует любое стороннее расширение или плагин, Вам придётся изучать inc-файлы. Так что, откройте sourcemod.inc, и листайте вниз, пока не увидите это:

/**
 * Plugin public information.
 */
struct Plugin
{
   public const char[] name;		/**< Plugin Name */
   public const char[] description;	/**< Plugin Description */
   public const char[] author;		/**< Plugin Author */
   public const char[] version;		/**< Plugin Version */
   public const char[] url;			/**< Plugin URL */
};

и это:

/**
 * Declare this as a struct in your plugin to expose its information.
 * Example:
 *
 * public Plugin myinfo =
 * {
 *    name = "My Plugin",
 *    //etc
 * };
 */
public Plugin myinfo;

Это говорит нам о том, что нам нужно создать глобальную публичную переменную myinfo, тип которой должен быть Plugin, который является структурой с 5-ью полями, и все - строки. Это может прозвучать сложно для новичка, но это просто. Так что давайте продолжим и создадим:

public Plugin myinfo =
{
	name = "Мой первый плагин",
	author = "Я",
	description = "Мой самый первый плагин",
	version = "1.0",
	url = "http://www.sourcemod.net/"
};

Ключевое слово public говорит о том, что SourceMod будет иметь прямой доступ к нашей переменной. Plugin указывает тип нашей переменной. myinfo, очевидно, имя нашей переменной, как того требует SourceMod. Вы видите, что мы тут же её инициализируем и заполняем данными. Это предпочтительный, и единственный способ рассказать ядру, что за плагин оно загружает.

После всего этого, наш плагин полностью должен выглядеть так:

#include <sourcemod>
 
public Plugin myinfo =
{
	name = "Мой первый плагин",
	author = "Я",
	description = "Мой самый первый плагин",
	version = "1.0",
	url = "http://www.sourcemod.net/"
};

Делая код "запускаемым"

Мы уже включили "фичи" SourceMod и заполнили информацию о нашем плагине. Сейчас мы имеем хороший сформированный плагин, который можно скомпилировать и загрузить с помощью SourceMod. Однако, есть одна проблема - он не делает ничего. У Вас мог возникнуть "соблазн" начать писать код прямо после объявления myinfo, чтобы посмотреть, что он не компилируется. SourcePawn, в отличии от других скриптовых языков, вроде Lua, не разрешает помещать любой код вне функций. После прочтения этого, Вы, скорее всего, захотите объявить какую-нибудь функцию, назвать её, возможно, main, скомпилировать и запустить плагин, и увидеть, что Ваш код никогда не будет вызван. Так как нам сделать, чтобы SourceMod вызывал наш код? Именно по этой причине, у нас есть "форварды". Форварды (Forwards) - прототипы функций, которые объявляются одной стороной, и которые могут быть реализованы - другой, как функции обратного вызова (каллбеки). Когда первая сторона запускает вызов форварда, все остальные, у кого есть объявленный совпадающий каллбек, получают его вызов. SourceMod объявляет множество интересных форвардов, которые мы можем реализовать. Как Вы могли заметить, форварды - единственный способ, чтобы наш код был вызван, держите это в уме. Так что давайте реализуем форвард OnPluginStart. Как Вы могли догадаться, он вызывается, когда наш плагин запускается. Чтобы сделать это, нам нужно посмотреть на объявление OnPluginStart. Она располагается внутри sourcemod.inc, файла, с которым мы уже знакомы, так что давайте найдём её:

/**
 * Called when the plugin is fully initialized and all known external references 
 * are resolved. This is only called once in the lifetime of the plugin, and is 
 * paired with OnPluginEnd().
 *
 * If any run-time error is thrown during this callback, the plugin will be marked 
 * as failed.
 *
 * It is not necessary to close any handles or remove hooks in this function.  
 * SourceMod guarantees that plugin shutdown automatically and correctly releases 
 * all resources.
 *
 * @noreturn
 */
forward void OnPluginStart();

Пустые скобки сообщают нам о том, что внутрь форварда не передаётся ни один аргумент; @noreturn внутри документации сообщает нам, что нам не нужно ничего возвращать. Крайне простой форвард. Так как написать правильный каллбек для этого? Для начала, наш каллбек должен иметь то же самое название, то есть OnPluginStart; во-вторых, наш каллбек должен иметь то же самое кол-во аргументов (в данном случае, ни одного); в-третьих, наш каллбек должен быть помечен ключевым словом public, чтобы SourceMod смог его вызвать. Так что простейшая реализация выглядит так:

public void OnPluginStart()
{
}

Теперь мы можем писать код внутри фигурных скобок. Давайте выведем "Привет, мир!" в серверную консоль. Чтобы сделать это, нам нужно воспользоваться функцией PrintToServer. Она объявлена внутри файла console.inc, однако, нам не нужно включать его, поскольку он уже включен как часть sourcemod.inc.

/**
 * Sends a message to the server console.
 *
 * @param format		Formatting rules.
 * @param ...			Variable number of format parameters.
 * @noreturn
 */
native int PrintToServer(const char[] format, any ...);

Как Вы могли заметить, это "нативная" функция. Она реализована внутри ядра SM. Судя по аргументам, она относится к функциям форматирующего типа. Однако, нам не нужно ничего форматировать сейчас, потому мы просто передадим строку "Привет, мир!", как один-единственный аргумент:

public void OnPluginStart()
{
	PrintToServer("Привет, мир!");
}

Готово! Полный исходный код Вашего плагина должен выглядеть так:

#include <sourcemod>
 
public Plugin myinfo =
{
	name = "Мой первый плагин",
	author = "Я",
	description = "Мой самый первый плагин",
	version = "1.0",
	url = "http://www.sourcemod.net/"
};
 
public void OnPluginStart()
{
	PrintToServer("Привет, мир!");
}

Скомпилируйте и загрузите его на Вашем сервере, и Вы увидите, что сообщение отобразится в серверной консоли.

Включения

Pawn требует включать файлы include, как и C требует наличие заголовка у файла. Включение списков файлов всех структур, функций, вызовы и тегов, которые имеются в наличии. Есть три типа файлов:

• Core - sourcemod.inc, и все его включения. Все представленные в SourceMod Core.
• Extension - добавляет зависимость от определенного расширения.
• Plugin - добавляет зависимость от некоторых плагинов.

Файлы включения загружаются с помощью #include указателя компилятора.

Команды

В Нашем первом примере будет написана простая команда для администратора, чтобы ударить игрока. Мы будем расширять функциональность этого примера, пока не получим окончательный результат, максимально полным.

Описание

Во-первых, давайте смотреть на то, какая команда требуется администратору. Команды администратора регистрируются с использованием функции RegAdminCmd. Она требует название, функцию обратного вызова и флаги админа по умолчанию.

Функция обратного вызова это то, на что ссылаться используемая команда каждый раз. Нажми здесь, чтобы просмотреть её прототип. Пример:

public OnPluginStart()
{
	RegAdminCmd("sm_myslap", Command_MySlap, ADMFLAG_SLAY)
}
 
public Action:Command_MySlap(client, args)
{
}

Теперь Мы успешно обеспечили выполнение команды -- хотя она не будет ничего делать. На самом деле, она скажет "Неизвестная команда", если Вы используете её! Причина в том, что отсутствует Action тег. По умолчанию функция ввода консольных команд заключается в том, чтобы ответить о неизвестной команде. Чтобы заблокировать эту функцию, вы должны создать новое действие:

public Action:Command_MySlap(client, args)
{
	return Plugin_Handled;
}

Теперь команда не будет сообщать об ошибке, но она по-прежнему не будет ничего делать.

Реализация

Давайте решим, что команда будет выглядеть так. Пусть будет она действовать как команда по умолчанию sm_slap:

sm_myslap <name|#userid> [damage]

Чтобы осуществить это, Нам потребуется несколько шагов:

• Получить ввод с консоли. Для этого мы используем GetCmdArg().
• Найти соответствия игрока. Для этого мы используем FindTarget().
• Ударить его. Для этого мы используем SlapPlayer(), которая требует в том числе sdktools расширение в комплекте с SourceMod.
• Сообщить администратору. Для этого мы используем ReplyToCommand().

Полный пример:

#include <sourcemod>
#include <sdktools>
 
public Plugin:myinfo =
{
	name = "Мой первый плагин",
	author = "Я",
	description = "Мой первый супер плагин",
	version = "1.0.0.0",
	url = "http://www.sourcemod.net/"
}
 
public OnPluginStart()
{
	RegAdminCmd("sm_myslap", Command_MySlap, ADMFLAG_SLAY)
}
 
public Action:Command_MySlap(client, args)
{
	new String:arg1[32], String:arg2[32]
	new damage
 
	/* Получаем первый аргумент */
	GetCmdArg(1, arg1, sizeof(arg1))
 
	/* Если есть 2 или более аргументов, и второй аргумент получен
	 * успешно, превратить его в целое.
	 */
	if (args >= 2 && GetCmdArg(2, arg2, sizeof(arg2)))
	{
		damage = StringToInt(arg2)
	}
 
	/* Попытка и нахождение соответствия игрока */
	new target = FindTarget(client, arg1)
	if (target == -1)
	{
		/* FindTarget() автоматически отвечает с
		 * причиной провала.
		 */
		return Plugin_Handled;
	}
 
	SlapPlayer(target, damage)
 
	new String:name[MAX_NAME_LENGTH]
 
	GetClientName(target, name, sizeof(name))
	ReplyToCommand(client, "[SM] Вас ударил %s на %d повреждений!", name, damage)
 
	return Plugin_Handled;
}

Для получения дополнительной информации о том, что такое %s и %d, см. Ru:Format Class Functions. Имейте в виду, что Вам никогда не придется отменять или удалить Ваши команды администратора. Если плагин выгружается, SourceMod очищает их за Вас.

ConVars

ConVars, известные также как cvars, глобальные консольные переменные в движке Source. Они могут иметь целые, десятичные, или строковые значения. Доступ к ConVar осуществляется через дескрипторы (Handles). С тех пор как ConVars имеют глобальный характер, Вам не нужно закрывать дескрипторы ConVar (фактически, Вы и не можете).

Удобная особенность ConVars заключается в том, что они легко настраиваются пользователями. Они могут быть помещены в любой .cfg файл, например server.cfg или sourcemod.cfg. Чтобы сделать удобнее их использование, SourceMod имеет AutoExecConfig() функции. Эта функция автоматически создает .cfg файл по умолчанию, содержащий все Ваши переменные (cvars), снабженные комментариями для пользователей. Очень рекомендую Вам вызывать её, если у Вас есть настраиваемые ConVars.

Давайте усовершенствуем Наш предыдущий пример новой ConVar. ConVar назовём sm_myslap_damage и она будет определять повреждение по умолчанию для удара игрока, если размер повреждений не указан.

new Handle:sm_myslap_damage = INVALID_HANDLE
 
public OnPluginStart()
{
	RegAdminCmd("sm_myslap", Command_MySlap, ADMFLAG_SLAY)
 
	sm_myslap_damage = CreateConVar("sm_myslap_damage", "5", "Повреждение от удара по умолчанию")
	AutoExecConfig(true, "plugin_myslap")
}
 
public Action:Command_MySlap(client, args)
{
	new String:arg1[32], String:arg2[32]
	new damage = GetConVarInt(sm_myslap_damage)
 
	/* Остальное остается без изменений! */

Отображение активности, логирование

Почти все команды администратора должны логировать (записывать в лог) их активность, а некоторые команды администратора должны отобразить свою активность в игре для клиентов. Это может быть сделано через LogAction() и ShowActivity2() функции. Точное функциональность ShowActivity2() определяется sm_show_activity переменной.

Например, давайте перепишем несколько последних строк нашей slap команды:

	SlapPlayer(target, damage)
 
	new String:name[MAX_NAME_LENGTH]
 
	GetClientName(target, name, sizeof(name))
 
	ShowActivity2(client, "[SM] ", "Вас ударил %s на %d повреждений!", name, damage)
	LogAction(client, target, "\"%L\" slapped \"%L\" (damage %d)", client, target, damage)
 
	return Plugin_Handled;
}

Групповые цели

Чтобы полностью завершить нашу демонстрацию slap, давайте сделаем поддержку нескольких целей. Targeting system в SourceMod достаточно усовершенствована, её использование может показаться сложным на первый взгляд.

Мы используем функцию ProcessTargetString(). Он принимает ввод с консоли, и возвращает список подходящих клиентов. Она также возвращает существительное, которые будет определять либо одного клиента или характеризовать список клиентов. Идея заключается в том, что каждый клиент будет обработан, но активность будет показана всем игрокам только один раз. Это уменьшит спам на экране.

Этот метод обработки цели используется почти каждой командой администратора в SourceMod, а на самом деле FindTarget() является лишь упрощенной версией.

Полный, окончательный пример:

#include <sourcemod>
#include <sdktools>
 
new Handle:sm_myslap_damage = INVALID_HANDLE
 
public Plugin:myinfo =
{
	name = "Мой первый плагин",
	author = "Я",
	description = "Мой первый супер плагин",
	version = "1.0.0.0",
	url = "http://www.sourcemod.net/"
}
 
public OnPluginStart()
{
	LoadTranslations("common.phrases")
	RegAdminCmd("sm_myslap", Command_MySlap, ADMFLAG_SLAY)
 
	sm_myslap_damage = CreateConVar("sm_myslap_damage", "5", "Повреждение от удара по умолчанию")
	AutoExecConfig(true, "plugin_myslap")
}
 
public Action:Command_MySlap(client, args)
{
	new String:arg1[32], String:arg2[32]
	new damage = GetConVarInt(sm_myslap_damage)
 
	/* Получаем первый аргумент */
	GetCmdArg(1, arg1, sizeof(arg1))
 
	/* Если есть 2 или более аргументов, и второй аргумент получен
	 * успешно, превратить его в целое.
	 */
	if (args >= 2 && GetCmdArg(2, arg2, sizeof(arg2)))
	{
		damage = StringToInt(arg2)
	}
 
	/**
	 * target_name - сохраняет существительные установленной цели(ей)
	 * target_list - массив для хранения клиентов
	 * target_count - переменная для хранения числа клиентов
	 * tn_is_ml - сохраняет должно ли существительное быть переведено
	 */
	new String:target_name[MAX_TARGET_LENGTH]
	new target_list[MAXPLAYERS], target_count
	new bool:tn_is_ml
 
	if ((target_count = ProcessTargetString(
			arg1,
			client,
			target_list,
			MAXPLAYERS,
			COMMAND_FILTER_ALIVE, /* Разрешено только живым игрокам */
			target_name,
			sizeof(target_name),
			tn_is_ml)) <= 0)
	{
		/* Эта функция отвечает администратору сообщение о неудачи */
		ReplyToTargetError(client, target_count);
		return Plugin_Handled;
	}
 
	for (new i = 0; i < target_count; i++)
	{
		SlapPlayer(target_list[i], damage)
		LogAction(client, target_list[i], "\"%L\" slapped \"%L\" (damage %d)", client, target_list[i], damage)
	}
 
	if (tn_is_ml)
	{
		ShowActivity2(client, "[SM] ", "Slapped %t for %d damage!", target_name, damage)
	}
	else
	{
		ShowActivity2(client, "[SM] ", "Slapped %s for %d damage!", target_name, damage)
	}
 
	return Plugin_Handled;
}

Клиентский и объектный индексы

Одним основным вопросом путаницы с Half-Life 2 является разница между следующими вещами:

• Индекс клиента (Client index)
• Индекс объекта (Entity index)
• Идентификатор пользователя (Userid)

Первый ответ заключается в том, что клиенты это объекты. Таким образом, индекс клиента и индекс объекта одно и тоже. Когда SourceMod функция запрашивает индекс объекта, индекс клиента может быть указан. Когда SourceMod функция запрашивает индекс клиента, как правило, это означает, что только индекс клиента может быть указан.

Быстрый способ проверить является ли индекс объекта клиентом - проверить находится ли он между 1 и GetMaxClients() (включительно). Если сервер имеет максимум N клиентских слотов, то объекты с 1 по N, всегда зарезервированы для клиентов. Заметим, что 0 - верный индекс объекта; он является общим объектом (worldspawn).

Идентификатор пользователя, это абсолютно другое. Сервер поддерживает общее "число соединений", и оно начинается с 1. Каждый раз, когда подключается новый клиент, общее число соединений увеличивается, и клиент получает новый номер, называемый идентификатором пользователя.

Например, первый подключившийся клиент имеет идентификатор пользователя 2. Если он вышел и соединился заново, его идентификатор будет 3 (если другие клиенты не подключились в этот период). Since clients are disconnected on mapchange, their userids change as well. Userids are a handy way to check if a client's connection status has changed.

SourceMod предусматривает две функции для userid: GetClientOfUserId() и GetClientUserId().

События

События являются информационными сообщениями передаваемые между объектами на сервере. Многие так же передаются от сервера к клиенту. Они определены в .res файлах в папке hl2/resource и папке resource конкретных модов. Основной список смотрите здесь Source Game Events.

Важно отметить некоторые особенности событий:

• Они почти всегда носят информационных характер. Т.е., блокирование player_death не остановит смерть игрока. Он может заблокировать HUD или консольное сообщение или что то незначительное.
• Они всегда используют userid вместо индексов клиента(client indexes).
• То что они находятся в файле ресурсов не означает что они когда-либо будут вызываться или работать так как вы ожидаете. Моды, как известно, не должным образом документируют функционирование своих событий.

Пример обнаружения, когда игрок умирает:

public OnPluginStart()
{
   HookEvent("player_death", Event_PlayerDeath)
}
 
public Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
   new victim_id = GetEventInt(event, "userid")
   new attacker_id = GetEventInt(event, "attacker")
 
   new victim = GetClientOfUserId(victim_id)
   new attacker = GetClientOfUserId(attacker_id)
 
   /* CODE */
}

Callback Orders and Pairing

SourceMod has a number of builtin callbacks about the state of the server and plugin. Some of these are paired in special ways which is confusing to users.

Pairing

Pairing is SourceMod terminology. Examples of it are:

• OnMapEnd() cannot be called without an OnMapStart(), and if OnMapStart() is called, it cannot be called again without an OnMapEnd().
• OnClientConnected(N) for a given client N will only be called once, until an OnClientDisconnected(N) for the same client N is called (which is guaranteed to happen).

There is a formal definition of SourceMod's pairing. For two functions X and Y, both with input A, the following conditions hold:

• If X is invoked with input A, it cannot be invoked again with the same input unless Y is called with input A.
• If X is invoked with input A, it is guaranteed that Y will, at some point, be called with input A.
• Y cannot be invoked with any input A unless X was called first with input A.
• The relationship is described as, "X is paired with Y," and "Y is paired to X."

General Callbacks

These callbacks are listed in the order they are called, in the lifetime of a plugin and the server.

• AskPluginLoad() - Called once, immediately after the plugin is loaded from the disk.
• OnPluginStart() - Called once, after the plugin has been fully initialized and can proceed to load. Any run-time errors in this function will cause the plugin to fail to load. This is paired with OnPluginEnd().
• OnMapStart() - Called every time the map loads. If the plugin is loaded late, and the map has already started, this function is called anyway after load, in order to preserve pairing. This function is paired with OnMapEnd().
• OnConfigsExecuted() - Called once per map-change after servercfgfile (usually server.cfg), sourcemod.cfg, and all plugin config files have finished executing. If a plugin is loaded after this has happened, the callback is called anyway, in order to preserve pairing. This function is paired with OnMapEnd().
• At this point, most game callbacks can occur, such as events and callbacks involving clients (or other things, like OnGameFrame).
• OnMapEnd() - Called when the map is about to end. At this point, all clients are disconnected, but TIMER_NO_MAPCHANGE timers are not yet destroyed. This function is paired to OnMapStart().
• OnPluginEnd() - Called once, immediately before the plugin is unloaded. This function is paired to OnPluginStart().

Client Callbacks

These callbacks are listed in no specific order, however, their documentation holds for both fake and real clients.

• OnClientConnect() - Called when a player initiates a connection. This is paired with OnClientDisconnect() for successful connections only.
• OnClientAuthorized() - Called when a player gets a Steam ID. It is important to note that this may never be called. It may occur any time in between connect and disconnect. Do not rely on it unless you are writing something that needs Steam IDs, and even then you should use OnClientPostAdminCheck().
• OnClientPutInServer() - Signifies that the player is in-game and IsClientInGame() will return true.
• OnClientPostAdminCheck() - Called after the player is both authorized and in-game. That is, both OnClientAuthorized() and OnClientPutInServer() have been invoked. This is the best callback for checking administrative access after connect.
• OnClientDisconnect() - Called when a player's disconnection ends. This is paired to OnClientConnect().

Frequently Asked Questions

Are plugins reloaded every mapchange?

Plugins, by default, are not reloaded on mapchange unless their timestamp changes. This is a feature so plugin authors have more flexibility with the state of their plugins.

Do I need to call CloseHandle in OnPluginEnd?

No. SourceMod automatically closes your Handles when your plugin is unloaded, in order to prevent memory errors.

Do I need to #include every individual .inc?

No. #include <sourcemod> will give you 95% of the .incs. Similarly, #include <sdktools> includes everything starting with <sdktools>.

Why don't some events fire?

There is no guarantee that events will fire. The event listing is not a specification, it is a list of the events that a game is capable of firing. Whether the game actually fires them is up to Valve or the developer.

Do I need to CloseHandle timers?

No. In fact, doing so may cause errors. Timers naturally die on their own unless they are infinite timers, in which case you can use KillTimer() or die gracefully by returning Plugin_Stop in the callback.

Are clients disconnected on mapchange?

All clients are fully disconnected before the map changes. They are all reconnected after the next map starts.

Продолжение обучения

Для дальнейшего обучения, смотри раздел "Scripting" в Ru:SourceMod Documentation.