S.T.A.L.K.E.R. Inside Wiki - Вклад участника [ru]

Справочник по функциям и классам

2012-09-15T05:58:48Z

188.226.13.119: /* сlass alife_simulator */

Посты с форума AMK

==Структура Lua_help==
Сам фаил можно найти в '''gamedata\scripts\lua_help.script'''
<code>C++ class [класс] {
const [описание1] = [константа1];
const [описание2] = [константа2];
...
[константы заменяют описания при вызове методов классов];

property [свойство1];
property [свойство2];
...
[свойства (property) - это характеристика какого-либо класса, которая может подвергаться мат. операциям, слияниям, присвояниям и пр.
читаются через точку: obj.health];

[глобальная(-ые) функция(-ии), которой вызывается класс];
function [метод1] ([аргумент 1 функции 1], [аргумент 2 функции 1]...);
function [метод2] ([аргумент 1 функции2]...);
...
[методы - это специальные функции, выполняющие операции с классами и возвращающие значения после операций над классами.
вызываются через двоеточие: obj:add_animation(...)];
}
</code>

==Создание своего класса==
Свой класс можно добавить так:
<code>
class "my_cool_class"
</code>
Здесь "my_cool_class" - имя моего нового класса. Записывается в кавычках, т.е. это строка.

Потом можно добавлять к этому классу свои методы:

<code>
-- это специальный метод - конструктор. Будет вызван при создании класса.
function my_cool_class:__init(num)
self.my_param = num -- добавили в свой класс переменную
end

-- обычный метод
function my_cool_class:cool_method_of_my_class()
get_console():execute("lua_bind_in_action_"..self.my_param)
end

-- деструктор, вызывается при сборке объекта сборщиком мусора. Аргументов не имеет (кроме скрытого self. об этом см. далее)
function my_cool_class:__finalize()
get_console():execute("good_by_"..self.my_param)
end
</code>

Потом можно создавать экземпляры своего класса, вызывать их методы и пр.:
<code>
local obj1 = my_cool_class(1) -- здесь создаётся новый объект. При этом вызывается конструктор и
-- ему передаются аргументы этого вызова (в данном случае число 1).
local obj2 = my_cool_class(4)
obj1:cool_method_of_my_class()
obj2:cool_method_of_my_class()
</code>

Как только объект становится ненужным (т.е. на него больше нет ссылок) он удаляется сборщиком мусора. При этом вызывается его метод __finalize

При чём здесь self.
self - это скрытый первый аргумент. Конструкция вида:
<code>
function class_name:fun_name(<список аргументов>)
end
</code>
на самом деле эквивалентна конструкции
<code>
function class_name.fun_name(self, <список аргументов>)
end
</code>
Обратите внимание на двоеточие в первом случае и точку во втором. 
При вызове метода конструкция вида:

'''object_name:fun_name(<список аргументов>)'''

эквивалентна конструкции

'''object_name.fun_name(object_name, <список аргументов>)'''

Это означает, что в качестве self как правило передаётся сам же объект. "Как правило" - это потому, что можно в принципе передать что-то другое. Но лучше этого соглашения не нарушать.

Всё это здорово, но какая от этого польза? Ну сделал я свой класс, и что с ним делать?

В общем, классы - это неплохое средство организации своего кода. Владеющие объектно-ориентированным подходом найдут это расширение весьма удобным. В частности такие, ни к чему не привязанные классы, в скриптах сталкера используются в некоторых местах. Однако, настоящая сила этой технологии не в этом. С помощью этой технологии можно расширять классы, экспортированные в Lua со стороны движка игры. Об этом пойдет речь в следующей части.

==Наследование от экспортированных классов==
Итак, кроме создания собственных классов технология Luabind позволяет создавать класы на основе уже существующих. Это реализовано в виде своеобразного наследования. Делается это с помощью следующей конструкции:

'''class "my_derived_class" (base_class)'''

Здесь:
"my_derived_class" как и раньше - это имя нового класса. 
base_class - это уже существующий класс, который будет базовым для вновь созданного. Имя выбрано произвольно, но подразумевается, что такой класс экспортирован и предназначен для наследования. 
Далеко не любой класс из экспортированных со стороны хост-приложения можно использовать в качестве базового. На стороне хост-приложения должен быть создан специальный класс-обёртка. Если его нет, то ничего хорошего не выйдет. Скорее всего при попытке использовать унаследованный класс в Lua будут малопонятные проблемы и вылеты, так что надо знать совершенно точно, можно ли от конкретного класса наследовать. 
Вопрос, какой глубины может быть наследование, т.е. можно ли наследовать от производного класса, мне пока до конца не ясен. С другой стороны, в этом практически нет необходимости. 

Итак после выполнения указанной конструкции появляется класс my_derived_class, который является копией класса base_class. У него есть в точности те же методы, что и у его базового класса. Пока от этого мало толку. Но теперь можно переопределить методы нашего класса, изменив таким образом его поведение. Делается это так же, как и ранее, но с некоторыми дополнениями.

<code>
-- конструктор
function my_derived_class:__init(num) super(num)
end
-- обычный метод
function my_cool_class:some_method(<список аргументов>)
base_class.some_method(self, <список аргументов>)
end
-- деструктор
function my_cool_class:__finalize()
end
</code>

На что стОит обратить внимание. 
Во-первых, конструкция super(num). Это вызов конструктора базового класса. 
Во-вторых, для вызова метода базового класса из метода унаследованного используется другая конструкция base_class.some_method(self, ). Здесь надо использовать альтернативную форму вызова метода (с точкой и явным указанием первого аргумента self). 
Наконец, метод __finalize() не требует вызова этого же метода для базового класса, поскольку тот будет вызван автоматически при удалении объекта сборщиком мусора.

Собственно и всё. Теперь можно пользоваться созданным классом: создавать объекты этого класса, вызывать их методы и пр. Здесь уже всё зависит от конкретных целей и требует знания конкретных классов.

==сlass alife_simulator==
alife_simulator - класс для управления серверными объектами. В игре существует всего один экземпляр такого класса, и получить его можно с помощью вызова глобальной функции alife().
<code>
level_name(level_id) -- возвращает имя уровня по его id
create_ammo(<имя секции патронов>, position, lvid, gvid, id, amount) - создание пачек с патронами
create(<имя секции объекта>, position, lvid, gvid, id) -- создание объектов в инвентаре
create(<имя секции объекта>, position, lvid, gvid) -- создание объектов на уровне
во всех функция создания объектов
position - объект класса vector. Не может быть nil, иначе вылет
lvid - level vertex id
gvid - game vertex id
id - это куда спавним. Если в инвентарь, то указываем id непися или ноль (для актора)
release(sobj, boolean) -- удаляет объект sobj. Зачем второй булевский аргумент - не известно.
Во всех примерах он либо отсутствует, либо установлен в true
object(id) -- возвращает серверный объект по его id. Если не нашёл nil
story_object(sid) -- возвращает серверный объект по его story id. Если не нашёл nil
actor() -- возвращает серверный объект актора
set_switch_online(id, boolean) -- переводит в онлайн объект с идентификатором id
set_switch_offline(id, boolean) -- то же , но в оффлайн
dont_has_info(const number&, string); -- проверка на Неполученный инфопоршень(db.actor:dont_has_info("infoportion")
-- или alife():actor():dont_has_info("infoportion")).
has_info - противоположная

