AlliedModders Wiki - User contributions [en]

Ru:KeyValues (SourceMod Scripting)

2010-12-25T05:23:17Z

V1KT0P: /* Deletion */

KeyValues это простая древовидная структура используемая для хранения вложенных разделов состоящих из пар ключ/значение. Детальная информация про KeyValues может быть найдена на [http://developer.valvesoftware.com/wiki/KeyValues_class Valve Developer Wiki].

Все KeyValues функции в этом документе находятся в <tt>public/include/keyvalues.inc</tt>.

=Введение=
KeyValues состоит из ''узлов'' и ''разделов'', которые содержат пары ключей и значений. Разделы выглядят примерно так:
<pre>"раздел"
{
"ключ" "значение"
}</pre>

Сторка <tt>"раздел"</tt> является именем раздела. Строка <tt>"ключ"</tt> это имя ключа и строка <tt>"значение"</tt>" является значением.

KeyValues структуры создаются с помощью <tt>CreateKeyValues()</tt>. Handle должен быть освобожден после завершения работы для устранения утечки памяти.

=Файлы=
KeyValues могут быть экспортированы и импортированы с помощью KeyValues файлов. Эти файлы всегда состоят из главного узла и множества под-ключей или подразделов. Например файл может выглядеть вот так:
<pre>"MyFile"
{
"STEAM_0:0:7"
{
"name" "crab"
}
}</pre>

В этом примере <tt>STEAM_0:0:7</tt> это раздел под главным узлом <tt>MyFile</tt>.

Для загрузки KeyValues из файла используйте <tt>FileToKeyValues</tt>. Для сохранения KeyValues в файл используйте <tt>KeyValuesFromFile</tt>. Для обоих случае вы всегда должны иметь Handle ссылающийся на KeyValues структуру.

=Перемещение=
SourceMod обеспечивает нативное перемещение по KeyValues структуре. Однако очень важно понимать как происходит это перемещение. Внутренне, SourceMod отслеживает из двух частей информации:
*Главный узел
*Стек перемещения

Поскольку структура KeyValues изначально рекурсивная (это дерево), ''стек перемещения'' используется для сохранения истории каждого ''перемещения'' (перемещение начинается рекурсивно погружаться в дерево, где текущий уровень вложенности углубляется на одну секцию). ''верх'' этого стека где все операции имеют место..

Например, <tt>KvJumpToKey</tt> будет пытаться найтим под-ключ под текущим разделом. При успехе позиция в дереве изменяется перемещением вниз на один уровень, и, следовательно, эта позиция помещается в стек перемещения. Теперь операции такие как <tt>KvGetString</tt> будут использовать эту новую позицию.

Это нативные изменяют положение, но не меняют стек перемещения. Например, <tt>KvGotoNextKey</tt> будет менять текущий раздел перед просмотром, но это не является push/pop операциями для стека перемещения. Это потому, что уровень вложенности не изменился; он проходит в следующий раздел на том же уровне, скорее чем найти секцию уровнем глубже.

Больше нативных перемещений:
*<tt>KvGotoFirstSubKey</tt> - Находит первый подраздел ниже текущей позиции. Это помещает раздел на стек перемещения.
*<tt>KvGoBack</tt> - Берет из стека перемещения (поднимается на уровень выше).
*<tt>KvRewind</tt> - Стирает из стека перемещения текущую позицию в главном узле.

==Основной Просмотр==
Давайте возьмем наш пример <tt>MyFile</tt>. Как мы можем получить имя "crab" учитывая Steam ID?

<pawn>bool:GetNameFromSteamID(const String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");
if (!KvJumpToKey(kv, steamid))
{
return false;
}
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}</pawn>

'''Обратите внимание:''' <tt>KvJumpToKey</tt> является нативным перемещением, что изменения уровней вложенности стека перемещения. Однако <tt>CloseHandle</tt> не будет случайно закрывать текущий уровень структуры KeyValues. Это закроет всю вещь.

==Повторяющийся Просмотр==
Давайте модифицируер предыдущий пример для использования повторов. Это имеет ту же функциональность, но демонстрирует, как для просмотра в течение многих разделах.

<pawn>bool:GetNameFromSteamID(const String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");

if (!KvGotoFirstSubKey(kv))
{
return false;
}

decl String:buffer[255];
do
{
KvGetSectionName(kv, buffer, sizeof(buffer));
if (StrEqual(buffer, steamid))
{
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}
} while (KvGotoNextKey(kv));

CloseHandle(kv)
return false
}</pawn>

'''Обратите внимание:''' В этом примере отметим что <tt>KvGotoNextKey</tt> является итеративной функции, не однократное перемещение. Так как это не меняет уровень вложенности, мы не должны вызывать <tt>KvGoBack</tt> для возврата и продолжения итерации.

==Полное Перемещение==
Например мы хотим просмотреть каждую секцию файла KeyValues. Пример как это может выглядеть:
<pawn>BrowseKeyValues(Handle:kv)
{
do
{
if (KvGotoFirstSubKey(kv))
{
BrowseKeyValues(kv);
KvGoBack(kv);
}
} while (KvGotoNextKey(kv));
}</pawn>

Эта функция будет просматривать всю структуру KeyValues. Обратите внимаеие, что каждый успешный вызов <tt>KvGotoFirstSubKey</tt> сопровождается вызовом <tt>KvGoBack</tt>. Это потому, что первый помещается в стек перемещения. Мы должны взять позицию для того, чтоб могли продолжить просмотр с нашей старой позиции.

=Удаление=
Есть два пути для удаления секции из структуры KeyValues:
*<tt>KvDeleteKey</tt> - Безопасное удаление имени подраздела и все дочерние секции/ключи.
*<tt>KvDeleteThis</tt> - Безопасное удаление текущей позиции, если это возможно.

==Простое Удаление==
Для начала используем наш пример "базовый просмотр" для удаления секции Steam ID:
<pawn>RemoveSteamID(const String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")
if (!KvGotoFirstSubKey(kv))
{
return
}
KvDeleteKey(kv, steamid)
KvRewind(kv)
KeyValuesToFile(kv, "myfile.txt")
CloseHandle(kv)
}</pawn>

'''Обратите внимание:''' Мы вызвали <tt>KvRewind</tt> так файл будет сбрасываться с корневой позиции, вместо текущей.

==Повторяющееся Удаление==
Кроме того давайте покажем как ранее повторяющийся пример может быть адаптирован для удаления раздела. Для этого мы используем <tt>KvDeleteThis</tt>, который удаляет текущую позицию из предыдущей позиции в стеке перемещения.

<pawn>RemoveSteamID(const String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")

if (!KvGotoFirstSubKey(kv))
{
return
}

decl String:buffer[255]
do
{
KvGetSectionName(kv, buffer, sizeof(buffer))
if (StrEqual(buffer, steamid))
{
KvDeleteThis(kv)
CloseHandle(kv)
return
}
} while (KvGotoNextKey(kv))

CloseHandle(kv)
}</pawn>

==Полное Удаление==
Наконец давайте посмотрим как удалить все (или некоторые) ключи. <tt>KvDeleteThis</tt> как особое свойство которое может действовать в качестве автоматического итератора. Когда удаляется ключ автоматически переходим к следующему, как если бы вызвали <tt>KvGotoNextKey</tt>. Если больше нет ключей просто берет стек перемещения.

Пример удаление всех SteamID-ов содержащие пустые имена:
<pawn>DeleteAll(Handle:kv)
{
if (!KvGotoFirstSubKey(kv))
{
return
}

for (;;)
{
decl String:name[4]
KvGetString(kv, name, sizeof(name))
if (name[0] == '\0')
{
if (KvDeleteThis(kv) < 1)
{
break
}
} else if (!KvGotoNextKey(kv)) {
break
}
}
}</pawn>

Хотя это и выглядет как бесконечный цикл, это не так. Как только <tt>KvDeleteThis</tt> вернет неудачу при нахождении ключа, произойдет разрыв цекла. Аналогично, если <tt>KvGotoNextKey</tt> вернет неудачу, цикл закончится.

[[Category:Ru:SourceMod Scripting]]

Ru:KeyValues (SourceMod Scripting)

2010-12-25T05:16:17Z

V1KT0P: /* Повторяющийся просмотр */

KeyValues это простая древовидная структура используемая для хранения вложенных разделов состоящих из пар ключ/значение. Детальная информация про KeyValues может быть найдена на [http://developer.valvesoftware.com/wiki/KeyValues_class Valve Developer Wiki].

Все KeyValues функции в этом документе находятся в <tt>public/include/keyvalues.inc</tt>.

=Введение=
KeyValues состоит из ''узлов'' и ''разделов'', которые содержат пары ключей и значений. Разделы выглядят примерно так:
<pre>"раздел"
{
"ключ" "значение"
}</pre>

Сторка <tt>"раздел"</tt> является именем раздела. Строка <tt>"ключ"</tt> это имя ключа и строка <tt>"значение"</tt>" является значением.

KeyValues структуры создаются с помощью <tt>CreateKeyValues()</tt>. Handle должен быть освобожден после завершения работы для устранения утечки памяти.

=Файлы=
KeyValues могут быть экспортированы и импортированы с помощью KeyValues файлов. Эти файлы всегда состоят из главного узла и множества под-ключей или подразделов. Например файл может выглядеть вот так:
<pre>"MyFile"
{
"STEAM_0:0:7"
{
"name" "crab"
}
}</pre>

В этом примере <tt>STEAM_0:0:7</tt> это раздел под главным узлом <tt>MyFile</tt>.

Для загрузки KeyValues из файла используйте <tt>FileToKeyValues</tt>. Для сохранения KeyValues в файл используйте <tt>KeyValuesFromFile</tt>. Для обоих случае вы всегда должны иметь Handle ссылающийся на KeyValues структуру.

=Перемещение=
SourceMod обеспечивает нативное перемещение по KeyValues структуре. Однако очень важно понимать как происходит это перемещение. Внутренне, SourceMod отслеживает из двух частей информации:
*Главный узел
*Стек перемещения

Поскольку структура KeyValues изначально рекурсивная (это дерево), ''стек перемещения'' используется для сохранения истории каждого ''перемещения'' (перемещение начинается рекурсивно погружаться в дерево, где текущий уровень вложенности углубляется на одну секцию). ''верх'' этого стека где все операции имеют место..

Например, <tt>KvJumpToKey</tt> будет пытаться найтим под-ключ под текущим разделом. При успехе позиция в дереве изменяется перемещением вниз на один уровень, и, следовательно, эта позиция помещается в стек перемещения. Теперь операции такие как <tt>KvGetString</tt> будут использовать эту новую позицию.

Это нативные изменяют положение, но не меняют стек перемещения. Например, <tt>KvGotoNextKey</tt> будет менять текущий раздел перед просмотром, но это не является push/pop операциями для стека перемещения. Это потому, что уровень вложенности не изменился; он проходит в следующий раздел на том же уровне, скорее чем найти секцию уровнем глубже.

Больше нативных перемещений:
*<tt>KvGotoFirstSubKey</tt> - Находит первый подраздел ниже текущей позиции. Это помещает раздел на стек перемещения.
*<tt>KvGoBack</tt> - Берет из стека перемещения (поднимается на уровень выше).
*<tt>KvRewind</tt> - Стирает из стека перемещения текущую позицию в главном узле.

==Основной Просмотр==
Давайте возьмем наш пример <tt>MyFile</tt>. Как мы можем получить имя "crab" учитывая Steam ID?

<pawn>bool:GetNameFromSteamID(const String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");
if (!KvJumpToKey(kv, steamid))
{
return false;
}
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}</pawn>

'''Обратите внимание:''' <tt>KvJumpToKey</tt> является нативным перемещением, что изменения уровней вложенности стека перемещения. Однако <tt>CloseHandle</tt> не будет случайно закрывать текущий уровень структуры KeyValues. Это закроет всю вещь.

==Повторяющийся Просмотр==
Давайте модифицируер предыдущий пример для использования повторов. Это имеет ту же функциональность, но демонстрирует, как для просмотра в течение многих разделах.

<pawn>bool:GetNameFromSteamID(const String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");

if (!KvGotoFirstSubKey(kv))
{
return false;
}

decl String:buffer[255];
do
{
KvGetSectionName(kv, buffer, sizeof(buffer));
if (StrEqual(buffer, steamid))
{
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}
} while (KvGotoNextKey(kv));

CloseHandle(kv)
return false
}</pawn>

'''Обратите внимание:''' В этом примере отметим что <tt>KvGotoNextKey</tt> является итеративной функции, не однократное перемещение. Так как это не меняет уровень вложенности, мы не должны вызывать <tt>KvGoBack</tt> для возврата и продолжения итерации.

==Полное Перемещение==
Например мы хотим просмотреть каждую секцию файла KeyValues. Пример как это может выглядеть:
<pawn>BrowseKeyValues(Handle:kv)
{
do
{
if (KvGotoFirstSubKey(kv))
{
BrowseKeyValues(kv);
KvGoBack(kv);
}
} while (KvGotoNextKey(kv));
}</pawn>

Эта функция будет просматривать всю структуру KeyValues. Обратите внимаеие, что каждый успешный вызов <tt>KvGotoFirstSubKey</tt> сопровождается вызовом <tt>KvGoBack</tt>. Это потому, что первый помещается в стек перемещения. Мы должны взять позицию для того, чтоб могли продолжить просмотр с нашей старой позиции.

=Deletion=
There are two ways to delete sections from a KeyValues structure:
*<tt>KvDeleteKey</tt> - Safely removes a named sub-section and any of its child sections/keys.
*<tt>KvDeleteThis</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 String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")
if (!KvGotoFirstSubKey(kv))
{
return
}
KvDeleteKey(kv, steamid)
KvRewind(kv)
KeyValuesToFile(kv, "myfile.txt")
CloseHandle(kv)
}</pawn>

'''Note:''' We called <tt>KvRewind</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>KvDeleteThis</tt>, which deletes the current position from the previous position in the traversal stack.

<pawn>RemoveSteamID(const String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")

if (!KvGotoFirstSubKey(kv))
{
return
}

decl String:buffer[255]
do
{
KvGetSectionName(kv, buffer, sizeof(buffer))
if (StrEqual(buffer, steamid))
{
KvDeleteThis(kv)
CloseHandle(kv)
return
}
} while (KvGotoNextKey(kv))

CloseHandle(kv)
}</pawn>

==Full Deletion==
Lastly, let's take a look at how we would delete all (or some) keys. <tt>KvDeleteThis</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>KvGotoNextKey</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(Handle:kv)
{
if (!KvGotoFirstSubKey(kv))
{
return
}

for (;;)
{
decl String:name[4]
KvGetString(kv, name, sizeof(name))
if (name[0] == '\0')
{
if (KvDeleteThis(kv) < 1)
{
break
}
} else if (!KvGotoNextKey(kv)) {
break
}
}
}</pawn>

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

[[Category:Ru:SourceMod Scripting]]

Ru:KeyValues (SourceMod Scripting)

2010-12-25T05:11:15Z

V1KT0P: /* Перемещение */

KeyValues это простая древовидная структура используемая для хранения вложенных разделов состоящих из пар ключ/значение. Детальная информация про KeyValues может быть найдена на [http://developer.valvesoftware.com/wiki/KeyValues_class Valve Developer Wiki].

Все KeyValues функции в этом документе находятся в <tt>public/include/keyvalues.inc</tt>.

=Введение=
KeyValues состоит из ''узлов'' и ''разделов'', которые содержат пары ключей и значений. Разделы выглядят примерно так:
<pre>"раздел"
{
"ключ" "значение"
}</pre>

Сторка <tt>"раздел"</tt> является именем раздела. Строка <tt>"ключ"</tt> это имя ключа и строка <tt>"значение"</tt>" является значением.

KeyValues структуры создаются с помощью <tt>CreateKeyValues()</tt>. Handle должен быть освобожден после завершения работы для устранения утечки памяти.

=Файлы=
KeyValues могут быть экспортированы и импортированы с помощью KeyValues файлов. Эти файлы всегда состоят из главного узла и множества под-ключей или подразделов. Например файл может выглядеть вот так:
<pre>"MyFile"
{
"STEAM_0:0:7"
{
"name" "crab"
}
}</pre>

В этом примере <tt>STEAM_0:0:7</tt> это раздел под главным узлом <tt>MyFile</tt>.

Для загрузки KeyValues из файла используйте <tt>FileToKeyValues</tt>. Для сохранения KeyValues в файл используйте <tt>KeyValuesFromFile</tt>. Для обоих случае вы всегда должны иметь Handle ссылающийся на KeyValues структуру.

=Перемещение=
SourceMod обеспечивает нативное перемещение по KeyValues структуре. Однако очень важно понимать как происходит это перемещение. Внутренне, SourceMod отслеживает из двух частей информации:
*Главный узел
*Стек перемещения

Поскольку структура KeyValues изначально рекурсивная (это дерево), ''стек перемещения'' используется для сохранения истории каждого ''перемещения'' (перемещение начинается рекурсивно погружаться в дерево, где текущий уровень вложенности углубляется на одну секцию). ''верх'' этого стека где все операции имеют место..

Например, <tt>KvJumpToKey</tt> будет пытаться найтим под-ключ под текущим разделом. При успехе позиция в дереве изменяется перемещением вниз на один уровень, и, следовательно, эта позиция помещается в стек перемещения. Теперь операции такие как <tt>KvGetString</tt> будут использовать эту новую позицию.

Это нативные изменяют положение, но не меняют стек перемещения. Например, <tt>KvGotoNextKey</tt> будет менять текущий раздел перед просмотром, но это не является push/pop операциями для стека перемещения. Это потому, что уровень вложенности не изменился; он проходит в следующий раздел на том же уровне, скорее чем найти секцию уровнем глубже.

Больше нативных перемещений:
*<tt>KvGotoFirstSubKey</tt> - Находит первый подраздел ниже текущей позиции. Это помещает раздел на стек перемещения.
*<tt>KvGoBack</tt> - Берет из стека перемещения (поднимается на уровень выше).
*<tt>KvRewind</tt> - Стирает из стека перемещения текущую позицию в главном узле.

==Основной Просмотр==
Давайте возьмем наш пример <tt>MyFile</tt>. Как мы можем получить имя "crab" учитывая Steam ID?

<pawn>bool:GetNameFromSteamID(const String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");
if (!KvJumpToKey(kv, steamid))
{
return false;
}
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}</pawn>

'''Обратите внимание:''' <tt>KvJumpToKey</tt> является нативным перемещением, что изменения уровней вложенности стека перемещения. Однако <tt>CloseHandle</tt> не будет случайно закрывать текущий уровень структуры KeyValues. Это закроет всю вещь.

==Повторяющийся просмотр==
Давайте модифицируер предыдущий пример для использования повторов. Это имеет ту же функциональность, но демонстрирует, как для просмотра в течение многих разделах.

<pawn>bool:GetNameFromSteamID(const String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");

if (!KvGotoFirstSubKey(kv))
{
return false;
}

decl String:buffer[255];
do
{
KvGetSectionName(kv, buffer, sizeof(buffer));
if (StrEqual(buffer, steamid))
{
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}
} while (KvGotoNextKey(kv));

CloseHandle(kv)
return false
}</pawn>

'''Обратите внимание:''' В этом примере отметим что <tt>KvGotoNextKey</tt> является итеративной функции, не однократное перемещение. Так как это не меняет уровень вложенности, мы не должны вызывать <tt>KvGoBack</tt> для возврата и продолжения итерации.

==Полное Перемещение==
Например мы хотим просмотреть каждую секцию файла KeyValues. Пример как это может выглядеть:
<pawn>BrowseKeyValues(Handle:kv)
{
do
{
if (KvGotoFirstSubKey(kv))
{
BrowseKeyValues(kv);
KvGoBack(kv);
}
} while (KvGotoNextKey(kv));
}</pawn>

Эта функция будет просматривать всю структуру KeyValues. Обратите внимаеие, что каждый успешный вызов <tt>KvGotoFirstSubKey</tt> сопровождается вызовом <tt>KvGoBack</tt>. Это потому, что первый помещается в стек перемещения. Мы должны взять позицию для того, чтоб могли продолжить просмотр с нашей старой позиции.

=Deletion=
There are two ways to delete sections from a KeyValues structure:
*<tt>KvDeleteKey</tt> - Safely removes a named sub-section and any of its child sections/keys.
*<tt>KvDeleteThis</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 String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")
if (!KvGotoFirstSubKey(kv))
{
return
}
KvDeleteKey(kv, steamid)
KvRewind(kv)
KeyValuesToFile(kv, "myfile.txt")
CloseHandle(kv)
}</pawn>

'''Note:''' We called <tt>KvRewind</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>KvDeleteThis</tt>, which deletes the current position from the previous position in the traversal stack.

<pawn>RemoveSteamID(const String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")

if (!KvGotoFirstSubKey(kv))
{
return
}

decl String:buffer[255]
do
{
KvGetSectionName(kv, buffer, sizeof(buffer))
if (StrEqual(buffer, steamid))
{
KvDeleteThis(kv)
CloseHandle(kv)
return
}
} while (KvGotoNextKey(kv))

CloseHandle(kv)
}</pawn>

==Full Deletion==
Lastly, let's take a look at how we would delete all (or some) keys. <tt>KvDeleteThis</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>KvGotoNextKey</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(Handle:kv)
{
if (!KvGotoFirstSubKey(kv))
{
return
}

for (;;)
{
decl String:name[4]
KvGetString(kv, name, sizeof(name))
if (name[0] == '\0')
{
if (KvDeleteThis(kv) < 1)
{
break
}
} else if (!KvGotoNextKey(kv)) {
break
}
}
}</pawn>

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

[[Category:Ru:SourceMod Scripting]]

Ru:KeyValues (SourceMod Scripting)

2010-12-25T04:48:25Z

V1KT0P: /* Перемещение */

KeyValues это простая древовидная структура используемая для хранения вложенных разделов состоящих из пар ключ/значение. Детальная информация про KeyValues может быть найдена на [http://developer.valvesoftware.com/wiki/KeyValues_class Valve Developer Wiki].

Все KeyValues функции в этом документе находятся в <tt>public/include/keyvalues.inc</tt>.

=Введение=
KeyValues состоит из ''узлов'' и ''разделов'', которые содержат пары ключей и значений. Разделы выглядят примерно так:
<pre>"раздел"
{
"ключ" "значение"
}</pre>

Сторка <tt>"раздел"</tt> является именем раздела. Строка <tt>"ключ"</tt> это имя ключа и строка <tt>"значение"</tt>" является значением.

KeyValues структуры создаются с помощью <tt>CreateKeyValues()</tt>. Handle должен быть освобожден после завершения работы для устранения утечки памяти.

=Файлы=
KeyValues могут быть экспортированы и импортированы с помощью KeyValues файлов. Эти файлы всегда состоят из главного узла и множества под-ключей или подразделов. Например файл может выглядеть вот так:
<pre>"MyFile"
{
"STEAM_0:0:7"
{
"name" "crab"
}
}</pre>

В этом примере <tt>STEAM_0:0:7</tt> это раздел под главным узлом <tt>MyFile</tt>.

Для загрузки KeyValues из файла используйте <tt>FileToKeyValues</tt>. Для сохранения KeyValues в файл используйте <tt>KeyValuesFromFile</tt>. Для обоих случае вы всегда должны иметь Handle ссылающийся на KeyValues структуру.

=Перемещение=
SourceMod обеспечивает нативное перемещение по KeyValues структуре. Однако очень важно понимать как происходит это перемещение. Внутренне, SourceMod отслеживает из двух частей информации:
*Главный узел
*Стек перемещения

Поскольку структура KeyValues изначально рекурсивная (это дерево), ''стек перемещения'' используется для сохранения истории каждого ''перемещения'' (перемещение начинается рекурсивно погружаться в дерево, где текущий уровень вложенности углубляется на одну секцию). ''верх'' этого стека где все операции имеют место..

Например, <tt>KvJumpToKey</tt> будет пытаться найтим под-ключ под текущим разделом. При успехе позиция в дереве изменяется перемещением вниз на один уровень, и, следовательно, эта позиция помещается в стек перемещения. Теперь операции такие как <tt>KvGetString</tt> будут использовать эту новую позицию.

There are natives which change the position but do not change the traversal stack. For example, <tt>KvGotoNextKey</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>KvGotoFirstSubKey</tt> - Finds the first sub-section under the current section. This pushes the section onto the traversal stack.
*<tt>KvGoBack</tt> - Pops the traversal stack (moves up one level).
*<tt>KvRewind</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 String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");
if (!KvJumpToKey(kv, steamid))
{
return false;
}
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}</pawn>

'''Note:''' <tt>KvJumpToKey</tt> is a traversal native that changes the nesting level of the traversal stack. However, <tt>CloseHandle</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 String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");

if (!KvGotoFirstSubKey(kv))
{
return false;
}

decl String:buffer[255];
do
{
KvGetSectionName(kv, buffer, sizeof(buffer));
if (StrEqual(buffer, steamid))
{
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}
} while (KvGotoNextKey(kv));

CloseHandle(kv)
return false
}</pawn>

'''Note:''' In this example, note that <tt>KvGotoNextKey</tt> is an iterative function, not a traversal one. Since it does not change the nesting level, we don't need to call <tt>KvGoBack</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(Handle:kv)
{
do
{
if (KvGotoFirstSubKey(kv))
{
BrowseKeyValues(kv);
KvGoBack(kv);
}
} while (KvGotoNextKey(kv));
}</pawn>

This function will browse an entire KeyValues structure. Note that every successful call to <tt>KvGotoFirstSubKey</tt> is paired with a call to <tt>KvGoBack</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.

=Deletion=
There are two ways to delete sections from a KeyValues structure:
*<tt>KvDeleteKey</tt> - Safely removes a named sub-section and any of its child sections/keys.
*<tt>KvDeleteThis</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 String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")
if (!KvGotoFirstSubKey(kv))
{
return
}
KvDeleteKey(kv, steamid)
KvRewind(kv)
KeyValuesToFile(kv, "myfile.txt")
CloseHandle(kv)
}</pawn>

'''Note:''' We called <tt>KvRewind</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>KvDeleteThis</tt>, which deletes the current position from the previous position in the traversal stack.

<pawn>RemoveSteamID(const String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")

if (!KvGotoFirstSubKey(kv))
{
return
}

decl String:buffer[255]
do
{
KvGetSectionName(kv, buffer, sizeof(buffer))
if (StrEqual(buffer, steamid))
{
KvDeleteThis(kv)
CloseHandle(kv)
return
}
} while (KvGotoNextKey(kv))

CloseHandle(kv)
}</pawn>