предположительно:
switch_distance() -- радиус переключения в оффлайн?
switch_distance(number) -- установка этого радиуса?
level_id() -- текущий номер уровня ?
object(string) -- получение объекта оп его имени. Не помню точно, что за имя.
object(number, boolean) - то же, что и object(number)? на что влияет второй аргумент?
valid_object_id(number) -- проверка наличия объекта по id?
alife():create( <индекс объекта в all.spawn> ) --
spawn_id(number) -- индекс объекта в all.spawn для объекта с заданным id ?

неизвестно:
add_out_restriction(cse_alife_monster_abstract*, number);
set_interactive(number, boolean);
add_in_restriction(cse_alife_monster_abstract*, number);
function remove_in_restriction(cse_alife_monster_abstract*, number);
remove_out_restriction(cse_alife_monster_abstract*, number);
kill_entity(cse_alife_monster_abstract*, const number&, cse_alife_schedulable*);
kill_entity(alife_simulator*, cse_alife_monster_abstract*, const number&);
kill_entity(alife_simulator*, cse_alife_monster_abstract*);
has_info(const number&, string);
remove_all_restrictions(number, const enum RestrictionSpace::ERestrictorTypes&);
</code>

====Пример использования:====
<code>
local sim = alife() -- получаем сам объект класса alife_simulator
local sactor = sim:actor() -- получаем серверный объект для актора
</code>

==class vector==
vector - вспомогательный класс, содержащий три координаты, и позволяющий выполнять с ними различные манипуляции. Объекты класса vector являются аргументами многих функций и возвращаются многими функциями. См. например выше про метод create класса alife_simulator. Отдельный объект класса вектор создаётся вызовом глобальной функции vector(). При создании имеет координаты [0,0,0].

===Список методов класса vector===
<code>
v:set_length(number) - оставить направление, изменить длину
v:normalize(); - сделать длину единичной

v:magnitude() -- длина вектора v
v1:distance_to(v2) -- расстояние между v1 и v2
v1:distance_to_sqr(v2) -- квадрат расстояния между v1 и v2
v1:crossproduct(v2) -- векторное произведение. Возвращает вектор
v1:dotproduct(v2) -- скалярное произведение. Возвращает число
v:sub(number); -- вычесть из каждого компонента v число number
v1:sub(v2); -- вычесть почленно вектор v2 из v1 и поместить в v1
v1:sub(v2, v3) -- вычесть из v2 - v3 и поместить в v1
аналогично:
add - почленное сложение
mul - почленное умножение
div - почленное деление
max/min - почленный максимум/минимум
v1:clamp(v2) -- почленное обрезание первого вторым
average -- почленное среднее
invert -- почленная инверсия знака

v1:abs(v2); -- копирует почленно положительные компоненты в v1 из v2
lerp(v1, v2, number) -- линейная интерполяция между двумя векторами
-- если number больше 1, то выходит за них - экстраполяция

v1:reflect(v2, v3) - должно быть отражение одного вектора от плоскости, определяемой другим. Не проверял
v1:slide(v2, v3); - вероятно, проекция одного вектора на плоскость, определяемую другим. Не уверен
v1:distance_to_xz(v2) - учитывая, что плоскость XZ - это плоскость параллельная земле, то возможно это
длина проекции на землю пути от точки до точки. Не проверял

v:getP() - зенитный угол в радианах (угол наклона над плоскостью XZ )
v:getH() - азимутальный угол в радианах (угол в плоскости XZ между проекцией вектора на эту плоскость и осью Z)
setHP - соответственно для установки этих значений
v1:align() - выравнивает вектор вдоль оси x или z и нормирует его. Значение по y игнорируется.
В итоге всегда возвращается одно из четырёх значений ([1,0,0], [-1,0,0], [0,0,1], [0,0,-1])
v4:mad(v1,v2,v3) -- бешеная операция =) умножить почленно второе на третье и сложить с
первым, т.е. v4 = v1 + v2*v3 (название операции mad == mul + add)
v1:inertion(v2, number) -- v1 = v2 + (v1-v2)*number (тоже почленно)
v1:similar(v2, number) -- сравнение векторов на равенство с погрешностью number. Выдаёт 1 или 0
</code>

====Пример использования:====
<code>
local v1 = vector()
v1:set(1,2,3)
local v2 = vector():set(4,5,6)
local dist = v1:distance_to(v2)
</code>

==class fcolor==
<code>
C++ class fcolor {
property a; --альфа-цвет, отвечающий за прозрачность.
property b; --blue-цвет, отвечающий за синий оттенок цвета.
property g; --green-цвет, отвечающий за зелёный оттенок цвета.
property r; --red-цвет, отвечающий за красный оттенок цвет.

fcolor ();

function set(number, number, number, number); --установка цвета (r,g,b,a)
function set(const fcolor&); --установка цвета по уже имеющемуся классу "fcolor()"
function set(number); -- не знаю. предполагаю, что есть несколько заранее подготовленных цветов с индексами для каждого.

};
</code>

====Пример использования:====
<code>
color = fcolor()
color.a = 50
color.g = 255
color.r = 100
color.b = 50
</code>
или
<code>
color = fcolor()
color:set(100,255,50,50)
</code>

==class hit==
Бывают случаи, при которых необходимо нанести некоторый урон неписю или мобу, при этом имитировав попадание в него. Для этого существует метод класса game_object:
<code>
function hit(hit*);
</code>
Чтобы использовать этот метод, нужно указать аргументы. В данном случае имеет объект другого класса - hit. Вот его описание:

<code>
C++ class hit {
const burn = 0; --здесь идут константы типов урона, используемых в свойстве "type". Все мы прекрасно знаем, что означает каждый.
const chemical_burn = 6;
const dummy = 11;
const explosion = 7;
const fire_wound = 8;
const radiation = 4;
const shock = 1;
const strike = 2;
const telepatic = 5;
const wound = 3;

property direction; --дирекция урона
property draftsman; --обозначает персонажа, нанёсшего урон.
property impulse; --импульс урона
property power; --сила урона
property type; -- тип урона (см. константы)

hit ();
hit (const hit*);

function bone(string); --метод с указанием кости урона

};
</code>

====Пример использования:====
<code>
hit = hit() -- создание объекта класса hit
hit.direction = vector():set(1,0,0) --дирекция по оси x
hit.draftsman = db.actor --нанёс урон актор
hit.impulse = 600 --импульс
hit.power = 1.45 --хит
hit.type = 2 --тип урона - выстрел
hit:bone("bip01_head") -- удар приходится на голову
obj:hit(hit)
-- наносим урон
</code>