==Full Deletion==
Lastly, let's take a look at how we would delete all (or some) keys. <tt>KvDeleteThis</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>KvGotoNextKey</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(Handle:kv)
{
if (!KvGotoFirstSubKey(kv))
{
return
}

for (;;)
{
decl String:name[4]
KvGetString(kv, name, sizeof(name))
if (name[0] == '\0')
{
if (KvDeleteThis(kv) < 1)
{
break
}
} else if (!KvGotoNextKey(kv)) {
break
}
}
}</pawn>

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

[[Category:Ru:SourceMod Scripting]]

Ru:KeyValues (SourceMod Scripting)

2010-12-25T04:44:20Z

V1KT0P:

KeyValues это простая древовидная структура используемая для хранения вложенных разделов состоящих из пар ключ/значение. Детальная информация про KeyValues может быть найдена на [http://developer.valvesoftware.com/wiki/KeyValues_class Valve Developer Wiki].

Все KeyValues функции в этом документе находятся в <tt>public/include/keyvalues.inc</tt>.

=Введение=
KeyValues состоит из ''узлов'' и ''разделов'', которые содержат пары ключей и значений. Разделы выглядят примерно так:
<pre>"раздел"
{
"ключ" "значение"
}</pre>

Сторка <tt>"раздел"</tt> является именем раздела. Строка <tt>"ключ"</tt> это имя ключа и строка <tt>"значение"</tt>" является значением.

KeyValues структуры создаются с помощью <tt>CreateKeyValues()</tt>. Handle должен быть освобожден после завершения работы для устранения утечки памяти.

=Файлы=
KeyValues могут быть экспортированы и импортированы с помощью KeyValues файлов. Эти файлы всегда состоят из главного узла и множества под-ключей или подразделов. Например файл может выглядеть вот так:
<pre>"MyFile"
{
"STEAM_0:0:7"
{
"name" "crab"
}
}</pre>

В этом примере <tt>STEAM_0:0:7</tt> это раздел под главным узлом <tt>MyFile</tt>.

Для загрузки KeyValues из файла используйте <tt>FileToKeyValues</tt>. Для сохранения KeyValues в файл используйте <tt>KeyValuesFromFile</tt>. Для обоих случае вы всегда должны иметь Handle ссылающийся на KeyValues структуру.

=Перемещение=
SourceMod обеспечивает нативное перемещение по KeyValues структуре. Однако очень важно понимать как происходит это перемещение. Внутренне, SourceMod отслеживает из двух частей информации:
*Главный узел
*Стек перемещения

Поскольку структура KeyValues изначально рекурсивная (это дерево), ''стек перемещения'' используется для сохранения истории каждого ''перемещения'' (перемещение начинается рекурсивно погружаться в дерево, где текущий уровень вложенности углубляется на одну секцию). The ''top'' of this stack is where all operations take place.

For example, <tt>KvJumpToKey</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>KvGetString</tt> will use this new position.

There are natives which change the position but do not change the traversal stack. For example, <tt>KvGotoNextKey</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>KvGotoFirstSubKey</tt> - Finds the first sub-section under the current section. This pushes the section onto the traversal stack.
*<tt>KvGoBack</tt> - Pops the traversal stack (moves up one level).
*<tt>KvRewind</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 String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");
if (!KvJumpToKey(kv, steamid))
{
return false;
}
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}</pawn>

'''Note:''' <tt>KvJumpToKey</tt> is a traversal native that changes the nesting level of the traversal stack. However, <tt>CloseHandle</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 String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");

if (!KvGotoFirstSubKey(kv))
{
return false;
}

decl String:buffer[255];
do
{
KvGetSectionName(kv, buffer, sizeof(buffer));
if (StrEqual(buffer, steamid))
{
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}
} while (KvGotoNextKey(kv));

CloseHandle(kv)
return false
}</pawn>

'''Note:''' In this example, note that <tt>KvGotoNextKey</tt> is an iterative function, not a traversal one. Since it does not change the nesting level, we don't need to call <tt>KvGoBack</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(Handle:kv)
{
do
{
if (KvGotoFirstSubKey(kv))
{
BrowseKeyValues(kv);
KvGoBack(kv);
}
} while (KvGotoNextKey(kv));
}</pawn>

This function will browse an entire KeyValues structure. Note that every successful call to <tt>KvGotoFirstSubKey</tt> is paired with a call to <tt>KvGoBack</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.

=Deletion=
There are two ways to delete sections from a KeyValues structure:
*<tt>KvDeleteKey</tt> - Safely removes a named sub-section and any of its child sections/keys.
*<tt>KvDeleteThis</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 String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")
if (!KvGotoFirstSubKey(kv))
{
return
}
KvDeleteKey(kv, steamid)
KvRewind(kv)
KeyValuesToFile(kv, "myfile.txt")
CloseHandle(kv)
}</pawn>

'''Note:''' We called <tt>KvRewind</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>KvDeleteThis</tt>, which deletes the current position from the previous position in the traversal stack.

<pawn>RemoveSteamID(const String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")

if (!KvGotoFirstSubKey(kv))
{
return
}

decl String:buffer[255]
do
{
KvGetSectionName(kv, buffer, sizeof(buffer))
if (StrEqual(buffer, steamid))
{
KvDeleteThis(kv)
CloseHandle(kv)
return
}
} while (KvGotoNextKey(kv))

CloseHandle(kv)
}</pawn>

==Full Deletion==
Lastly, let's take a look at how we would delete all (or some) keys. <tt>KvDeleteThis</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>KvGotoNextKey</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(Handle:kv)
{
if (!KvGotoFirstSubKey(kv))
{
return
}

for (;;)
{
decl String:name[4]
KvGetString(kv, name, sizeof(name))
if (name[0] == '\0')
{
if (KvDeleteThis(kv) < 1)
{
break
}
} else if (!KvGotoNextKey(kv)) {
break
}
}
}</pawn>

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

[[Category:Ru:SourceMod Scripting]]

Ru:KeyValues (SourceMod Scripting)

2010-12-25T04:27:29Z

V1KT0P: /* Introduction */

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>.

=Введение=
KeyValues состоит из ''узлов'' и ''разделов'', которые содержат пары ключей и значений. Разделы выглядят примерно так:
<pre>"раздел"
{
"ключ" "значение"
}</pre>

Сторка <tt>"раздел"</tt> является именем раздела. Строка <tt>"ключ"</tt> это имя ключа и строка <tt>"значение"</tt>" является значением.

KeyValues структуры создаются с помощью <tt>CreateKeyValues()</tt>. Handle должен быть освобожден после завершения работы для устранения утечки памяти.