=="Функции времени"==
<code>
time_global() -- реальное время (в миллисекундах) с начала запуска программы
game.time() -- игровое время (в игровых миллисекундах) с начала игры (т.е. с начала прохождения игры)
level.get_time_days() -- день месяца по игровому времени
level.get_time_hours() -- час текущего игрового дня
level.get_time_minutes() -- минута текущего игрового часа

level.get_time_factor() -- возвращает отношение скорости течения игрового времени к скорости реального
--(game_time_speed / real_time_speed)
level.set_time_factor(number) -- устанавливает это отношение

game.get_game_time() -- возвращает игровое время в виде объекта класса CTime. Класс CTime я опишу подробно
-- как-нибудь потом, а пока опишу только пару его методов.
конструктор. Вызывается через пространство имён game
game.CTime()
</code>

===Дефолтовые значения===
<code>
year, month, day = 1
hour, min, sek, ms = 0
CTime.set(year, month, day, hour, min, sek, ms) -- устанавливает все данные о времени
метод CTime.get описан так:
function get(number&, number&, number&, number&, number&, number&, number&);
что наводит на мысль о семи аргументах. однако с точки зрения Lua этот метод не принимает аргументов, зато возвращает семь значений.
</code>
====Пример использования обоих методов:====
<code>
local t = game.CTime() -- создания объекта с дефолтовыми значнеиями
t:set(2009, 7, 11, 8, 11, 22, 333) -- установили все значения

local y,m,d,h,min,sec,ms = t:get() -- получили все значения
</code>
===Класс CTime (неразобранный)===
<code>
C++ class CTime {
const DateToDay = 0;
const DateToMonth = 1;
const DateToYear = 2;
const TimeToHours = 0;
const TimeToMilisecs = 3;
const TimeToMinutes = 1;
const TimeToSeconds = 2;

CTime ();
CTime (const CTime&);

function sub(CTime*);
function timeToString(number);
function dateToString(number);
operator ==(const CTime&, CTime);
function get(number&, number&, number&, number&, number&, number&, number&);
function set(number, number, number, number, number, number, number);
function setHMSms(number, number, number, number);
function diffSec(CTime*);
operator <(const CTime&, CTime);
operator +(CTime&, CTime);
operator >=(const CTime&, CTime);
function setHMS(number, number, number);
operator >(const CTime&, CTime);
operator -(CTime&, CTime);
operator <=(const CTime&, CTime);
function add(CTime*);
};
</code>

==класс CUIScriptWnd==
CUIScriptWnd(); --для работы с окном...
<code>
function _construct();
function Register(CUIWindow*);
function Register(CUIWindow*, string);
function Enable(boolean); --вкл/выкл
function SetHeight(number); --установка высоты
function GetFrameLineWnd(string);
function SetHolder(CDialogHolder*);
function GetWidth() const; --получение ширины контрола
function GetCheckButton(string);--Получение состояния checkBox ,на выходе true или false?
function DetachChild(CUIWindow*);
function SetPPMode();
function SetFont(CGameFont*); --установка шрифта по имени
function IsShown(); --проверка видно ли контрол иль нет?
function Show(boolean); --показывать контолили нет?
function GetHeight() const; --возвращает высоту
function SetWidth(number); --устанавливает ширину
function GetListWndEx(string);
function IsEnabled();
function ResetPPMode();
function GetPropertiesBox(string);
function GetFont(); --возвращает шрифт установленный setFont?
function Update();
function AddCallback(string, number, const function<void>&); --соответские контрола с действие?
function AddCallback(string, number, const function<void>&, object);--соответские контрола с действие?
function GetButton(string);--Получаем последнюю нажатую кнопку?
function SetAutoDelete(boolean);
function OnKeyboard(number, enum EUIMessages);--Колбек нажатия на клавиатуре
function Dispatch(number, number);
function GetListWnd(string);--получение окна ListBoxa?
function AttachChild(CUIWindow*);
function GetStatic(string);--получение текста метки
function SetWndPos(number, number);--установка позиции окна(x,y)
function GetTabControl(string);
function GetRadioButton(string);--состояние RadioButtton на выходите true или false
function Init(number, number, number, number);--инициализация окна...читай FormInitializatione (x,y,width,height)
function Init(Frect*);--инициализация окна
function GetFrameWindow(string);
function WindowName();
function GetDialogWnd(string);
function GetHolder();
function SetWndRect(Frect);--установка координат углов
function SetWndRect(number, number, number, number);--установка координат углов
function GetEditBox(string);--получение текста из ЭдитБокса
function SetWindowName(string);--Устанавливаем имя форме(caption)
function GetProgressBar(string);
function GetMessageBox(string);
function SetWndSize(number, number);
function Load(string);
function IsAutoDelete();
</code>

==Авторы==
Статья создана: [[Участник:malandrinus|malandrinus]], [[Участник:IQDDD|IQDDD]], [[Участник:меченый|меченый]]

[[Категория:Скрипты]]

SoC. Логика NPC

2012-07-21T09:35:16Z

188.226.13.119: /* Разбор настройки и работы планировщика на примере скрипта xr_kamp */

=Теория=