=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>KeyValuesFromFile</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>KvJumpToKey</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>KvGetString</tt> will use this new position.

There are natives which change the position but do not change the traversal stack. For example, <tt>KvGotoNextKey</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>KvGotoFirstSubKey</tt> - Finds the first sub-section under the current section. This pushes the section onto the traversal stack.
*<tt>KvGoBack</tt> - Pops the traversal stack (moves up one level).
*<tt>KvRewind</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 String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");
if (!KvJumpToKey(kv, steamid))
{
return false;
}
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}</pawn>

'''Note:''' <tt>KvJumpToKey</tt> is a traversal native that changes the nesting level of the traversal stack. However, <tt>CloseHandle</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 String:steamid[], String:name[], maxlength)
{
new Handle:kv = CreateKeyValues("MyFile");
FileToKeyValues(kv, "myfile.txt");

if (!KvGotoFirstSubKey(kv))
{
return false;
}

decl String:buffer[255];
do
{
KvGetSectionName(kv, buffer, sizeof(buffer));
if (StrEqual(buffer, steamid))
{
KvGetString(kv, "name", name, maxlength);
CloseHandle(kv);
return true;
}
} while (KvGotoNextKey(kv));

CloseHandle(kv)
return false
}</pawn>

'''Note:''' In this example, note that <tt>KvGotoNextKey</tt> is an iterative function, not a traversal one. Since it does not change the nesting level, we don't need to call <tt>KvGoBack</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(Handle:kv)
{
do
{
if (KvGotoFirstSubKey(kv))
{
BrowseKeyValues(kv);
KvGoBack(kv);
}
} while (KvGotoNextKey(kv));
}</pawn>

This function will browse an entire KeyValues structure. Note that every successful call to <tt>KvGotoFirstSubKey</tt> is paired with a call to <tt>KvGoBack</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.

=Deletion=
There are two ways to delete sections from a KeyValues structure:
*<tt>KvDeleteKey</tt> - Safely removes a named sub-section and any of its child sections/keys.
*<tt>KvDeleteThis</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 String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")
if (!KvGotoFirstSubKey(kv))
{
return
}
KvDeleteKey(kv, steamid)
KvRewind(kv)
KeyValuesToFile(kv, "myfile.txt")
CloseHandle(kv)
}</pawn>

'''Note:''' We called <tt>KvRewind</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>KvDeleteThis</tt>, which deletes the current position from the previous position in the traversal stack.

<pawn>RemoveSteamID(const String:steamid[])
{
new Handle:kv = CreateKeyValues("MyFile")
FileToKeyValues(kv, "myfile.txt")

if (!KvGotoFirstSubKey(kv))
{
return
}

decl String:buffer[255]
do
{
KvGetSectionName(kv, buffer, sizeof(buffer))
if (StrEqual(buffer, steamid))
{
KvDeleteThis(kv)
CloseHandle(kv)
return
}
} while (KvGotoNextKey(kv))

CloseHandle(kv)
}</pawn>

==Full Deletion==
Lastly, let's take a look at how we would delete all (or some) keys. <tt>KvDeleteThis</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>KvGotoNextKey</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(Handle:kv)
{
if (!KvGotoFirstSubKey(kv))
{
return
}

for (;;)
{
decl String:name[4]
KvGetString(kv, name, sizeof(name))
if (name[0] == '\0')
{
if (KvDeleteThis(kv) < 1)
{
break
}
} else if (!KvGotoNextKey(kv)) {
break
}
}
}</pawn>

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

[[Category:Ru:SourceMod Scripting]]

Ru:Events (SourceMod Scripting)

2010-12-25T04:16:50Z

V1KT0P: /* Hooking Events */

:''Для просмотра всех событий, нажмите [[Game Events (Source)|здесь]].''

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

Все нативные события можно найти в <tt>plugins/include/events.inc</tt>.

=Введение=
События описаны в <tt>.res</tt> файлах мода в папке <tt>resource</tt>. "Стандартные" события находятся в <tt>hl2/resource/gameevents.res</tt> и <tt>hl2/resource/serverevents.res</tt>. Мод может расширить эти события с помощью расширений.

Для примера посмотрим на <tt>player_death</tt> из <tt>hl2/resource/gameevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID убитого
"attacker" "short" // user ID убийцы
}</pre>

Counter-Strike:Source расширяет это описание в <tt>cstrike/resource/modevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID убитого
"attacker" "short" // user ID убийцы
"weapon" "string" // название оружие, которым убил убийца
"headshot" "bool" // сигнал попадания в голову
}</pre>

Обратите внимание, что событие состоит в следующем формате:
<pre>"name"
{
"key1" "valueType1"
"key2" "valueType2"
...
}</pre>

=Посылка сообщений=
Послать сообщенмя очень просто. Например мы хотим послать сообщение смерти используя событие <tt>player_death</tt> описанное выше. Для Counter-Strike:Source, это будет иметь вид:

<pawn>SendDeathMessage(attacker, victim, const String:weapon[], bool:headshot)
{
new Handle:event = CreateEvent("player_death")
if (event == INVALID_HANDLE)
{
return
}

SetEventInt(event, "userid", GetClientUserId(victim))
SetEventInt(event, "attacker", GetClientUserId(attacker))
SetEventString(event, "weapon", weapon)
SetEventBool(event, "headshot", headshot)
FireEvent(event)
}</pawn>

Примечания:
*Вы не должны вызывать <tt>CloseHandle()</tt>, <tt>FireEvent()</tt> сделает это за вас.
*Даже если "userid" и "attacker" являются shorts, мы отсылаем их в качестве ints. Термин "short" используется только для того, чтобы сказать движку сколько байт числа необходимо для отправки.
*Событие может и не создастся; это происходит если событие не существует или никто не перехватывает его. Поэтому вы должны убедиться, что вызов <tt>CreateEvent</tt> возвращает правильный Handle.
*Большинство событий используют userids вместо индекса.
*По умолчанию, <tt>FireEvent()</tt> посылает сообщения к клиенту. Это можно отключить установив <tt>dontBroadcast</tt> в true.

=Перехват Событий=
Существует три режима перехвата событий:
*<tt>Pre</tt> - Перехват события до выполнения.
*<tt>Post</tt> - Перехват события после выполнения.
*<tt>Post_NoCopy</tt> - Перехват события, но не сохраняется любая информация об этом событии (специальная оптимизация).

Перехват событий обычно делается для одной из этих целей. Для того, чтоб понять какой режим использовать, смотрите ниже список целей:
*Блокировка события (предотвращение выполнения)
**'''Всегда <tt>Pre</tt>'''
*Изменение события (изменение параметров)
**'''Всегда <tt>Pre</tt>'''
*Выполнить после события (сделать что-то после того как событие произошло)
**'''<tt>Pre</tt>''' если ваши действия должны произойти перед выполнением мода.
**'''<tt>Post</tt>''' если ваши действия должны произойти после выполнением мода.
**'''<tt>PostNoCopy</tt>''' если подходит <tt>Post</tt> и требуется только имя события.

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

==Блокировка Событий==
Блокировку событий сделать очень просто. Например мы хотим заблокировать событие смерти если смерть произошла от попадания в голову:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
if (GetEventBool(event, "headshot"))
{
return Plugin_Handled
}
return Plugin_Continue
}</pawn>

==Изменение Событий==
Измененить событий тоже очень просто -- события могут быть изменены в режиме перед выполнением события. Например мы хотим убрать попадание в голову со всех событий:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
SetEventBool(event, "headshot", false)
return Plugin_Continue
}</pawn>

==Post Перехват==
По умолчанию используется перехват после события и как правило наиболее используемый. Например мы хотим послать сообщение всем игрокам, которые умерли:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath)
}

public Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
decl String:weapon[64]
new victimId = GetEventInt(event, "userid")
new attackerId = GetEventInt(event, "attacker")
new bool:headshot = GetEventBool(event, "headshot")
GetEventString(event, "weapon", weapon, sizeof(weapon))

decl String:name[64]
new victim = GetClientOfUserId(victimId)
new attacker = GetClientOfUserId(attackerId)
GetClientName(attacker, name, sizeof(name))

PrintToConsole(victim,
"You were killed by \"%s\" (weapon \"%s\") (headshot \"%d\")",
name,
weapon,
headshot)
}</pawn>

Это будет писать игроку в консоли кто его убил, с каким оружием и было ли попадание в голову.

Обратите внимание, что возвращение значений с перехвата после события игнорируется, поэтому тег <tt>Action</tt> ненужен.

==PostNoCopy Перехват==
Наконец есть перехваты где требуется только имя события. <tt>PostNoCopy</tt> специальная оптимизация для этого. При переходе от <tt>Pre</tt> к <tt>Post</tt>, SourceMod должен дублировать событие и все значения. <tt>PostNoCopy</tt> предотвращает это.

Например мы хотим найти когда происходят определенные события.

<pawn>public OnPluginStart()
{
HookEvent("game_newmap", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_start", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_end", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_message", GameEvents, EventHookMode_PostNoCopy)
}

public GameEvents(Handle:event, const String:name[], bool:dontBroadcast)
{
PrintToServer("Event has been fired (event \"%s\") (nobcast \"%d\")", name, dontBroadcast)
}</pawn>

Обратите внимание, что как и обычный <tt>Post</tt> перехват, он не требует возврата значений. Однако, параметр <tt>event</tt> для <tt>PostNoCopy</tt> '''всегда''' должен быть равным <tt>INVALID_HANDLE</tt>. Таким образом параметр <tt>name</tt> должен использоваться вместо <tt>GetEventName</tt>.

[[Category:Ru:SourceMod Scripting]]

Ru:Events (SourceMod Scripting)

2010-12-25T03:49:37Z

V1KT0P: /* Посылка сообщений */

:''Для просмотра всех событий, нажмите [[Game Events (Source)|здесь]].''

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

Все нативные события можно найти в <tt>plugins/include/events.inc</tt>.

=Введение=
События описаны в <tt>.res</tt> файлах мода в папке <tt>resource</tt>. "Стандартные" события находятся в <tt>hl2/resource/gameevents.res</tt> и <tt>hl2/resource/serverevents.res</tt>. Мод может расширить эти события с помощью расширений.

Для примера посмотрим на <tt>player_death</tt> из <tt>hl2/resource/gameevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID убитого
"attacker" "short" // user ID убийцы
}</pre>

Counter-Strike:Source расширяет это описание в <tt>cstrike/resource/modevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID убитого
"attacker" "short" // user ID убийцы
"weapon" "string" // название оружие, которым убил убийца
"headshot" "bool" // сигнал попадания в голову
}</pre>

Обратите внимание, что событие состоит в следующем формате:
<pre>"name"
{
"key1" "valueType1"
"key2" "valueType2"
...
}</pre>

=Посылка сообщений=
Послать сообщенмя очень просто. Например мы хотим послать сообщение смерти используя событие <tt>player_death</tt> описанное выше. Для Counter-Strike:Source, это будет иметь вид:

<pawn>SendDeathMessage(attacker, victim, const String:weapon[], bool:headshot)
{
new Handle:event = CreateEvent("player_death")
if (event == INVALID_HANDLE)
{
return
}

SetEventInt(event, "userid", GetClientUserId(victim))
SetEventInt(event, "attacker", GetClientUserId(attacker))
SetEventString(event, "weapon", weapon)
SetEventBool(event, "headshot", headshot)
FireEvent(event)
}</pawn>

Примечания:
*Вы не должны вызывать <tt>CloseHandle()</tt>, <tt>FireEvent()</tt> сделает это за вас.
*Даже если "userid" и "attacker" являются shorts, мы отсылаем их в качестве ints. Термин "short" используется только для того, чтобы сказать движку сколько байт числа необходимо для отправки.
*Событие может и не создастся; это происходит если событие не существует или никто не перехватывает его. Поэтому вы должны убедиться, что вызов <tt>CreateEvent</tt> возвращает правильный Handle.
*Большинство событий используют userids вместо индекса.
*По умолчанию, <tt>FireEvent()</tt> посылает сообщения к клиенту. Это можно отключить установив <tt>dontBroadcast</tt> в true.

=Hooking Events=
When hooking an event, there are three modes to choose from:
*<tt>Pre</tt> - Hook the event before it is fired.
*<tt>Post</tt> - Hook the event after it is fired.
*<tt>Post_NoCopy</tt> - Hook the event, but do not save any of its information (special optimization).

Hooking an event is usually done for one of the following goals. To get an idea of which mode to use, see the list below each goal:
*Blocking the event (preventing it from being fired)
**'''Always <tt>Pre</tt>'''
*Rewriting the event (changing its parameters)
**'''Always <tt>Pre</tt>'''
*Acting upon the event (doing something once the event is completed)
**'''<tt>Pre</tt>''' if your action must come before the mod's action.
**'''<tt>Post</tt>''' if your action must come after the mod's action.
**'''<tt>PostNoCopy</tt>''' if your action is <tt>Post</tt> and only requires the event name.

As always, you do not need to unhook events when your plugin unloads. They are automatically removed.

==Blocking Events==
Blocking events is the easiest thing to do. Let's say we want to block death events that are headshots:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
if (GetEventBool(event, "headshot"))
{
return Plugin_Handled
}
return Plugin_Continue
}</pawn>

==Rewriting Events==
Rewriting events is just as easy -- events can be modified in pre hooks. For example, say we want to remove headshots from all events:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
SetEventBool(event, "headshot", false)
return Plugin_Continue
}</pawn>

==Post Hooks==
Post hooks are default, and will usually be the most common usage. For example, say we want to print a message to every client that dies:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath)
}

public Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
decl String:weapon[64]
new victimId = GetEventInt(event, "userid")
new attackerId = GetEventInt(event, "attacker")
new bool:headshot = GetEventBool(event, "headshot")
GetEventString(event, "weapon", weapon, sizeof(weapon))

decl String:name[64]
new victim = GetClientOfUserId(victimId)
new attacker = GetClientOfUserId(attackerId)
GetClientName(attacker, name, sizeof(name))

PrintToConsole(victim,
"You were killed by \"%s\" (weapon \"%s\") (headshot \"%d\")",
name,
weapon,
headshot)
}</pawn>

This will print a message to a player's console telling them who killed them, with what weapon, and whether it was a headshot or not.

Note that the return value for post hooks is ignored, so the <tt>Action</tt> tag is not needed.

==PostNoCopy Hooks==
Lastly, there are some hooks where the only piece of information needed is the name of the event. <tt>PostNoCopy</tt> is a special optimization for this case. When transitioning from <tt>Pre</tt> to <tt>Post</tt>, SourceMod must duplicate the event and all of its key/value pairs. <tt>PostNoCopy</tt> prevents that sequence from happening.

For example, let's say we want to find when a certain sequence of events is called.

<pawn>public OnPluginStart()
{
HookEvent("game_newmap", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_start", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_end", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_message", GameEvents, EventHookMode_PostNoCopy)
}

public GameEvents(Handle:event, const String:name[], bool:dontBroadcast)
{
PrintToServer("Event has been fired (event \"%s\") (nobcast \"%d\")", name, dontBroadcast)
}</pawn>

Note that like normal <tt>Post</tt> hooks, there is no return value needed. However, the <tt>event</tt> parameter for <tt>PostNoCopy</tt> will '''always''' be equal to <tt>INVALID_HANDLE</tt>. Thus, the <tt>name</tt> parameter must be used instead of <tt>GetEventName</tt>.

[[Category:Ru:SourceMod Scripting]]

Ru:Events (SourceMod Scripting)

2010-12-08T15:17:00Z

V1KT0P:

:''Для просмотра всех событий, нажмите [[Game Events (Source)|здесь]].''

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

Все нативные события можно найти в <tt>plugins/include/events.inc</tt>.

=Введение=
События описаны в <tt>.res</tt> файлах мода в папке <tt>resource</tt>. "Стандартные" события находятся в <tt>hl2/resource/gameevents.res</tt> и <tt>hl2/resource/serverevents.res</tt>. Мод может расширить эти события с помощью расширений.

Для примера посмотрим на <tt>player_death</tt> из <tt>hl2/resource/gameevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID убитого
"attacker" "short" // user ID убийцы
}</pre>

Counter-Strike:Source расширяет это описание в <tt>cstrike/resource/modevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID убитого
"attacker" "short" // user ID убийцы
"weapon" "string" // название оружие, которым убил убийца
"headshot" "bool" // сигнал попадания в голову
}</pre>

Обратите внимание, что событие состоит в следующем формате:
<pre>"name"
{
"key1" "valueType1"
"key2" "valueType2"
...
}</pre>