Предполагается, что читатель этой статьи знаком с языком [http://www.lua.org/ LUA] и основами объектно-ориентированного программирования.

==История==

Подход к решению проблемы игрового ИИ, выбранный создателями '''S.T.A.L.K.E.R.''' (далее буду писать просто "Сталкер"), был
впервые применён в 1957 году Гербертом Саймоном (Herbert Simon) и Алленом Ньюэллом (Allen Newell) в программе '''GPS'''
('''General Problem Solver''' или '''Универсальный Решатель Задач''').

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

В Сталкере подсистема поиска последовательности операторов называется '''планировщик'''.

==ИИ в Сталкере==

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

Условия в игре тоже вычисляются динамически. Для этого используются специальные объекты – эвалуаторы. Эвалуатор
должен содержать метод '''evaluate()''', возвращающий '''true''', если условие выполняется и '''false''' в противном случае. Операторы также представлены как объекты. Планировщик вызывает метод '''initialize()''' при начале работы оператора, затем он
периодически вызывает метод '''execute()'''.

Например, можно создать эвалуатор для условия '''NPC голоден''', и привязать к этому условию оператор '''поесть'''.

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

К сожалению, в большей части скриптов все возможности планировщика не используются.

===Разбор настройки и работы планировщика на примере скрипта xr_kamp===

Рассмотрим скрипт '''xr_kamp''', заставляющий сталкеров сидеть у костра и рассказывать анекдоты.
Настройка планировщика осуществляется в функции '''add_to_binder'''. Параметры функции: '''object''' – объект, для которого
настраивается планировщик (в нашем случае это сталкер), '''ini''', '''scheme''', '''section''' – инициализационный файл, название
схемы действий, секция ини-файла (эти параметры будут подробно разобраны в части по созданию мода), '''storage''' –
таблица для хранения текущих параметров схемы действий.

Разберём, что делает эта функция.

Сначала получаем планировщик для текущего объекта ('''object'''):

<lua>
local manager = object:motivation_action_manager()
</lua>

Затем присваиваем идентификаторы операторов и условий элементам массива. Это сделано просто для удобства.

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

<lua>
properties["kamp_end"]=xr_evaluators_id.stohe_kamp_base+1
properties["on_position"]=xr_evaluators_id.stohe_kamp_base+2
properties["contact"]=xr_evaluators_id.stohe_meet_base+1
operators["go_position"]=xr_actions_id.stohe_kamp_base+1
operators["wait"]=xr_actions_id.stohe_kamp_base+3
</lua>

Для каждого идентификатора условия создадим соответствующий эвалуатор и добавим его в планировщик. В данном случае
это условия: '''закончить ли посиделки около костра?''' и '''пришёл ли я на своё место у костра?'''.

<lua>
manager:add_evaluator (properties["kamp_end"], this.evaluator_kamp_end ("kamp_end", storage, "kamp_end"))
manager:add_evaluator (properties["on_position"], this.evaluator_on_position ("kamp_on_position", storage, "kamp_on_position"))
</lua>

Теперь создадим оператор '''сидеть около костра, рассказывать анекдоты, жевать колбасу и т.д.'''. Можно было бы
реализовать эти действия как набор разных операторов, выбором которых занимался бы планировщик, но автор скрипта
решил сделать один сложный оператор.

<lua>
local action = this.action_wait (object:name(),"action_kamp_wait", storage)
</lua>

Задаем предусловия для этого оператора. Планировщик выберет этот оператор при выполнении всех условий. Всё это
значит примерно следующее: я могу сидеть у костра, если:

<lua>
action:add_precondition (world_property(stalker_ids.property_alive, true))
</lua>
я живой,

<lua>
action:add_precondition (world_property(stalker_ids.property_danger,false))
</lua>
опасностей нет,

<lua>
action:add_precondition (world_property(stalker_ids.property_enemy, false))
</lua>
врагов нет,

<lua>
action:add_precondition (world_property(stalker_ids.property_anomaly,false))
</lua>
аномалий поблизости нет,

<lua>
xr_motivator.addCommonPrecondition(action)
</lua>
выполняются другие важные условия (игрок не собирается со мной поговорить, я не собираюсь никого бить по морде, я не
ранен, я не собираюсь стрелять по вертолёту),

<lua>
action:add_precondition (world_property(properties["on_position"], true))
</lua>
я уже нахожусь около костра.

Скажем планировщику, что он должен ожидать от выполнения этого оператора. В данном случае после выполнения этого
оператора условие '''закончить ли посиделки около костра?''' должно стать истинным. То есть если условие стало истинным,
планировщик прекратит выполнение оператора.

<lua>
action:add_effect (world_property(properties["kamp_end"], true))
</lua>

Создание оператора завершено. Добавим его в планировщик.

<lua>
manager:add_action (operators["wait"], action)
</lua>

Эта строчка не имеет отношения к работе планировщика. Если коротко, то она позволяет объекту получать уведомления об
определённых событиях (смерть NPC – вызывается метод '''death_callback()''', попадание пули в NPC – вызывается метод
'''hit_callback()''' и т.д.)

<lua>
xr_logic.subscribe_action_for_events(object, storage, action)
</lua>

Создаем оператор, отвечающий за доставку NPC к его месту у костра.

<lua>
action = this.action_go_position (object:name(),"action_go_kamp", storage)
</lua>

Добавляем предусловия, как и для предыдущего оператора.

<lua>
action:add_precondition (world_property(stalker_ids.property_alive, true))
action:add_precondition (world_property(stalker_ids.property_danger,false))
action:add_precondition (world_property(stalker_ids.property_enemy, false))
action:add_precondition (world_property(stalker_ids.property_anomaly,false))
xr_motivator.addCommonPrecondition(action)
action:add_precondition (world_property(properties["on_position"], false))
</lua>

Единственное отличие – последнее условие. Этот оператор будет выполняться только если NPC ещё не находится на своем
месте у костра, то есть если функция '''evaluator_on_position.evaluate()''' возвращает '''false'''.

В результате выполнения этого действия условие '''на своём ли я месте у костра?''' должно стать истинным.

<lua>
action:add_effect (world_property(properties["on_position"], true))
</lua>

Создание оператора завершено. Добавляем его к планировщику.

<lua>
manager:add_action (operators["go_position"], action)
</lua>

Осталось ещё одна задача. Нужно запретить планировщику активировать оператор '''alife''', тот самый оператор, который
заставляет NPC болтаться по карте, отстреливать собачек и в конце концов попадать в аномалию. Впрочем, отстрелом
врагов занимается другой оператор с идентификатором '''stalker_ids.action_combat_planner'''.

Для этого мы получаем оператор '''alife''':

<lua>
action = manager:action (xr_actions_id.alife)
</lua>

И добавляем к его предусловиям следующее: условие '''закончить ли посиделки у костра?''' должно быть истинным.

<lua>
action:add_precondition (world_property(properties["kamp_end"], true))
</lua>

Итак, мы настроили планировщик. Посмотрим как всё это будет работать.

В некоторый момент времени гулаг, в который попал NPC, назначает ему работу: сидеть у костра. В результате условие
'''закончить ли посиделки у костра?''' становится ложным. Планировщик видит это изменение и пытается выработать
последовательность операторов, после выполнения которой, условие бы стало истинным и NPC снова бы вернулся к
выполнению высокоприоритетного оператора '''alife'''. Для выполнения этой задачи подходит оператор '''посиделки у костра''',
но для него не выполняется условие '''я на своем месте у костра'''. Поэтому планировщик создаёт план из двух операторов:
'''дойти до костра''' и '''посиделки у костра'''. Если во время выполнения одного из операторов возникнет непредвиденная
ситуация (появится враг, главный герой начнёт приставать с вопросами и т.п.), то планировщик скорректирует план,
добавив оператор для устранения этой непредвиденной ситуации.

Как видно, система ИИ в Сталкере обладает весьма большой гибкостью, что мы и продемонстрируем при создании мода.

==Модели (или схемы) поведения в Сталкере==

В наборе скриптов Сталкера предусмотрена возможность объединять операторы и условия в модели поведения. Модель
поведения – это набор логически связанных операторов и условий, служащих для выполнения определённой задачи. Так
скрипт '''xr_kamp''' представляет собой модель поведения, состоящую из двух операторов и двух условий.

===Регистрация модели поведения===

Для включения новой модели поведения в набор моделей, доступных NPC, сначала необходимо её зарегистрировать.
Предположим, нам нужно зарегистрировать модель поведения, описанную в скрипте '''actor_need_help.script'''. Регистрация
моделей осуществляется в скрипте '''modules.script'''. Добавим туда следующие строки:

<lua>
if actor_need_help then –- в этой строке мы проверяем что наш скрипт действительно существует
load_scheme("actor_need_help", "actor_need_help", stype_stalker)
end
</lua>

Первый параметр функции '''load_scheme''' задает имя файла скрипта, второй параметр – это название модели поведения,
третий параметр – тип модели поведения (возможны следующие значения: '''stype_stalker''' – модель поведения NPC,
'''stype_mobile''' – модель поведения монстра, '''stype_item''' – «модель поведения» физического объекта, '''stype_heli''' – модель
поведения вертолёта, '''stype_restrictor''' – «модель поведения» области пространства). Скрипты для моделей поведения
разных типов пишутся по-разному. Мы будем рассматривать только модели поведения NPC.

Внимание! Для успешной работы модели поведения её скрипт должен содержать функцию '''add_to_binder''', выполняющую
настройку планировщика.

===Активация/деактивация модели поведения===

Некоторые модели поведения применимы в любых ситуациях (например, реакция на попадание пули в NPC или реакция на
появление врага). Такие модели должны активироваться/деактивироваться в функциях '''enable_generic_schemes()/disable_generic_schemes()''' скрипта '''xr_logic'''. В случае с моделью поведения '''actor_need_help''' это будет выглядеть так:

'''1.''' Создаём функции '''set_actor_need_help''' и '''disable_scheme''' в нашем скрипте '''actor_need_help'''. Эти функции будут отвечать за активацию и деактивацию нашей модели поведения.

<lua>
function set_actor_need_help(npc,ini,scheme)
local st=xr_logic.assign_storage_and_bind(npc, ini, scheme, “actor_need_help”)
st.enabled=true
end
function disable_scheme(npc,scheme)
local st = db.storage[npc:id()][scheme]
if st then
st.enabled = false
end
end
</lua>

'''2.''' Добавляем следующую строку в скрипт '''xr_logic.script'' после строки '''if stype == modules.stype_stalker then''' в
функции '''enable_generic_schemes()''':

<lua>
actor_need_help.set_actor_need_help(npc,ini,”actor_need_help”)
</lua>

'''3.''' Добавляем следующую строку в скрипт '''xr_logic.script''' после строки '''if stype == modules.stype_stalker then''' в
функции '''disable_generic_schemes()''':

<lua>
actor_need_help.disable_scheme(npc,”actor_need_help”)
</lua>

Если же модель поведения предназначена только для использования в определённых ситуациях, то достаточно выполнить
шаг '''1''' и использовать созданные функции по мере надобности. Например, активируя эту схему через диалог с NPC (как мы
и сделаем в нашем моде).

Внимание! Я максимально упростил функции активации/деактивации модели поведения. Чтобы полностью разобраться с ними,
посмотрите скрипты '''xr_combat''', '''xr_kamp''' и другие подобные.

===Приоритеты моделей поведения===

Некоторые модели поведения настолько важны, что должны срабатывать в любой ситуации (например, реакция на попадание
пули). Для этого в скрипте '''xr_motivator''' предусмотрена функция '''addCommonPrecondition(action)''', в эту функцию можно
добавить одно из условий нашей модели поведения, чтобы другие модели поведения не могли сработать при выполнении
этого условия (здесь есть свои тонкости, но мы рассмотрим их позже). Предположим, что у нас есть модель поведения
'''actor_need_help''', заставляющая NPC подбежать к ГГ и вылечить его. Пусть за проверку здоровья ГГ отвечает условие с
идентификатором '''actor_need_help.property_actor_is_wounded'''. Значит, если мы хотим, чтобы NPC подбегал к ГГ, не обращая
внимание ни на что другое, то нужно добавить следующую строчку в функцию '''addCommonPrecondition(action)''':

<lua>
action:add_precondition(world_property(actor_need_help.property_actor_is_wounded,false))
</lua>

Эта строчка запретит выполнение всех других действий, если условие с идентификатором
'''actor_need_help.property_actor_is_wounded''' станет истинным (в нашем случае это будет означать, что ГГ сильно ранен).

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

=Создаем мод=

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

==Постановка задачи==

Итак, мы хотим, чтобы дружественные NPC наконец начали приносить пользу. Для этого научим их лечить ГГ во время боя.
Распишем по пунктам:

'''1.''' Нужно добавить дружественным NPC ветку в диалоге с просьбой присматривать за ГГ и лечить его, если в этом
возникнет необходимость.

'''2.''' Добавить NPC модель поведения, реализующую выполнение этой просьбы.

'''2.1.''' NPC должен действовать согласно этой модели только если ГГ находится недалеко от него.

'''2.2.''' NPC не должен далеко отходить от ГГ во время боя.

'''2.3.''' Если здоровье ГГ упало ниже определённой отметки, NPC должен подойти/подбежать и вылечить ГГ.

==Что потребуется для реализации==

Нам придётся изменять диалоги для некоторых NPC, для этого нужно будет изменить файлы
'''config\gameplay\character_dialogs.xml''' (диалоги для всех NPC), '''config\localization.ltx''' и '''config\system.ltx''' (подробнее см. статью '''BAC9-FLCL''' или '''Fr3nzy'''). Мы изменим диалоги для всех NPC, но для неподходящих NPC диалог будет отсекаться с помощью предусловия. Потребуется также добавить файлы с текстами диалогов и функции для проверки условий,
используемых в диалогах.

Для включения новой модели поведения NPC нужно будет внести изменения в скрипты '''scripts\modules.script''' (регистрация
моделей поведения) и '''scripts\xr_motivator.script''' (для установки высокого приоритета нашей модели). Модификации файла
'''xr_logic.script''', в котором происходит установка общих моделей поведения, не потребуется, так как мы будем
активировать нашу схему поведения при выборе определённой ветки в диалоге.

Теперь решим, какие условия и операторы нам понадобятся.

Условия:

'''1.''' Состояние главного героя. Если оно ниже определённого порога, то условие станет истинным. Назначим ему
идентификатор '''property_actor_is_wounded''' и эвалуатор '''evaluator_actor_is_wounded'''. Далее я буду указывать идентификатор
и эвалуатор в скобках через запятую.

'''2.''' Находится ли NPC достаточно близко, чтобы вылечить ГГ ('''property_ready_to_heal, evaluator_ready_to_heal''').

'''3.''' Есть ли у NPC аптечки ('''property_has_medkit''', '''evaluator_has_medkit''').

'''4.''' Не отошёл ли NPC слишком далеко от ГГ или ГГ от NPC ('''property_faraway''', '''evaluator_faraway''').

'''5.''' Находится ли ГГ достаточно близко, чтобы имело смысл помогать ему ('''property_near_enough''', '''evaluator_near_enough''').

Операторы:

'''1.''' Лечить ГГ ('''act_heal''', '''action_heal''').

'''2.''' Подбежать к ГГ на дистанцию, достаточную для лечения ('''act_run_to_actor''', '''action_run_to_actor''').

'''3.''' Крикнуть, что аптечки кончились ('''act_no_medkit''', '''action_no_medkit''').

'''4.''' Подобраться поближе к ГГ, чтобы быть под рукой ('''act_stay_close''', '''action_stay_close''').

==Реализация==

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

===Диалоги===

В этом моде будет всего один диалог, и довольно простой, поэтому начнём с него. Создаём файл
'''config\gameplay\dialogs_need_help.xml'''. Чтобы не возиться с идентификаторами текстов, попробуем обойтись без них.
Начнём с простой тестовой версии:

<xml>
<?xml version="1.0" encoding="windows-1251" standalone="yes" ?>
<game_dialogs>
<dialog id="actor_will_need_help">
<precondition>actor_need_help.i_am_friend</precondition>
<phrase_list>
<phrase id="0">
<text>Дружище, сможешь присмотреть за мной, если стрелять начнут? Промедольчику, там, вколоть или
перевязку сделать, если что...</text>
<next>1</next>
</phrase>
<phrase id="1">
<text>Нет проблем, конечно помогу.</text>
</phrase>
</phrase_list>
</dialog>
</game_dialogs>
</xml>

Добавляем строку с идентификатором этого диалога в '''config\gameplay\character_dialogs.xml''':

<xml>
<actor_dialog>actor_will_need_help</actor_dialog>
</xml>

Дописываем имя файла диалога в '''config\system.ltx''' в секцию '''dialogs'''. Осталось создать функцию '''i_am_friend'''. Наш
скрипт с моделью поведения будет называться '''scripts\actor_need_help.script''', заодно пропишем там и диалоговые
функции.

<lua>
function i_am_friend(actor,npc)
return npc:relation(actor)==game_object.friend
end
</lua>

При первом тестировании я заменил '''game_object.friend''' на '''game_object.neutral''', чтобы не искать друзей по всей карте.

Тестируем, что у нас получилось...

Диалог работает, но вместо текста – набор значков, оказалось, я написал текст в кодировке '''CP866 (DOS)''', нужно
поменять её на '''CP1251'''. Так, теперь текст в порядке.

Выбранный подход к созданию диалога оказался удачным.

Обратите внимание, вместо идентификатора текста можно вписать сам текст. Это усложнит локализацию, но уменьшит время
создания диалогов.

Теперь нам понадобятся функции проверки наличия аптечек у NPC, проверки активации схемы поведения,
активации/деактивации схемы поведения. Добавляем их в наш скрипт-файл.

Первый вариант скрипта я не буду приводить, чтобы не увеличивать и так большую статью. Окончательный вариант
смотрите в конце статьи. Дальше по тексту идёт простейший работающий вариант.

Теперь у нас должно быть два варианта начальной фразы для активной и неактивной схемы. Придётся экспериментировать.

Вот первый проверенный вариант:

<xml>
<?xml version="1.0" encoding="windows-1251" standalone="yes" ?>
<game_dialogs>
<dialog id="actor_will_need_help">
<precondition>actor_need_help.i_am_friend</precondition>
<phrase_list>
<phrase id="0">
<next>1</next>
<next>2</next>
</phrase>
<phrase id="1">
<text>Дружище, сможешь присмотреть за мной, если стрелять начнут? Промедольчику, там, вколоть или
перевязку сделать, если что...</text>
<precondition>actor_need_help.scheme_is_not_active</precondition>
<next>11</next>
<next>12</next>
</phrase>
<phrase id="11">
<text>Нет проблем, конечно помогу.</text>
<precondition>actor_need_help.npc_have_medkit</precondition>
<action>actor_need_help.activate_scheme</action>
</phrase>
<phrase id="12">
<text>Извини, друг, аптечек совсем не осталось.</text>
<precondition>actor_need_help.npc_havent_medkit</precondition>
</phrase>
<phrase id="2">
<text>Спасибо, друг, теперь я сам справлюсь.</text>
<precondition>actor_need_help.scheme_is_active</precondition>
<next>21</next>
</phrase>
<phrase id="21">
<text>Да не за что, ты мне помог, я - тебе.</text>
<action>actor_need_help.deactivate_scheme</action>
</phrase>
</phrase_list>
</dialog>
</game_dialogs>
</xml>

При первом запуске игра вылетела без сообщений об ошибках. Я внимательно просмотрел все файлы и оказалось, что в
скриптах вместо комментария '''--''' (два минуса) я поставил просто минус (рекомендую пользоваться компилятором с
[http://www.lua.org www.lua.org] для проверки корректности скриптов). После исправления ошибки игра запустилась, но диалог так и не
появился. Небольшая дискуссия на форуме (спасибо Z.E.N. и Arhet) показала, что придётся сделать два диалога.

Кроме того, при тестах первых вариантов, выяснилось, что всегда выбирается вариант диалога с просьбой о помощи. То
есть схема поведения не активируется.

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

Итак, все проблемы решены. Файл диалога принял следующий вид ('''config\gameplay\dialogs_need_help.xml'''):

<xml>
<?xml version="1.0" encoding="windows-1251" standalone="yes" ?>
<game_dialogs>
<dialog id="actor_will_need_help">
<precondition>actor_need_help.i_am_friend</precondition>
<precondition>actor_need_help.scheme_is_not_active</precondition>
<phrase_list>
<phrase id="0">
<text>Дружище, сможешь присмотреть за мной, если стрелять начнут? Промедольчику, там, вколоть или
перевязку сделать, если что...</text>
<next>11</next>
<next>12</next>
</phrase>
<phrase id="11">
<precondition>actor_need_help.npc_have_medkit</precondition>
<text>Нет проблем, конечно помогу.</text>
<action>actor_need_help.activate_scheme</action>
</phrase>
<phrase id="12">
<precondition>actor_need_help.npc_havent_medkit</precondition>
<text>Извини, друг, аптечек совсем не осталось.</text>
</phrase>
</phrase_list>
</dialog>
<dialog id="actor_will_not_need_help">
<precondition>actor_need_help.i_am_friend</precondition>
<precondition>actor_need_help.scheme_is_active</precondition>
<phrase_list>
<phrase id="0">
<text>Спасибо, друг, теперь я сам справлюсь.</text>
<next>21</next>
</phrase>
<phrase id="21">
<text>Да не за что, ты мне помог, я - тебе.</text>
<action>actor_need_help.deactivate_scheme</action>
</phrase>
</phrase_list>
</dialog>
</game_dialogs>
</xml>

Функции, поддерживающие работу диалога, теперь выглядят так (файл '''scripts\actor_need_help.script'''):

<lua>
function i_am_friend(talker,target)
return target:relation(talker)==game_object.friend
end

-- За основу этой функции взята функция dialogs.actor_have_medkit
function npc_have_medkit(talker, target)
return talker:object("medkit") ~= nil or
talker:object("medkit_army") ~= nil or
talker:object("medkit_scientic") ~= nil
end
function npc_havent_medkit(talker, target)
return not npc_have_medkit(talker,target)
end

-- Так как модель поведения еще не написана, вставим заглушки
local scheme_status={}
function scheme_is_active(talker,target)
return scheme_status[target:id()]==true -- сравниваем с true, чтобы функция не возвращала nil
end
function scheme_is_not_active(talker,target)
return not scheme_is_active(talker,target)
end
function activate_scheme(talker,target)
scheme_status[talker:id()]=true
end
function deactivate_scheme(talker,target)
scheme_status[talker:id()]=nil -- присваиваем nil, чтобы освободить память, занятую этим элементом массива
end
</lua>

И в файл '''config\gameplay\character_dialogs.xml''' добавлены строки:

<xml>
<actor_dialog>actor_will_need_help</actor_dialog>
<actor_dialog>actor_will_not_need_help</actor_dialog>
</xml>

В результате получился работающий диалог, но NPC выглядит просто как ходячая аптечка. В окончательном варианте, я
добавил некоторые «человеческие» реакции. Да и сама модель поведения пока отсутствует - вместо неё стоят заглушки. Исправим это.

===Модель поведения===

Начнём создание модели поведения с разработки эвалуаторов. Эвалуатор должен представлять собой объект класса унаследованного от класса '''property_evaluator'''.

Возьмём для начала эвалуатор '''evaluator_faraway''', определяющий, что NPC находится слишком далеко от ГГ. Этот эвалуатор требуется для того, чтобы NPC не отходил слишком далеко от ГГ и мог в случае надобности быстро подбежать к нему и оказать помощь.

Объявляем класс эвалуатора:

<lua>
class "evaluator_faraway" (property_evaluator)
</lua>

Определяем функцию инициализации (в LUA это аналог конструктора объекта):

<lua>
function evaluator_faraway:__init(name, storage) super (nil, name)
self.st = storage
end
</lua>

Ключевое слово '''super''' служит для вызова конструктора базового класса. Член '''st''' будет хранить ссылку на таблицу состояния нашей модели поведения.

Теперь нужно определить функцию '''evaluate()''', ради которой и создавался эвалуатор. По-видимому всё просто, нужно проверить расстояние от NPC до ГГ и вернуть '''true''', если это расстояние больше определённого значения. Но давайте подумаем. Когда эвалуатор возвратит '''true''', заработает оператор, заставляющий NPC подойти поближе к ГГ, то есть расстояние моментально уменьшится и эвалуатор начнёт возвращать '''false''', что приведёт к переходу NPC под управление игрового ИИ. ИИ может опять решить удалиться от ГГ, что приведёт к повторному срабатыванию эвалуатора. В результате возникнет замкнутый цикл, и NPC будет крутиться на одном месте (на самом деле этот цикл рано или поздно разорвётся из-за изменения игровой ситуации, но лучше вообще избежать его).

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

<lua>
local min_faraway_dist=10
local max_faraway_dist=20

function evaluator_faraway:evaluate()
local actor=db.actor
if not actor then
-- ГГ ещё не заспаунился
return false
end
local dist=actor:position():distance_to(self.object:position())
if dist>max_faraway_dist then
self.st.faraway=true
elseif dist<min_faraway_dist then
self.st.faraway=false
end
return self.st.faraway==true
end
</lua>

Эвалуатор готов, но нужно как-то его протестировать. Поэтому давайте создадим минимальную модель поведения из одного условия и одного оператора. Нам нужен оператор, перемещающий NPC поближе к ГГ. Объявляем класс '''action_stay_close''', унаследованный от '''action_base''', и определяем его конструктор.

<lua>
class "action_stay_close" (action_base)

function action_stay_close:__init(name, storage) super (nil, name)
self.st=storage
end
</lua>

Оператор должен содержать функции '''initialize()''', '''execute()''' и, возможно, '''finalize()'''.

Функция '''initialize()''' вызывается при начала работы оператора, то есть в момент, когда планировщик ставит этот оператор в первую позицию плана.

<lua>
function action_stay_close:initialize()
local npc=self.object
-- Не знаю зачем эти две функции, но они используются во всех операторах
npc:set_desired_position()
npc:set_desired_direction()
-- Сбрасываем текущие анимации
npc:clear_animations()
-- Задаём параметры движения
npc:set_detail_path_type(move.line)
npc:set_body_state(move.standing)
npc:set_movement_type(move.run)
npc:set_path_type(game_object.level_path)
-- Эксперименты показали, что эта функция устанавливает скорость движения (anim.danger -
минимальная скорость, anim.free - нормальная, anim.panic - максимальная)
npc:set_mental_state(anim.panic)
-- Повышаем зоркость NPC
npc:set_sight(look.danger, nil, 0)
-- Освободим сталкера от всех идиотских ограничений
npc:remove_all_restrictions()
-- Зададим смещение точки назначения, чтобы помощники не сбивались в кучу
self.offset=vector():set(math.random()*6-3,0,math.random()*6-3)
self.offset:normalize()
end
</lua>

Функция '''execute()''' периодически вызывается во время выполнения оператора. Частота вызовов, по-видимому, зависит от расстояния от NPC до ГГ.

<lua>
function action_stay_close:execute()
local npc=self.object
local actor=db.actor
if not actor then
-- Хм, что-то не так. Может быть ГГ перешёл на другой уровень? Запрещаем схему поведения
self.st.enabled=false
end
-- Получаем ближайшую доступную точку в 5 метрах от ГГ
-- Сначала, я попробавал использовать функцию npc:vertex_in_direction, но она не работает
local vertex_id=level.vertex_in_direction(actor:level_vertex_id(),self.offset,5)
local act_v_id=actor:level_vertex_id()
-- Отправляем нашего NPC в найденную точку
local acc_id=utils.send_to_nearest_accessible_vertex( npc, vertex_id )
if self.st.dist and self.st.dist>max_faraway_dist then
-- если NPC находится слишком далеко от ГГ пусть пробежиться побыстрее
npc:set_mental_state(anim.panic)
else
npc:set_mental_state(anim.free)
end
end
</lua>

Функция настройки планировщика.

<lua>
function add_to_binder(object, char_ini, scheme, section, st)
local manager = object:motivation_action_manager()
local property_wounded = xr_evaluators_id.sidor_wounded_base

-- Удаляем эвалуатор, так как в xr_motivator мы установили его в property_evaluator_const
manager:remove_evaluator(property_faraway)
-- и заменяем его нашим
manager:add_evaluator(property_faraway, evaluator_faraway("evaluator_faraway",st))
-- Создаём оператор
local action = action_stay_close("action_stay_close",st)
-- и настраиваем предусловия. 1. Сталкер жив
action:add_precondition(world_property(stalker_ids.property_alive, true))
-- 2. Сталкер не ранен
action:add_precondition(world_property(property_wounded, false))
-- Я использую свой мод для обхода аномалий, иначе от помощников мало толку.
if anomaly_evader then
-- 3. Рядом нет аномалий
action:add_precondition (world_property(1099,false))
end
-- 4. Сталкер слишком далеко от ГГ
action:add_precondition(world_property(property_faraway, true))
action:add_effect (world_property(property_faraway, false))
-- Добавляем оператор в планировшик
manager:add_action (act_stay_close, action)
-- Теперь подкорректируем стандартные операторы, чтобы помощник не отвлекался на всякую ерунду.
action=manager:action(stalker_ids.action_alife_planner)
action:add_precondition(world_property(property_faraway, false))
action=manager:action(stalker_ids.action_combat_planner)
action:add_precondition(world_property(property_faraway, false))
action=manager:action(stalker_ids.action_danger_planner)
action:add_precondition(world_property(property_faraway, false))
end
</lua>

Добавим функции активации/деактивации схемы поведения.

<lua>
function set_help(npc, ini)
local st = xr_logic.assign_storage_and_bind(npc, ini, "actor_need_help")
st.enabled=true
end
function disable_scheme(npc, scheme)
local st = db.storage[npc:id()][scheme]
if st then
st.enabled = false
end
end
</lua>

Изменим диалоговые функции-заглушки.

<lua>
function activate_scheme(talker,target)
set_help(talker,talker:spawn_ini())
scheme_status[talker:id()]=true
end
function deactivate_scheme(talker,target)
disable_scheme(talker,"actor_need_help")
scheme_status[talker:id()]=nil
end
</lua>

Добавим в функцию '''xr_motivator.addCommonPrecondition()''' следующие строки, чтобы заблокировать стандартные схемы поведения.

<lua>
if actor_need_help then
action:add_precondition (world_property(actor_need_help.property_faraway,false))
end
</lua>

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

<lua>
local manager = self.object:motivation_action_manager()
if actor_need_help then
manager:add_evaluator(actor_need_help.property_faraway, property_evaluator_const(false))
end
</lua>

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

===Файлы мода===

Мод можно скачать [http://sdk.stalker-game.com/ru/images/4/47/%D0%9D%D0%B0%D0%BF%D0%B0%D1%80%D0%BD%D0%B8%D0%BA%D0%B8_0.2.zip здесь].

Ссылка обновлена. Выложена новая версия. Причиной "зависаний" NPC был конфликт со '''state_mgr.script'''. Код мода, приведённый в статье, не устанавливал состояние NPC с помощью '''state_mgr.set_state()''', в результате '''state_mgr''' пытался вернуть состояние NPC к начальному (до срабатывания нашей модели поведения), что и приводило к "зависаниям".

Более подробное описание мода смотри [http://sdk.stalker-game.com/ru/index.php?title=Mod:%D0%9D%D0%B0%D0%BF%D0%B0%D1%80%D0%BD%D0%B8%D0%BA%D0%B8 здесь].

----

Спасибо за внимание,
Red75

=Авторы=

Статья создана:

* [[Участник:Red75|Red75]]

[[Категория:A-Life]][[Категория:Скрипты]]

Исправление дефектов сглаживания на импортированных моделях...

2011-08-03T19:31:18Z

188.226.13.119: /* ...в 3ds Max */

==...в MilkShape 3D==


Итак, в конвертере бардака, а так же (естественно) в его плагине для импорта моделей в 3Д редакторы есть одна крайне неприятная особенность: слетают группы сглаживания (или как там это правильно называется), и, когда потом модель через СДК экспортируется в ОГФ на модели возникают дефекты такого вида:

[[Файл:Ms3d bad smooth.jpg||400px]]

Что сделать для исправления (способ найден и проверен в '''Milkshape 3D''', как это делать в других редакторах не знаю, так как не пользуюсь)

Выделяем всю модель или нужную область, потом ''Vertex - Weld Together'' и... наша моделька ровная и гладенькая

[[Файл:Ms3d bad smooth_2.jpg||400px]]

Теперь её можно спокойно экспортировать в СДК.

'''Т.е. напрямую загонять модели в СДК (через преобразование конвертером) не рекомендую во избежании этих дефектов, а они будут 100%'''

==...в 3ds Max==

По просьбе '''blackraven6''' добавляю способ по решению этой проблемы в '''3D Max''' (за что ему отдельное спасибо)

В '''3D Max''' выделяем модель, далее ''Modifiers - Subdivision surface - Mesh smooth'' и справа в свитке ''subdivisions amount'' в поле ''iterations'' ставим вместо 1 (по дефолту) 0.
Тогда модели добавляется только визуальный эффект сглаживания без добавления дополнительных сглаживающих полигонов.

----

Ещё один способ, предложенный '''adept''' для '''3D Max'''

[[Файл:3dsmax bad smooth.jpg||400px]]

Выделяем модель и переходим на вкладку ''Modify'' (1)

Открываем вкладку модификаторов (2)

Выбираем модификатор ''Smooth'' (3)

Модель стала граненная

[[Файл:3dsmax bad smooth_2fx.jpg||400px]]

Теперь нужно поставить галочку ''Auto Smooth''. Все, модель сгладилась. Для регулировки уровня сглаживания нужно поставить галочку ''Prevent Indirect Smoothing'' и клацать на кнопочки возле надписи ''Threshold'', стандартно сглаживание стоит на цифре 30

[[Файл:3dsmax bad smooth_3fx.jpg||400px]]

* Также можно использовать другой способ: открываем редактирование в Editable Mesh, нажимаем Polygon (или Element), выделяем всю модель и находим в редактировании полигонов квадратик из 32 (вроде там столько) чисел. Нажимаем "1" и модель сглажена.


По-человечески это называется "задать группы сглаживания" :) --[[Участник:RedPython|RedPython]] 18:04, 17 апреля 2011 (UTC)


Авторы: '''Deathdoor''' (OGSE team), '''blackraven6''', '''adept''', [[Участник:Rekongstor|Rekongstor]]

==...в Maya==

Если в импортированной, например, из 3ds Max'а модели имеются видимые артефакты, то нужно разблокировать нормали, выполнив '''''Normals-->Unlock Normals''''' и затем '''''Normals-->Set to Face''''', при этом в опциях '''''Set to Face''''' должен стоять флажок '''''Match face normal'''''.

[[Файл:Maya bad face normals 1.png|400px]] [[Файл:Maya bad face normals 2.png|400px]]

Т.к. в Maya нет понятия "группы сглаживания", а есть вершинные нормали, то поиск несуществующего пункта меню поначалу ставит в тупик новичка. Выходим из положения, выполнив '''''Shift+RMB-->Soften/Harden Edge-->Soften Edge''''':

[[Файл:Maya bad face normals 3fx.png|400px]] [[Файл:Maya smooth face normals.png|325px]]

--[[Участник:RedPython|RedPython]] 18:04, 17 апреля 2011 (UTC)

[[Категория:Wireframe]]