=Посылка сообщений=
Послать сообщенмя очень просто. Например мы хотим послать сообщение смерти используя событие <tt>player_death</tt> описанное выше. Для Counter-Strike:Source, это будет иметь вид:

<pawn>SendDeathMessage(attacker, victim, const String:weapon[], bool:headshot)
{
new Handle:event = CreateEvent("player_death")
if (event == INVALID_HANDLE)
{
return
}

SetEventInt(event, "userid", GetClientUserId(victim))
SetEventInt(event, "attacker", GetClientUserId(attacker))
SetEventString(event, "weapon", weapon)
SetEventBool(event, "headshot", headshot)
FireEvent(event)
}</pawn>

Примечания:
*Вы не должны вызывать <tt>CloseHandle()</tt>, <tt>FireEvent()</tt> сделает это за вас.
*Даже если "userid" и "attacker" являются shorts, мы отсылаем их в качестве ints. Термин "short" используется только для того, чтобы сказать движку сколько байт числа необходимо для отправки.
*It is possible for event creation to fail; this can happen if the event does not exist, or nothing is hooking the event. Thus, you should always make sure <tt>CreateEvent</tt> calls return a valid Handle.
*Most events use client userids instead of client indexes.
*By default, <tt>FireEvent()</tt> broadcasts messages to clients. This can be prevented by passing <tt>dontBroadcast</tt> as true.

=Hooking Events=
When hooking an event, there are three modes to choose from:
*<tt>Pre</tt> - Hook the event before it is fired.
*<tt>Post</tt> - Hook the event after it is fired.
*<tt>Post_NoCopy</tt> - Hook the event, but do not save any of its information (special optimization).

Hooking an event is usually done for one of the following goals. To get an idea of which mode to use, see the list below each goal:
*Blocking the event (preventing it from being fired)
**'''Always <tt>Pre</tt>'''
*Rewriting the event (changing its parameters)
**'''Always <tt>Pre</tt>'''
*Acting upon the event (doing something once the event is completed)
**'''<tt>Pre</tt>''' if your action must come before the mod's action.
**'''<tt>Post</tt>''' if your action must come after the mod's action.
**'''<tt>PostNoCopy</tt>''' if your action is <tt>Post</tt> and only requires the event name.

As always, you do not need to unhook events when your plugin unloads. They are automatically removed.

==Blocking Events==
Blocking events is the easiest thing to do. Let's say we want to block death events that are headshots:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
if (GetEventBool(event, "headshot"))
{
return Plugin_Handled
}
return Plugin_Continue
}</pawn>

==Rewriting Events==
Rewriting events is just as easy -- events can be modified in pre hooks. For example, say we want to remove headshots from all events:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
SetEventBool(event, "headshot", false)
return Plugin_Continue
}</pawn>

==Post Hooks==
Post hooks are default, and will usually be the most common usage. For example, say we want to print a message to every client that dies:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath)
}

public Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
decl String:weapon[64]
new victimId = GetEventInt(event, "userid")
new attackerId = GetEventInt(event, "attacker")
new bool:headshot = GetEventBool(event, "headshot")
GetEventString(event, "weapon", weapon, sizeof(weapon))

decl String:name[64]
new victim = GetClientOfUserId(victimId)
new attacker = GetClientOfUserId(attackerId)
GetClientName(attacker, name, sizeof(name))

PrintToConsole(victim,
"You were killed by \"%s\" (weapon \"%s\") (headshot \"%d\")",
name,
weapon,
headshot)
}</pawn>

This will print a message to a player's console telling them who killed them, with what weapon, and whether it was a headshot or not.

Note that the return value for post hooks is ignored, so the <tt>Action</tt> tag is not needed.

==PostNoCopy Hooks==
Lastly, there are some hooks where the only piece of information needed is the name of the event. <tt>PostNoCopy</tt> is a special optimization for this case. When transitioning from <tt>Pre</tt> to <tt>Post</tt>, SourceMod must duplicate the event and all of its key/value pairs. <tt>PostNoCopy</tt> prevents that sequence from happening.

For example, let's say we want to find when a certain sequence of events is called.

<pawn>public OnPluginStart()
{
HookEvent("game_newmap", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_start", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_end", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_message", GameEvents, EventHookMode_PostNoCopy)
}

public GameEvents(Handle:event, const String:name[], bool:dontBroadcast)
{
PrintToServer("Event has been fired (event \"%s\") (nobcast \"%d\")", name, dontBroadcast)
}</pawn>

Note that like normal <tt>Post</tt> hooks, there is no return value needed. However, the <tt>event</tt> parameter for <tt>PostNoCopy</tt> will '''always''' be equal to <tt>INVALID_HANDLE</tt>. Thus, the <tt>name</tt> parameter must be used instead of <tt>GetEventName</tt>.

[[Category:Ru:SourceMod Scripting]]

Ru:Events (SourceMod Scripting)

2010-12-08T15:11:23Z

V1KT0P:

:''Для просмотра всех событий, нажмите [[Game Events (Source)|здесь]].''

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

Все нативные события можно найти в <tt>plugins/include/events.inc</tt>.

=Введение=
События описаны в <tt>.res</tt> файлах мода в папке <tt>resource</tt>. "Стандартные" события находятся в <tt>hl2/resource/gameevents.res</tt> и <tt>hl2/resource/serverevents.res</tt>. Мод может расширить эти события с помощью расширений.

Для примера посмотрим на <tt>player_death</tt> из <tt>hl2/resource/gameevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID убитого
"attacker" "short" // user ID убийцы
}</pre>

Counter-Strike:Source расширяет это описание в <tt>cstrike/resource/modevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID убитого
"attacker" "short" // user ID убийцы
"weapon" "string" // название оружие, которым убил убийца
"headshot" "bool" // сигнал попадания в голову
}</pre>

Обратите внимание, что событие состоит в следующем формате:
<pre>"name"
{
"key1" "valueType1"
"key2" "valueType2"
...
}</pre>

=Посылка сообщений=
Послать сообщенмя очень просто. Например мы хотим послать сообщение смерти используя событие <tt>player_death</tt> описанное выше. Для Counter-Strike:Source, это будет иметь вид:

<pawn>SendDeathMessage(attacker, victim, const String:weapon[], bool:headshot)
{
new Handle:event = CreateEvent("player_death")
if (event == INVALID_HANDLE)
{
return
}

SetEventInt(event, "userid", GetClientUserId(victim))
SetEventInt(event, "attacker", GetClientUserId(attacker))
SetEventString(event, "weapon", weapon)
SetEventBool(event, "headshot", headshot)
FireEvent(event)
}</pawn>

Примечания:
*You don't need to call <tt>CloseHandle()</tt>, <tt>FireEvent()</tt> does this for us.
*Even though "userid" and "attacker" are shorts, we set them as ints. The term "short" is only used to tell the engine how many bytes of the integer are needed to be networked.
*It is possible for event creation to fail; this can happen if the event does not exist, or nothing is hooking the event. Thus, you should always make sure <tt>CreateEvent</tt> calls return a valid Handle.
*Most events use client userids instead of client indexes.
*By default, <tt>FireEvent()</tt> broadcasts messages to clients. This can be prevented by passing <tt>dontBroadcast</tt> as true.

=Hooking Events=
When hooking an event, there are three modes to choose from:
*<tt>Pre</tt> - Hook the event before it is fired.
*<tt>Post</tt> - Hook the event after it is fired.
*<tt>Post_NoCopy</tt> - Hook the event, but do not save any of its information (special optimization).

Hooking an event is usually done for one of the following goals. To get an idea of which mode to use, see the list below each goal:
*Blocking the event (preventing it from being fired)
**'''Always <tt>Pre</tt>'''
*Rewriting the event (changing its parameters)
**'''Always <tt>Pre</tt>'''
*Acting upon the event (doing something once the event is completed)
**'''<tt>Pre</tt>''' if your action must come before the mod's action.
**'''<tt>Post</tt>''' if your action must come after the mod's action.
**'''<tt>PostNoCopy</tt>''' if your action is <tt>Post</tt> and only requires the event name.

As always, you do not need to unhook events when your plugin unloads. They are automatically removed.

==Blocking Events==
Blocking events is the easiest thing to do. Let's say we want to block death events that are headshots:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
if (GetEventBool(event, "headshot"))
{
return Plugin_Handled
}
return Plugin_Continue
}</pawn>

==Rewriting Events==
Rewriting events is just as easy -- events can be modified in pre hooks. For example, say we want to remove headshots from all events:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
SetEventBool(event, "headshot", false)
return Plugin_Continue
}</pawn>

==Post Hooks==
Post hooks are default, and will usually be the most common usage. For example, say we want to print a message to every client that dies:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath)
}

public Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
decl String:weapon[64]
new victimId = GetEventInt(event, "userid")
new attackerId = GetEventInt(event, "attacker")
new bool:headshot = GetEventBool(event, "headshot")
GetEventString(event, "weapon", weapon, sizeof(weapon))

decl String:name[64]
new victim = GetClientOfUserId(victimId)
new attacker = GetClientOfUserId(attackerId)
GetClientName(attacker, name, sizeof(name))

PrintToConsole(victim,
"You were killed by \"%s\" (weapon \"%s\") (headshot \"%d\")",
name,
weapon,
headshot)
}</pawn>

This will print a message to a player's console telling them who killed them, with what weapon, and whether it was a headshot or not.

Note that the return value for post hooks is ignored, so the <tt>Action</tt> tag is not needed.

==PostNoCopy Hooks==
Lastly, there are some hooks where the only piece of information needed is the name of the event. <tt>PostNoCopy</tt> is a special optimization for this case. When transitioning from <tt>Pre</tt> to <tt>Post</tt>, SourceMod must duplicate the event and all of its key/value pairs. <tt>PostNoCopy</tt> prevents that sequence from happening.

For example, let's say we want to find when a certain sequence of events is called.

<pawn>public OnPluginStart()
{
HookEvent("game_newmap", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_start", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_end", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_message", GameEvents, EventHookMode_PostNoCopy)
}

public GameEvents(Handle:event, const String:name[], bool:dontBroadcast)
{
PrintToServer("Event has been fired (event \"%s\") (nobcast \"%d\")", name, dontBroadcast)
}</pawn>

Note that like normal <tt>Post</tt> hooks, there is no return value needed. However, the <tt>event</tt> parameter for <tt>PostNoCopy</tt> will '''always''' be equal to <tt>INVALID_HANDLE</tt>. Thus, the <tt>name</tt> parameter must be used instead of <tt>GetEventName</tt>.

[[Category:Ru:SourceMod Scripting]]

Ru:Events (SourceMod Scripting)

2010-12-08T14:52:21Z

V1KT0P:

:''Для просмотра всех событий, нажмите [[Game Events (Source)|здесь]].''

Events are short, named messages sent by the server. Although they are used for internal message passing, they are also networked to clients.

All event natives are found in <tt>plugins/include/events.inc</tt>.

=Introduction=
Events are documented in <tt>.res</tt> files under a mod's <tt>resource</tt> folder. The "default" events are located in <tt>hl2/resource/gameevents.res</tt> and <tt>hl2/resource/serverevents.res</tt>. Mods can extend these events with their own.

For example, let's look at <tt>player_death</tt> from <tt>hl2/resource/gameevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID who died
"attacker" "short" // user ID who killed
}</pre>

Counter-Strike:Source extends this definition in <tt>cstrike/resource/modevents.res</tt>:
<pre>"player_death"
{
"userid" "short" // user ID who died
"attacker" "short" // user ID who killed
"weapon" "string" // weapon name killer used
"headshot" "bool" // signals a headshot
}</pre>

Note that the event is structured in the following format:
<pre>"name"
{
"key1" "valueType1"
"key2" "valueType2"
...
}</pre>

=Sending Events=
Events are very easy to send. For example, let's say we want to send a death message using the <tt>player_death</tt> event from above. For Counter-Strike:Source, this would look like:

<pawn>SendDeathMessage(attacker, victim, const String:weapon[], bool:headshot)
{
new Handle:event = CreateEvent("player_death")
if (event == INVALID_HANDLE)
{
return
}

SetEventInt(event, "userid", GetClientUserId(victim))
SetEventInt(event, "attacker", GetClientUserId(attacker))
SetEventString(event, "weapon", weapon)
SetEventBool(event, "headshot", headshot)
FireEvent(event)
}</pawn>

Notes:
*You don't need to call <tt>CloseHandle()</tt>, <tt>FireEvent()</tt> does this for us.
*Even though "userid" and "attacker" are shorts, we set them as ints. The term "short" is only used to tell the engine how many bytes of the integer are needed to be networked.
*It is possible for event creation to fail; this can happen if the event does not exist, or nothing is hooking the event. Thus, you should always make sure <tt>CreateEvent</tt> calls return a valid Handle.
*Most events use client userids instead of client indexes.
*By default, <tt>FireEvent()</tt> broadcasts messages to clients. This can be prevented by passing <tt>dontBroadcast</tt> as true.

=Hooking Events=
When hooking an event, there are three modes to choose from:
*<tt>Pre</tt> - Hook the event before it is fired.
*<tt>Post</tt> - Hook the event after it is fired.
*<tt>Post_NoCopy</tt> - Hook the event, but do not save any of its information (special optimization).

Hooking an event is usually done for one of the following goals. To get an idea of which mode to use, see the list below each goal:
*Blocking the event (preventing it from being fired)
**'''Always <tt>Pre</tt>'''
*Rewriting the event (changing its parameters)
**'''Always <tt>Pre</tt>'''
*Acting upon the event (doing something once the event is completed)
**'''<tt>Pre</tt>''' if your action must come before the mod's action.
**'''<tt>Post</tt>''' if your action must come after the mod's action.
**'''<tt>PostNoCopy</tt>''' if your action is <tt>Post</tt> and only requires the event name.

As always, you do not need to unhook events when your plugin unloads. They are automatically removed.

==Blocking Events==
Blocking events is the easiest thing to do. Let's say we want to block death events that are headshots:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
if (GetEventBool(event, "headshot"))
{
return Plugin_Handled
}
return Plugin_Continue
}</pawn>

==Rewriting Events==
Rewriting events is just as easy -- events can be modified in pre hooks. For example, say we want to remove headshots from all events:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath, EventHookMode_Pre)
}

public Action:Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
SetEventBool(event, "headshot", false)
return Plugin_Continue
}</pawn>

==Post Hooks==
Post hooks are default, and will usually be the most common usage. For example, say we want to print a message to every client that dies:

<pawn>public OnPluginStart()
{
HookEvent("player_death", Event_PlayerDeath)
}

public Event_PlayerDeath(Handle:event, const String:name[], bool:dontBroadcast)
{
decl String:weapon[64]
new victimId = GetEventInt(event, "userid")
new attackerId = GetEventInt(event, "attacker")
new bool:headshot = GetEventBool(event, "headshot")
GetEventString(event, "weapon", weapon, sizeof(weapon))

decl String:name[64]
new victim = GetClientOfUserId(victimId)
new attacker = GetClientOfUserId(attackerId)
GetClientName(attacker, name, sizeof(name))

PrintToConsole(victim,
"You were killed by \"%s\" (weapon \"%s\") (headshot \"%d\")",
name,
weapon,
headshot)
}</pawn>

This will print a message to a player's console telling them who killed them, with what weapon, and whether it was a headshot or not.

Note that the return value for post hooks is ignored, so the <tt>Action</tt> tag is not needed.

==PostNoCopy Hooks==
Lastly, there are some hooks where the only piece of information needed is the name of the event. <tt>PostNoCopy</tt> is a special optimization for this case. When transitioning from <tt>Pre</tt> to <tt>Post</tt>, SourceMod must duplicate the event and all of its key/value pairs. <tt>PostNoCopy</tt> prevents that sequence from happening.

For example, let's say we want to find when a certain sequence of events is called.

<pawn>public OnPluginStart()
{
HookEvent("game_newmap", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_start", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_end", GameEvents, EventHookMode_PostNoCopy)
HookEvent("game_message", GameEvents, EventHookMode_PostNoCopy)
}

public GameEvents(Handle:event, const String:name[], bool:dontBroadcast)
{
PrintToServer("Event has been fired (event \"%s\") (nobcast \"%d\")", name, dontBroadcast)
}</pawn>

Note that like normal <tt>Post</tt> hooks, there is no return value needed. However, the <tt>event</tt> parameter for <tt>PostNoCopy</tt> will '''always''' be equal to <tt>INVALID_HANDLE</tt>. Thus, the <tt>name</tt> parameter must be used instead of <tt>GetEventName</tt>.

[[Category:Ru:SourceMod Scripting]]