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

Скриптовые шейдеры

2014-10-10T16:16:26Z

91.217.2.224:

Редактируя любую модель, многие в свойствах поверхностей замечали графу shader, в которой указывается нечто вроде models/model или подобные.
Как правило, эти шейдеры упакованы в '''shaders.xr''' и '''shaders_xrlc.x'''r, которые представляют собой своеобразную базу данных шейдеров, собранных по определенным шаблонам.

Но кроме этих баз данных есть еще и скриптовые шейдеры, которые имеют приоритет перед теми шейдерами, что упакованы в *.xr. Это файлы, имеющие расширение .s и лежащие в папках соответствующих рендеров. Вычислить правильное название шейдера в БД и шейдерного скрипта '''.s''' можно очень просто - для примера, если у нас в БД шейдер находится в '''model/selflight''', то имя шейдера должно быть '''model_selflight.s''', если details/blend, то скрипт шейдера будет, соответственно, '''details_blend.s'''. Не так уж сложно.

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

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

По некоторым причинам я считаю что для модостроителей шейдерные скрипты являются более предпочтительными, чем распространение своих шейдерных модов в виде модифицированной .xr-БД. Причины в основном две: Во-первых скриптовые шейдеры предоставляют бОльшие возможности для полета фантазии, а во-вторых распространение шейдерных модов в виде скриптовых шейдеров все же делает меньше вероятность конфликта модов, так как разные шейдеры будут в разных файлах, а не все вместе в одном хитром и трудноредактируемом, и, что самое плохое, - труднообъединяемом файле. Поэтому далее мы рассмотрим скриптовые шейдеры.

Что собой представляют шейдерные скрипты? Это скрипты на HLSL (High Level Shader Language), которые являются своеобразным языком для того чтобы объяснить движку, какие загружать текстуры и какие подключать шейдеры из наличествующих .ps и .vs файлов.

: ''Для тех кто воспрял духом сразу скажу, что несмотря на то, что шейдерные скрипты написаны на языке, который используется в игровых скриптах, это все-таки не одно и то же. Во-первых шейдерные скрипты выполняются при загрузке уровня всего один раз (в фазу загрузки "загрузка шейдеров"), поэтому на отрисовку в реальном времени влиять неспособны, и кроме того, к игровым скриптам скриптовые шейдеры доступа не имеют.''

Вот, для примера, содержимое простейшего скриптового шейдера:

<lua>function normal( shader, t_base, t_second, t_detail )
shader:begin( "effects_gradient", "effects_gradient_p" )
end</lua>

Разберем его по косточкам:

* '''function normal''' - объявление стандартной функции шейдерного скрипта. В некоторых шейдерах есть еще функции '''l_spot''', '''l_point''', '''l_special''' и '''normal_hq''' аналогичного содержания, но явно просчитывающие поведение этого шейдера в условиях освещения

* '''shader''' - вероятнее всего идентификатор шейдера в игре, содержимое этой переменной обычно представляет собой текстовую строку вроде "models_selflight" или "models/selflight".
* '''t_base''' - путь к текстуре, которую следует выводить с помощью этого шейдера
* '''t_second''', '''t_detail''' - пути к другим текстурам, пока назначение их неизвестно.

* '''shader:begin( "effects_gradient", "effects_gradient_p" )''' - святая святых шейдера. Если точнее - создание объекта шейдера как такового.
:: '''effects_gradient''' - имя .vs файла используемого в этом шейдере
:: '''effects_gradient_p''' - имя .ps файла соответственно.

После этой строки могут быть такие строки (они необязательны)

* ''': blend ( true, blend.srcalpha, blend.one )''' - настройка блендинга для текстур с альфой, например, полупрозрачные текстуры без применения этой строки будут выглядеть непрозрачными черными в прозрачных местах. Эти методы блендинга соответствуют переключателю в сдк, где варианты ALPHA-ADD, BLEND, SET и так далее. На примере выше блендинг соответствует положению ALPHA-ADD.

:: '''true''' - может быть '''false''' - включение обработки текстур, то есть true - обработка включена, false, соответственно, выключена.

:: '''blend.srcalpha''', '''blend.one''' - соответственно, методы блендинга, могут быть:

blend.one
blend.zero
null

Также вот таблица, по которой можно выбрать остальные параметры блендинга, выбирая в таблице по порядку слева направо:

<table style="border: 1px solid #666;" width="470px" height="60px">
<tr>
<td> </td>
<td bgcolor="#666" width="2px"></td>
<td>src</td>
<td bgcolor="#666" width="2px"></td>
<td>color</td>
</tr>
<tr>
<td height="2px" bgcolor="#666" colspan="5"></td>
</tr>
<tr>
<td>inv</td>
<td bgcolor="#666" width="2px"></td>
<td>dest</td>
<td bgcolor="#666" width="2px"></td>
<td>alpha</td>
</tr>
</table>

то есть:

blend.srccolor
blend.invsrccolor
blend.destcolor
blend.invdestcolor
blend.srcalpha
blend.invsrcalpha
blend.destalpha
blend.invdestalpha

: где '''inv''' - инверсия, '''color''' - цвет, '''alpha''' - альфа (коэффициент прозрачности), '''src''' - параметр берется до шейдера, '''dest''' - параметр берется после шейдера.

* ''': sorting ( 3, false )''' - порядок отрисовки поверхности по отношению к самому объекту, частью которого является поверхность.

:: '''3''' - цифра порядка отрисовки, где 1 - за объектом, 2 - на уровне с объектом, 3 - спереди объекта (ближе к актору). Как правило, при тройке шейдируемая поверхность будет отрисовываться поверх всего, в том числе и оружия.

:: '''false''' - соответствует галочке "srict sorting" в сдк. Пока назначение неизвестно.

* ''': aref ( false, 2 )''' - функция переключает режим тестирования пикселей по альфе. Первый аргумент - вкл/выкл, второй аргумент - значение альфы, используемое в сравнении альфы пикселей. Если пиксель проверку не прошел, он не будет отрисовываться. Как именно происходит проверка альфы, пока непонятно, функция проверки устанавливается где-то в движке.

* ''': zb ( false, false )''' - устанавливает функцию сравнения пикселей при z-тесте и включает режим записи в z-буфер для текстуры. Первый аргумент - функция сравнения (false - D3DCMP_LESSEQUAL - пиксель проходит тест только, если его z меньше или равно текущему пикселю, true - D3DCMP_ALWAYS - пиксель всегда проходит тест). Второй аргумент - включение записи в z-буфер, тут вкл/выкл.

* ''': fog ( false )''' - отключает освещение текстуры и включает для нее FOG DirectX.

* ''': emissive ( true )''' - применяется в источниках освещения.

* ''': distort ( true )''' - представляет из себя механизм искажений, аналогичный эффекту искажающегося воздуха в некоторых аномалиях, а также "линза" в главном меню над кнопками.

* ''': wmark (true)''' - используется в валлмарках

----

* '''shader : sampler( "s_base" )''' - создание буфера для помещения туда текстуры. Аргумент представляет собой идентификатор, получаемый ps и vs шейдерами, где будет фигурировать как predefined-переменная s_base.

''Перечисленные ниже параметры могут быть только ниже сэмплерной строки!''

* ''': texture ( t_base ) ''' - помещение в вышеобъявленный буфер текстуры. Аргумент этой ф-ции представляет собой путь к текстуре, так что вполне можно указать нечто вроде

: texture ( "fx\\fx_sun" )

чтобы в буфер воткнуть текстуру '''gamedata/textures/fx/fx_sun.dds'''

Следующие функции устанавливают один из режимов адресации текстуры. Режим адресации определяет способ обработки текстурных координат при выходе их за пределы диапазона [0.0,1.0]
* ''': clamp()''' - режим адресации D3DTADDRESS_CLAMP. Значения текстурных координат, выходящие за рамки [0.0,1.0] обрезаются до 0.0 и 1.0 соответственно. Соответствует галке Texture Clamp в сдк.

* ''': wrap ()''' - режим адресации D3DTADDRESS_WRAP. При выходе значений текстурных координат за пределы [0.0,1.0] от значений отнимается их целая часть. Другими словами, если у вас u,v получились [1.3, 2.5], в этом режиме семплирование текстуры будет происходит по координатам [0.3, 0.5].

* ''': mirror ()''' - режим адресации D3DTADDRESS_MIRROR. При выходе значений текстурных координат за пределы [0.0,1.0] от значений отнимается их целая часть и остаток вычитается из 1.0. Если u,v получились [1.3, 2.6], в этом режиме семплирование текстуры будет происходит по координатам [0.7, 0.4].

Функции установки фильтрации текстур:

* ''': f_none ()''' - точечная фильтрация (то есть по сути, нет фильтрации)

* ''': f_linear ()''' - линейная фильтрация

* ''': f_bilinear ()''' - билинейная фильтрация

* ''': f_trilinear ()''' - трилинейная фильтрация. На редкость бесполезная функция, потому что семплер по умолчанию создается с трилинейной фильтрацией

* ''': f_anisotropic ()''' - анизотропная фильтрация.

Помимо этих функций также присутствуют функции для "тонкой" настройки фильтрации:
Настройка magnification filter

* ''': fmag_none ()''' - без фильтрации

* ''': fmag_point ()''' - точечная фильтрация

* ''': fmag_linear ()''' - линейная фильтрация

Настройка minification filter

* ''': fmin_none ()''' - без фильтрации

* ''': fmin_point ()''' - точечная фильтрация

* ''': fmin_linear ()''' - линейная фильтрация

* ''': fmin_aniso ()''' - анизотропная фильтрация.

Настройка mip filter

* ''': fmip_none ()''' - без фильтрации

* ''': fmip_point ()''' - точечная фильтрация

* ''': fmip_linear ()''' - линейная фильтрация

Разные функции:

* ''': project()''' - функция выставляет флаг D3DTTFF_PROJECTED для преобразования текстурных координат перед растеризатором. При выставленном флаге все компоненты текстурных координат делятся на w-компоненту. Актуально только для ffp (R1, ps_1_x).

----

Также в папке с шейдерами лежат еще файлы .s (именно такого имени - точка и эс), которые являются для всех *.s-файлов своеобразными заголовочными файлами, функции из файла .s доступны из файлов *.s . На данный момент там имеются функции printf, и закомментированные во втором рендере ф-ции l_point и l_spot, которые отвечают за создание точечного и неточечного источников света соответственно.

'''Статья создана участником cjayho, отредактировал ошибки Sергей][akaMoonlight'''

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

G always run

2014-09-20T11:58:03Z

91.217.2.224: Отмена правки 13622, сделанной участником 95.70.2.3 (обс.)

== Описание ==

Бег без усталости.

== Входные параметры ==

g_always_run on/off

== Значение по умолчанию ==

Профиль настроек:
*Extreme - off
*Hight - off
*Default - off
*Low - off
*Minimum - off

[[Категория:Команды консоли]]

SoC. Создание ремонт комплектов

2014-01-10T10:39:22Z

91.217.2.224: /* Работа со скриптами */

===Создание ремонт комплекта===
Я опишу пример создания ремонт комплекта для костюмов, а для оружия в конце статьи сделаю пару заметок. Дело в том, что различия в создании ремонт комплектов почти нет.

1. Для начала нам нужно создать сам ремонт комплект, то есть предмет, а уже потом вешать на него функцию при использование. Для этого в config\misc\items.ltx в конец добавляем конфиг нашего предмета:

<ini>[repair_kit_outfit]:identity_immunities
GroupControlSection = spawn_group
discovery_dependency =
$spawn = "food and drugs\repair kit outfit"
$prefetch = 32
class = II_ANTIR ;класс не трогаем!
cform = skeleton
visual = equipments\item_merger.ogf ;модель
description = enc_equipment_repair_kit_outfit ;ссылка на описание в config\text\rus\....xml

inv_name = repair_kit_outfit_name ;ссылка на название в config\text\rus\....xml
inv_name_short = repair_kit_outfit_name ;тоже самое, что и inv_name
inv_weight = 6.0 ;вес

inv_grid_width = 2 ;ширина иконки
inv_grid_height = 1 ;высота иконки
inv_grid_x = 8 ;координата x иконки
inv_grid_y = 18 ;координата y иконки
cost = 10000 ;цена
;всё ниже написанное не трогаем, оно нам и не нужно
eat_health = 0
eat_satiety = 0
eat_power = 0
eat_radiation = 0
wounds_heal_perc = 0
eat_portions_num = 1
animation_slot = 4
hud = wpn_vodka_hud</ini>
2. Теперь добавим название и описание. Для этого в файле config\text\rus\string_table_enc_equipment.xml в конец между </string> и </string_table> добавляем строки по аналогии с уже написсанными:
<xml><string id="repair_kit_outfit_name">
<text>Ремонт комплект ДПК</text>
</string>
<string id="enc_equipment_repair_kit_outfit">
<text>Новинка от Вани Болта - ремонт комплект ДПК для быстрой и эффективной починки костюмов. При его создании были учтены все недочёты и, следовательно, удалены. Благодаря улучшенным инструментам и деталям, а также облегченному весу весьма ценен. С его помощью можно увеличить состояние костюма до 100%, если он повреждён не больше 30%. Незаменимая вещь во время вылазки.</text>
</string></xml>
Отлично, с предметом закончили. Теперь приступим к самому главному - скриптам.
===Работа со скриптами===
1.Вешаем функцию починки при использовании нашего ремонт комплекта.
Для этого в файле '''scripts\bind_stalker.script'''
находим функцию:

''function actor_binder:net_destroy()'' и после строки

<code>self.object:set_callback(callback.take_item_from_box, nil)</code>

пишем:

<code>self.object:set_callback(callback.use_object, nil)</code>

И теперь находим функцию

''function actor_binder:reinit()'' и после строки

<code>self.object:set_callback(callback.take_item_from_box, self.take_item_from_box, self)</code>

пишем:

<code>self.object:set_callback(callback.use_object, self.repair_outfit_start, self)</code>

Теперь в папке '''scripts''' создаёте свой скриптовый файл '''ваше_название_скрипта.script'''. Но! Название должно быть написано на английском языке и вместо пробелов должен стоять знак "_". Опять открываем '''bind_stalker.script''' и в самый конец добавляем эту функцию:
<lua>function actor_binder:repair_outfit_start(obj, who)
if obj then
if obj:section() == "repair_kit_outfit" then --здесь указываем предмет, при использование которого будет срабатывать функция ниже
ваше_название_скрипта.repair_outfit() --здесь указываем ссылку на функцию. Сначала скрипт, в котором она написана, потом название самой функции
end
end
end</lua>
2. Добавляем саму функцию ремонта.
Для этого в файле '''ваше_название_скрипта.script''' пишем:
<lua> -- Ремонт комплект для костюмов
function repair_outfit()
local item_s6 = db.actor:item_in_slot(6) --объявляем переменную (item_s6)
if item_s6 ~= nil and item_s6:condition() >=0.30 and item_s6:condition() ~=1 then --когда костюм можно чинить (состояние больше или равно 30%)
item_s6:set_condition(1)
local snd_obj = xr_sound.get_safe_sound_object([[interface\inv_detach_addon]])
snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
local news_text = "%c[255,160,160,160]Ремонт комплект:\\n%c[255,0,255,0]Ремонт костюма завершен."
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
elseif item_s6 == nil then --когда костюма нет
local news_text = "%c[255,160,160,160]Ремонт комплект:\\n%c[255,255,0,0]Ремонт невозможен: нужно одеть коcтюм."
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
alife():create("repair_kit_outfit", db.actor:position(), 1, db.actor:game_vertex_id(), db.actor:id())
elseif item_s6:condition() <0.30 then --когда костюм нельзя чинить (состояние меньше 30%)
local news_text = "%c[255,160,160,160]Ремонт комплект:\\n%c[255,255,0,0]Ремонт невозможен: костюм слишком сильно повреждён."
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
alife():create("repair_kit_outfit", db.actor:position(), 1, db.actor:game_vertex_id(), db.actor:id())
elseif item_s6:condition() ==1 then --когда костюм в отличном состояние
local news_text = "%c[255,160,160,160]Ремонт комплект:\\n%c[255,255,0,0]Ремонт невозможен: %c[255,0,255,0]костюм в отличном состояние."
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
alife():create("repair_kit_outfit", db.actor:position(), 1, db.actor:game_vertex_id(), db.actor:id())
end
end</lua>
Всё! Теперь заходим в игру и наслаждаемся.

===Небольшая заметка===
1. Чтобы сделать ремонт комплект для оружия проделываем тоже самое, только переименовываем всё вместо outfit на weapon и в функцие починки ставим слот 1 или 2 (оружейные слота) вместо 6 (слот костюмов).
Ещё нужно заменить переменную item_s6 например на item_s1 или item_s2.

2. Число 0.30 - минимальное состояние костюма, следовательно его можно менять на любое вам угодное.
Простите за такое оформление, это моя вторая статья. В будущем, если будет больше свободного времени, постораюсь расписать все моменты подробно. Автор статьи: Бага.

Данный метод создания ремонт комплектов не работает! (проверено)
ЗЫ: StalkerNew2012 этот скрипт подправил теперь всё работает :)
Ремонтный комплект без лишних сообщений просто съедается!:(

3.Ремонт оружия и брони:
{| class="collapsible collapsed"
|-
!
|
|-
|
<code lua>

-- bind_stalker.script
function actor_binder:repair_outfit_start(obj, who)
if obj then
if obj:section() == "repair_kit_outfit" then
remkomplekt.action_repair()
end
end
end

-- remkomplekt.script
function action_repair()
-- эмулируем возврат ремкомплекта в инвентарь
alife():create("repair_kit_outfit", vector(),0,0,0)

-- нет ли рядом врагов и монстров
local apos = db.actor:position()
for obj_id,_ in pairs (db.storage)do
local obj = level.object_by_id(obj_id)
if obj and (IsStalker(obj) or IsMonster(obj)) and obj:alive()
and obj:relation(db.actor) == game_object.enemy and obj:position():distance_to(apos)<30 then
send_tip("Нельзя чинить костюм, когда враги слишком близко.")
return
end
end

-- пробуем чинить предмет в
repair_item_in_slot(1) -- первом
repair_item_in_slot(2) -- втором
repair_item_in_slot(6) -- шестом слоте
end

function repair_item_in_slot(num)
local item = db.actor:item_in_slot(num)
if item then
local cond = item:condition()
if cond < 0.3 then
send_tip("%c[255,255,0,0]Ремонт невозможен: предмет в слоте "..num.. " сильно повреждён.")
elseif cond > 0.95 then
send_tip("%c[255,255,0,0]Ремонт невозможен: %c[255,0,255,0]предмет в слоте "..num.. " в отличном состоянии.")
else
item:set_condition(1)
send_tip("%c[255,0,255,0]Ремонт предмета в слоте "..num.. " завершен.")
end
else
send_tip("%c[255,255,0,0]В слоте "..num.." нет предмета для починки.")
end
end

function send_tip(news_text)
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
end
</code>
|}

4. Для многоразового использования ремкомплекта можно не доспавнивать новый предмет при съедании, а в его конфиге указать для параметра '''eat_portions_num''' большое число.
<lua>eat_portions_num = 100500</lua>
[[Категория:Скрипты]]

SoC. Создание ремонт комплектов

2014-01-10T10:35:57Z

91.217.2.224: /* Небольшая заметка */

===Создание ремонт комплекта===
Я опишу пример создания ремонт комплекта для костюмов, а для оружия в конце статьи сделаю пару заметок. Дело в том, что различия в создании ремонт комплектов почти нет.

1. Для начала нам нужно создать сам ремонт комплект, то есть предмет, а уже потом вешать на него функцию при использование. Для этого в config\misc\items.ltx в конец добавляем конфиг нашего предмета:

<ini>[repair_kit_outfit]:identity_immunities
GroupControlSection = spawn_group
discovery_dependency =
$spawn = "food and drugs\repair kit outfit"
$prefetch = 32
class = II_ANTIR ;класс не трогаем!
cform = skeleton
visual = equipments\item_merger.ogf ;модель
description = enc_equipment_repair_kit_outfit ;ссылка на описание в config\text\rus\....xml

inv_name = repair_kit_outfit_name ;ссылка на название в config\text\rus\....xml
inv_name_short = repair_kit_outfit_name ;тоже самое, что и inv_name
inv_weight = 6.0 ;вес

inv_grid_width = 2 ;ширина иконки
inv_grid_height = 1 ;высота иконки
inv_grid_x = 8 ;координата x иконки
inv_grid_y = 18 ;координата y иконки
cost = 10000 ;цена
;всё ниже написанное не трогаем, оно нам и не нужно
eat_health = 0
eat_satiety = 0
eat_power = 0
eat_radiation = 0
wounds_heal_perc = 0
eat_portions_num = 1
animation_slot = 4
hud = wpn_vodka_hud</ini>
2. Теперь добавим название и описание. Для этого в файле config\text\rus\string_table_enc_equipment.xml в конец между </string> и </string_table> добавляем строки по аналогии с уже написсанными:
<xml><string id="repair_kit_outfit_name">
<text>Ремонт комплект ДПК</text>
</string>
<string id="enc_equipment_repair_kit_outfit">
<text>Новинка от Вани Болта - ремонт комплект ДПК для быстрой и эффективной починки костюмов. При его создании были учтены все недочёты и, следовательно, удалены. Благодаря улучшенным инструментам и деталям, а также облегченному весу весьма ценен. С его помощью можно увеличить состояние костюма до 100%, если он повреждён не больше 30%. Незаменимая вещь во время вылазки.</text>
</string></xml>
Отлично, с предметом закончили. Теперь приступим к самому главному - скриптам.
===Работа со скриптами===
1.Вешаем функцию починки при использовании нашего ремонт комплекта.
Для этого в файле '''scripts\bind_stalker.script'''
находим функцию:

''function actor_binder:net_destroy()'' и после строки

<code>self.object:set_callback(callback.take_item_from_box, nil)</code>

пишем:

<code>self.object:set_callback(callback.use_object, nil)</code>

И теперь находим функцию

''function actor_binder:reinit()'' и после строки

<code>self.object:set_callback(callback.take_item_from_box, self.take_item_from_box, self)</code>

пишем:

<code>self.object:set_callback(callback.use_object, self.repair_outfit_start, self)</code>

Теперь в папке '''scripts''' создаёте свой скриптовой файл '''ваше_название_скрипта.script'''. Но! Название должно быть написано на английском языке и вместо пробелов должен стоять знак "_". Опять открываем '''bind_stalker.script''' и в самый конец добавляем эту функцию:
<lua>function actor_binder:repair_outfit_start(obj, who)
if obj then
if obj:section() == "repair_kit_outfit" then --здесь указываем предмет, при использование которого будет срабатывать функция ниже
ваше_название_скрипта.repair_outfit() --здесь указываем ссылку на функцию. Сначала скрипт, в котором она написана, потом название самой функции
end
end
end</lua>
2. Добавляем саму функцию ремонта.
Для этого в файле '''ваше_название_скрипта.script''' пишем:
<lua> -- Ремонт комплект для костюмов
function repair_outfit()
local item_s6 = db.actor:item_in_slot(6) --объявляем переменную (item_s6)
if item_s6 ~= nil and item_s6:condition() >=0.30 and item_s6:condition() ~=1 then --когда костюм можно чинить (состояние больше или равно 30%)
item_s6:set_condition(1)
local snd_obj = xr_sound.get_safe_sound_object([[interface\inv_detach_addon]])
snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
local news_text = "%c[255,160,160,160]Ремонт комплект:\\n%c[255,0,255,0]Ремонт костюма завершен."
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
elseif item_s6 == nil then --когда костюма нет
local news_text = "%c[255,160,160,160]Ремонт комплект:\\n%c[255,255,0,0]Ремонт невозможен: нужно одеть коcтюм."
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
alife():create("repair_kit_outfit", db.actor:position(), 1, db.actor:game_vertex_id(), db.actor:id())
elseif item_s6:condition() <0.30 then --когда костюм нельзя чинить (состояние меньше 30%)
local news_text = "%c[255,160,160,160]Ремонт комплект:\\n%c[255,255,0,0]Ремонт невозможен: костюм слишком сильно повреждён."
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
alife():create("repair_kit_outfit", db.actor:position(), 1, db.actor:game_vertex_id(), db.actor:id())
elseif item_s6:condition() ==1 then --когда костюм в отличном состояние
local news_text = "%c[255,160,160,160]Ремонт комплект:\\n%c[255,255,0,0]Ремонт невозможен: %c[255,0,255,0]костюм в отличном состояние."
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
alife():create("repair_kit_outfit", db.actor:position(), 1, db.actor:game_vertex_id(), db.actor:id())
end
end</lua>
Всё! Теперь заходим в игру и наслаждаемся.

===Небольшая заметка===
1. Чтобы сделать ремонт комплект для оружия проделываем тоже самое, только переименовываем всё вместо outfit на weapon и в функцие починки ставим слот 1 или 2 (оружейные слота) вместо 6 (слот костюмов).
Ещё нужно заменить переменную item_s6 например на item_s1 или item_s2.

2. Число 0.30 - минимальное состояние костюма, следовательно его можно менять на любое вам угодное.
Простите за такое оформление, это моя вторая статья. В будущем, если будет больше свободного времени, постораюсь расписать все моменты подробно. Автор статьи: Бага.

Данный метод создания ремонт комплектов не работает! (проверено)
ЗЫ: StalkerNew2012 этот скрипт подправил теперь всё работает :)
Ремонтный комплект без лишних сообщений просто съедается!:(

3.Ремонт оружия и брони:
{| class="collapsible collapsed"
|-
!
|
|-
|
<code lua>

-- bind_stalker.script
function actor_binder:repair_outfit_start(obj, who)
if obj then
if obj:section() == "repair_kit_outfit" then
remkomplekt.action_repair()
end
end
end

-- remkomplekt.script
function action_repair()
-- эмулируем возврат ремкомплекта в инвентарь
alife():create("repair_kit_outfit", vector(),0,0,0)

-- нет ли рядом врагов и монстров
local apos = db.actor:position()
for obj_id,_ in pairs (db.storage)do
local obj = level.object_by_id(obj_id)
if obj and (IsStalker(obj) or IsMonster(obj)) and obj:alive()
and obj:relation(db.actor) == game_object.enemy and obj:position():distance_to(apos)<30 then
send_tip("Нельзя чинить костюм, когда враги слишком близко.")
return
end
end

-- пробуем чинить предмет в
repair_item_in_slot(1) -- первом
repair_item_in_slot(2) -- втором
repair_item_in_slot(6) -- шестом слоте
end

function repair_item_in_slot(num)
local item = db.actor:item_in_slot(num)
if item then
local cond = item:condition()
if cond < 0.3 then
send_tip("%c[255,255,0,0]Ремонт невозможен: предмет в слоте "..num.. " сильно повреждён.")
elseif cond > 0.95 then
send_tip("%c[255,255,0,0]Ремонт невозможен: %c[255,0,255,0]предмет в слоте "..num.. " в отличном состоянии.")
else
item:set_condition(1)
send_tip("%c[255,0,255,0]Ремонт предмета в слоте "..num.. " завершен.")
end
else
send_tip("%c[255,255,0,0]В слоте "..num.." нет предмета для починки.")
end
end

function send_tip(news_text)
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal", Frect():set(83,470,83,47), 1000, 5000)
end
</code>
|}

4. Для многоразового использования ремкомплекта можно не доспавнивать новый предмет при съедании, а в его конфиге указать для параметра '''eat_portions_num''' большое число.
<lua>eat_portions_num = 100500</lua>
[[Категория:Скрипты]]

CoP. Отключение intro.

2014-01-04T23:23:10Z

91.217.2.224:

1) Откройте любым текстовым редактором файл '''game_tutorials.xml''', что в папке ''gamedata\configs\ui'', распакованных ресурсов "Зова Припяти".

2) Найдите там строку '''<intro_logo>''', и замените весь код между:
<code>
<intro_logo>
...
</intro_logo>
</code>

на этот код:

<code>
<global_wnd width="1024" height="768">
</global_wnd>
<item>
<main_wnd>
</main_wnd>
</item>
</code>

Сохраните изменения в файле. 
Теперь никаких лого при запуске игры не будет.

3) В том же файле '''game_tutorials.xml''', найдите строку '''<intro_game>''', и замените весь код между:
<code>
<intro_game>
...
</intro_game>
</code>

на этот код:

<code>
<global_wnd width="1024" height="768">
</global_wnd>
<item>
<main_wnd>
</main_wnd>
</item>
</code>

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

= Авторы =

Статью создал: [[aka_sektor]] 

= P.S. =

Параметр запуска '''-nointro''' на ЗП не работает, вот пришлось разобрался с этим раз и навсегда. 

[[Категория:Конфигурационные файлы]]

Менеджер сигналов

2013-12-25T17:13:16Z

91.217.2.224: /* Подписывание функционального объекта */

[[Category:Скрипты]]

= Система сигналов в стиле Boost.Signals или делегатов C# =

== Введение ==

Как мы все знаем, давно распространена практика "навешивания" всевозможных действий на разные вызовы биндера актора: виртуальные функции, такие как '''net_spawn''' и '''update''', а также всевозможные колбеки. Как правило, это делается вставкой строки в один из методов биндера в модуле '''bind_stalker.script''' (в котором как раз и находится класс '''actor_binder'''). Для случая метода '''update''' это может выглядеть примерно так:

<lua>function actor_binder:update(delta)
object_binder.update(self, delta)
...
my_module.update(delta)
...
end</lua>

здесь '''my_module.update(delta)''' - эта наша врезка. Вызовы из разных методов и колбеков используются для разных целей. Тот-же апдейт широко (даже слишком широко) используется для всевозможных периодических проверок. Данный подход имеет несколько недостатков.

=== Недостатки существующих подходов ===

1. Добавление очередного сервиса требует внесения изменений в модуль '''bind_stalker.script'''. Это не плохо само по себе, но постепенно приводит к замусориванию и разрастанию этого модуля, что не всем нравится. Кроме того, внесение изменений в существующий код потенциально чревато ошибками.

2. Поскольку каждый новый добавляемый сервис пишется по-разному, то возникает изрядный разнобой как в именовании вызовов, так и в передаваемых аргументах. Это опять же не плохо само по себе, но затрудняет сопровождение кода.

3. Усложнение отладки. Давно известна проблема подвисания различных вызовов биндера в случае возникновения в нем исключения движка. При таких ситуациях вызов тихо перестаёт вызываться с неопределёнными последствиями. Впрочем, неопределённость проявляется только в виде неочевидности и немгновенности эффектов. С точки зрения глобальных последствий всё достаточно определённо. Это почти всегда фатально для дальнейшего продолжения игры, приводит к порче сейвов и крайне мутным и трудноотлаживаемым глюкам.

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

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

Другой пример - изменение свойств предметов методом их пересоздания. Суть в том, что движок ограничивает возможность изменения свойств существующих объектов, и единственным путём является просто удаление объекта и создание нового с новыми свойствами. Реальная проблема возникает тогда, когда этот предмет является аргументом одного из таких вызовов и передаётся по цепочке от одного к другому. В один прекрасный момент один из вызовов в цепочке удаляет предмет с целью создать вместо него новый. Теперь следующий вызов в цепочке имеет дело с предметов в стадии удаления. Клиентский объект ещё есть, а серверного уже нет. Похожие ситуации может возникнуть и между разными вызовами, когда к примеру один вызов перемещает объект из слота в рюкзак, чтобы освободить слот, а затем удаляет объект. При помещении предмета в рюкзак срабатывает другой вызов и в нём уже серверного объекта нет с самого начала.

В общем, при дезорганизованном добавлении сервисов с этой проблемой крайне сложно бороться, что автор этих строк вполне прочувствовал на своей шкуре. К сожалению, хотя подобные приёмы и уродливые, они работают. Если не прибегать к движковым правкам, то ничего лучше в распоряжении модостроителей нет. Таким образом, если нельзя обойтись без использования этих трюков, то нужны инструменты, которые позволят как-то бороться с последствиями.

Описанная здесь система событий как раз и позволяет во многой части преодолеть перечисленные проблемы.

=== Кратко об идее события и подписки на событие ===

Об этом много написано (см. boost.signals, делегаты C#, слоты и сигналы Qt и т.п.), но не лишним будет и повториться. Попробую изложить идею на конкретном примере.

Пусть у нас есть ситуация, когда актор использует некий предмет в инвентаре. Мы имеем движковый колбек, который срабатывает при использовании предмета, расположен в модуле '''bind_stalker.script'''
<lua>function actor_binder:use_inventory_item(obj)
...
end</lua>
Как было описано в предыдущей части, в модостроении этот колбек используется для многочисленных действий. К примеру, интерфейс использования спального мешка, ремкомплекта и вообще всевозможных устройств, активируемых предметов из инвентаря, дополнительные эффекты от съедаемых предметов и медикаментов и т.п. Соответственно, вызов соответствующих обработок может выглядеть примерно так:
<lua>function actor_binder:use_inventory_item(obj)
sleep_manager.on_use(obj) -- активация спального мешка
remkit.use_object(obj) -- активация ремкита
healing.use_item(obj) -- дополнительные эффекты от препаратов
end</lua>
Недостатки этого подхода были подробно описаны ранее.

Что здесь событие? Событие - это факт использования актором предмета. Из примера видно, что событие одно, а действий, которые происходят по событию, может быть много. А может и не быть вовсе, хотя событие происходит вне зависимости от того, связаны ли с ним действия. Отсюда вытекает простая идея отделить событие от обработчиков события. Т.е. я хотел бы иметь в коде что-то вроде такого:
<lua>function actor_binder:use_inventory_item(obj)
генерировать_событие_использования_предмета(obj)
end</lua>
что приводило бы к срабатыванию функций '''sleep_manager.on_use(obj)''', '''remkit.use_object(obj)''' и '''healing.use_item(obj)'''. Естественно, что это потребует неких усилий: нужен некий промежуточный код, который будет хранить список функций, связанных с событием, который будет при активации события вызывать эти функции одна за другой, передавая в них один и тот-же аргумент; нужен сервисный код, который позволит регистрировать функции-обработчики и связывать их с конкретным событием, а также отвязывать. В частности, используя этот сервисный код, надо предварительно выполнить действия такого рода:
<lua>связать_функцию_с_событием_использования_предмета(sleep_manager.on_use)
связать_функцию_с_событием_использования_предмета(remkit.use_object)
связать_функцию_с_событием_использования_предмета(healing.use_item)</lua>
чтобы система событий знала, что надо вызвать эти три функции.

Немного о терминологии. В разных системах и языках для разных частей этого процесса используются разные названия. Событие (event) может также называться сигналом (signal). Функции-обработчики могут также называться слотами (slot), подписчиками (subscriber), делегатами (delegate), колбеками (callback). Соответственно процесс связывания сигнала и обработчика тоже может называться по-разному: (un)subscribe, (dis)connect, add/remove и прочие слова, которые так или иначе могут означать "связать", "добавить", "подписать", "назначить" и т.п. В предлагаемой системе я использую термины "сигнал", "слот", "подписать/отписать". На самом деле рекомендую не делать из этого священную корову, главное понимать смысл.

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

=== Преимущества системы сигналов перед простым подходом ===

# Добавление очередного подписчика не приводит к изменению того модуля, откуда генерируется сигнал. Разумеется, один раз надо вставить код генерации сигнала, но после этого этот код уже меняться не будет, вне зависимости от количества модулей, использующих этот сигнал. Таким образом, можно добавлять новые куски в мод с минимальным изменением существующего кода, и вообще разные части мода будут более изолированы друг от друга. Это особенно важно для громоздких глобальных модов, состоящих из кучи разных компонентов.
# Как следствие единой системы вызовов для конкретного сигнала принимается соглашение о списках аргументов. Все подписчики на этот сигнал должны следовать этому соглашению. Это на самом деле сильно повышает надёжность системы в целом, поскольку снижает вероятность ошибок при разработке.
# Наличие централизованный системы вызовов даёт возможность использовать разные сервисы, которые в противном случае требовали бы индивидуальной и громоздкой реализации для каждого вызова.
#* Внедрена централизованная система отладки, которая автоматически определяет подвисший вызов. Теперь никакой подвисший колбек не останется незамеченным, если его обработка организована через менеджер сигналов. При этом никаких дополнительных усилий это не требует, не нужны обрамляющие отладочные вызовы, счётчики и т.п., поскольку это внедрено в код менеджера сигналов.
#* Частично сглаживается проблема драки за один объект между вызовами. Это особенно важно для обработчиков инвентарных предметов, а также событий нажатий клавиатуры. Общая проблема заключается в том, что событие одно, а адресовано оно как правило только одному из обработчиков. Т.е. использование предмета "спальный мешок" адресовано только обработчику менеджера сна. При этом, зачастую объект удаляется его обработчиком, что приводит к тому, что последующие обработчики имеют дело с объектом в стадии удаления (клиентский объект ещё есть, а серверного уже нет), что запросто может приводить к багам или дополнительному громоздкому коду, который должен эту ситуацию проверять. При использовании же системы сигналов у обработчиков есть возможность завершить цепочку вызовов на себе, и предотвратить вызов оставшихся в цепочке обработчиков. Для этого обработчик должен вернуть '''true''' (не вернуть ничего или вернуть '''false''' будет означать разрешение продолжить обработку). Кроме того, для некоторых вызовов сам менеджер производит проверку существования объекта, и если он уже удалён, то дальнейшие вызовы не будет сделаны вообще. Для обработчиков нажатий клавиатуры этот подход позволяет снизить нагрузку на процессор.
#* Есть возможность распределения нагрузки в виде низкоприоритетных (или очерёдных колбеков). В основном это имеет смысл только для использования вместе с сигналом update, тем не менее весьма полезно. Без такой фишки приходится делать это вручную со счётчиком, километровым кодом с if-ами и т.п.
# Обработчики можно не только подписывать на сигналы, но и отписывать. Это позволяет делать разнообразные динамические компоненты, которые "цепляются" к нужному сигналу и отсоединяются по мере необходимости. Это упрощает разработку, поскольку позволяет избежать громоздкого кода, который при отсутствии такой возможности проверял бы необходимость вызова, и, как следствие, повышает надёжность системы. Это активно используется, к примеру, в системе таймеров.
# На события можно подписывать не только обычные функции, но и методы классов. Это фишка конкретно этой реализации, но на мой взгляд полезная. Используется при реализации тех-же таймеров.
# В принципе возможны трюки с эмуляцией сигнала. Т.е. к примеру сигнал update биндера актора нормально вызывается из биндера актора, но никто не мешает принудительно вызывать его откуда-то ещё, что вызовет срабатывание всех подписанных на этот сигнал обработчиков. Я бы не рекомендовал использовать это без лишней нужды, но тем не менее возможность такая есть.
# Автоподключение модулей. Идея простая: пишется модуль с функциями-обработчиками каких-то событий, имя модуля должно следовать неким правилам для его распознавания менеджером, и также модуль должен содержать специальную переменную-метку и функцию, которая автоматически будет выполнена. В этой функции выполняется подписка на события функций из этого модуля. Используя эту технику можно написать модуль с колбеками, не изменив вообще ни строки ни в одном другом модуле. Всё, что надо сделать для его использования, просто поместить файл в папку scripts. Например, можно написать модуль, который выводит на худ информацию об объекте под прицелом по нажатию сочетания клавиш (нужны естественно колбеки на клавиши), или удаляет объект под прицелом, или меняет его свойства, или телепортирует актора на три метра вперёд, или открывает окно тестового спавна и т.п. Не нужен модуль, просто убрал его из папки со скриптами. Это всё очень удобно для отладочных модулей. Для использования в штатных компонентах не рекомендуется, поскольку по ряду причин для автоподписываемых модулей ослаблены проверки корректности.

== Использование менеджера ==

=== Общие сведения ===

Код менеджера сигналов находится в двух модулях:

'''ogse_signals.script''' - собственно менеджер сигналов

'''ogse_signals_addons_list.script''' - список подписываемых модулей

Глобальный объект менеджера сигналов существует в единственном экземпляре. Поучить его можно функцией '''ogse_signals.get_mgr()'''. Объект менеджера используется для всех дальнейших операций: подписки/отписки функций и вызова сигналов.

Для подписки используется метод менеджера '''subscribe(slot_descriptor)''', для отписки - метод '''unsubscribe(slot_descriptor)''', для генерации сигнала - метод '''call("signal_name", <список аргументов>)'''
'''slot_descriptor''' - это таблица, имеющая вид:
<lua>slot_descriptor = {signal = "signal_name", fun = function_or_class_member, self = object_reference_or_nil, queued = true}</lua>
Если необходимо отписать функцию от события, то надо сохранить этот дескриптор и позднее использовать его в функции '''unsubscribe'''. Для иллюстрации всего этого далее приводятся несколько конкретных примеров использования.

=== Подписка глобальной функции ===
Допустим, имеется модуль '''some_module.script''', а в нём функция
<lua>function some_function(arg1, arg2)
end</lua>

Тогда я могу выполнить подписку этой функции на сигнал "'''some_signal'''" таким образом:
<lua>local slot_desc = {signal = "some_signal", fun = some_module.some_function} -- дескриптор слота
ogse_signals.get_mgr():subscribe(slot_desc) -- подписали слот</lua>

С этого момента при генерации сигнала "'''some_signal'''" будет вызываться функция '''some_module.some_function'''. Генерация сигнала (а по-простому вызов) осуществляется так:
<lua>ogse_signals.get_mgr():call("some_signal", arg1, arg2) -- вызов сигнала. В каждый обработчик будут переданы аргументы arg1, arg2</lua>

Для отписки этой функции делаем так (при условии, что мы сохранили дескриптор слота '''slot_desc'''):
<lua>ogse_signals.get_mgr():unsubscribe(slot_desc) -- отписали функцию</lua>

Замечание: модули, в котором находится функция '''some_module.some_function''', из которого осуществляется подписка и отписка функции и откуда вызывается сигнал, могут быть совершенно разными. Хотя чаще всего получается так, что первые три - это один модуль, а откуда вызывается сигнал - другой.

=== Подписка глобальной функции в низкоприоритетную очередь ===

Здесь рассмотрим пример подписки функции на очерЁдное выполнение или оно же выполнение с низким приоритетом. Смысл очерёдности в том, что за каждый вызов сигнала выполняются не все подписанные функции, а только одна, в следующий раз следующая за ней в очереди и т.д. по кругу. В основном это имеет смысл только для события "'''update'''", которое вызывается из функции апдейта биндера актора. Используя эту возможность, можно распределить нагрузку между последовательными апдейтами за счёт снижения частоты вызовов каждого конкретного подписчика. Обращаю внимание, что при этом частота вызовов будет зависеть от количества подписчиков - чем их больше, тем реже они вызываются. Естественно, не для любых операций это годится, а только для тех, где важен факт срабатывания по принципу "пусть сработает хоть когда-нибудь". Если важна скорость реакции, то всегда остаётся возможность подписать на то же событие апдейта с высоким приоритетом. Технически эта фишка работает с использованием второй очереди.

В примере ниже подразумевается, что подписываемая функция и код подписывания/отписывания находятся в одном модуле. Таким образом, я могу избежать указания имени модуля. Более того, я могу использовать системную ссылку this, которая означает "этот модуль", чтобы избежать потенциальных конфликтов имён (вдруг среди глобальных имён встречается '''on_update''').
<lua>function on_update() -- функция-обработчик события низкоприоритетного обновления
end

ogse_signals.get_mgr():subscribe({signal = "on_update", fun = this.on_update, queued = true}) -- подписали
</lua>
В качестве дополнительного замечания. В этом примере мы не хотим отписываться от сигнала. Это вполне нормальная ситуация в особенности для глобальных функций типа обработчиков периодического апдейта. В этом случае нет необходимости сохранять дескриптор слота и синтаксис в целом упрощается.

=== Подписка метода класса ===

Имеется возможность подписать на событие метод класса. Напоминаю, что при вызове метода класса в него передаётся скрытый аргумент self, соответственно, при регистрации обработчика надо в дескрипторе указать дополнительный параметр со ссылкой на объект класса. Пример ниже показывает идею, на которой основана работы системы таймеров:
<lua>class "simple_timer"
function simple_timer:__init() -- конструктор класса
self.slot_desc = {signal = "on_update", self = self, fun = self.on_update}
self.sm = ogse_signals.get_mgr()
sm:subscribe(self.slot_desc)
end
function simple_timer:on_update() -- функция периодической проверки некоего условия
if <выполнилось некое условие> then
self:on_finish()
end
end
function simple_timer:on_finish() -- отписка и завершение выполнения
sm:unsubscribe(self.slot_desc)
end</lua>

В данном примере объект класса при своём создании сам регистрирует один из своих методов на событие периодического апдейта. Далее, в этой функции проверяется некое условие. Когда это условие выполняется, то вызывается функция завершения работы, которая, кроме выполнения разной полезной нагрузки, также разрегистрирует класс в менеджере сигналов. Таким образом, для начала работы этого простого таймера достаточно просто его создать.
<lua>simple_timer()</lua>
и он автоматически начнёт работу. Более того, нет даже необходимости нигде хранить ссылку на этот объект, поскольку она хранится в менеджере сигналов (в поле '''self'''). При отписывании же, после окончании работы таймера, эта ссылка удаляется и вместе с ней сборщиком мусора удаляется и объект таймера.

Разумеется, это только упрощённый пример и лишь один из вариантов использования этой возможности.

=== Подписывание функционального объекта ===

Достаточно экзотическая возможность. Вряд ли потребуется, особенно при наличии возможности подписать метод класса.

Если с помощью метатаблицы задать классу оператор "'''call'''", то такой класс, с одной стороны, можно подписать как глобальную функцию, а с другой - он может хранить состояние, в отличие от простой функции.

<lua>class "some_luabind_class"
function some_luabind_class:__init()
local mt = getmetatable(self)
mt.__call = self.method_to_call
end
function some_luabind_class:method_to_call()
end

local slot_desc = {signal = "signal_name", fun = some_luabind_class()}
ogse_signals.get_mgr():subscribe(slot_desc) -- подписали в высокоприоритетную очередь
--...
ogse_signals.get_mgr():unsubscribe(slot_desc) -- отписали</lua>

Функциональный класс на таблице строится немного сложнее:
<lua>local t = {}
function t:method_to_call()
end
local mt = {}
mt.__call = t.method_to_call
setmetatable(t, mt)
</lua>
и далее всё как в предыдущем фрагменте.

=== Подписка модуля ===

Часто встречается ситуация, когда имеется некий файл скрипта, который содержит в себе набор обработчиков разных событий. Многие геймплейные минимоды представляют собой такие модули. Их интеграция обычно включает явное прописывание вызовов этих обработчиков из разных колбеков игры. Специально для облегчения этого процесса в менеджере сигналов имеется возможность подписывать модуль целиком. Для подписывания модуля надо сделать следующее:
1. Вписать имя модуля без расширения в таблицу '''addons''' в файле '''ogse_signals_addons_list.script'''. Допустим, у меня есть модуль '''my_module.script''', тогда я напишу так:<lua>addons = {
"my_module",
}</lua>Примечание: запятая после последнего элемента массива допускается синтаксисом '''Lua'''.

2. В самом модуле '''my_module.script''' должна иметься глобальная функция '''attach(sm)''' с единственным аргументом. Эта функция будет вызвана автоматически при старте игры, а аргумент - это ссылка на менеджер сигналов. Функция может выглядеть примерно так:
<lua>function attach(sm)
sm:subscribe({signal = "on_spawn", fun = this.on_spawn})
sm:subscribe({signal = "on_use", fun = this.on_item_use})
sm:subscribe({signal = "on_update",fun = this.on_update, queued = true})
sm:subscribe({signal = "on_save", fun = this.on_save})
end</lua>
т.е. её задача - явно подписать на нужные сигналы обработчики из этого модуля.

Этот подход позволяет выполнить интеграцию скриптовой части минимода с минимальным остальных скриптов. По сути, извне модуля меняется только таблица в файле '''ogse_signals_addons_list.script''' - туда добавляется одна строка. Разумеется, соответствующие сигналы уже должны быть заведены в разных колбеках мода, но для большинства стандартных сигналов (типа колбеков биндера актора update, spawn, use_item и т.п.) это обычно уже сделано. Также, соглашения о вызовах обработчиков из подключаемого модуля должны следовать соглашениям о вызовах соответствующих сигналов.

=== Авторегистрация модуля ===

Имеется возможность подключать модуль без вписывания его в файл '''ogse_signals_addons_list.script'''. Для этого он должен отвечать двум дополнительным требованиям:
# Имя модуля должно начинаться с "ogse_"
# Модуль должен содержать глобальную переменную '''auto_attach''', установленную в '''true'''.

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

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

В качестве лирического отступления. Данная фишка на заре создания этой системы была основным функционалом, ради которого я эту систему и делал. Мне нужна была возможность создавать отладочные модули, которые можно было подключать/отключать просто перенося файл скрипта в папку '''scripts'''. При наличии движковых колбеков на нажатия клавиш получается очень удобная система. К примеру, есть наработки по отладочным модулям, которые позволяют снимать информацию о разных объектах вблизи актора и выводить её в лог или на экран по нажатию нужных сочетаний. С другой стороны я не включаю эти модули в релиз для тестеров, и это не требует изменения ни одной строки кода.

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

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

Как заспавнить физический объект

2013-08-11T15:11:08Z

91.217.2.224: оформление

В этой статье вы узнаете как создать спавнящийся физический объект.
 Выбираем нужную модель из папки '''gamedata\meshes'''.
 Создаем в файле '''configs\misc\items.ltx''' (или своем конфиге) новую секцию, которая будет выглядеть так:
<ini>
[vedro]:identity_immunities ;vedro — название спавн-секции предмета (Потом мы будем через него спавнить). Пишется латиницей.
$spawn = "dynamic_objects\el_tehnika\komp_klava" ;путь спавн-секции в дереве спавн-объектов в СДК (если не пользуетесь СДК, то особой важности не имеет).
visual = objects\dynamics\decor\vedro_01.ogf ;Путь до модели физического объекта из папки meshes.
cform = skeleton ; Движковые классы (не изменяем)
class = P_SKELET
remove_time = 4 ;Время через которое объект исчезнет. Число до от 0 до 9999, если поставить 9999 то он просуществует очень долго</ini>

Второй вариант:
<ini>[vedro]:identity_immunities ;vedro — название спавн-секции предмета (Потом мы будем через него спавнить). Пишется латиницей.
$spawn = "physics\object" ;путь спавн-секции в дереве спавн-объектов в СДК (если не пользуетесь СДК, то особой важности не имеет).
visual = objects\dynamics\decor\vedro_01.ogf ;Путь до модели физического объекта из папки meshes.
class = O_PHYS_S
remove_time = 60000 ;Время через которое объект исчезнет. Число до от 0 до 9999, если поставить 9999 то он просуществует очень долго.
</ini>
 Сохраняем файл.

Далее уже стандартно — создаем в скриптовом файле функцию типа
<lua>function spawn ()
alife():create("vedro",vector():set(координаты X,Y,Z),level_vertex_id,game_vertex_id)
end</lua>
И вызываем эту функцию через диалог или другой скрипт.
 
Автор — [[Участник:KitkaT.Net|KitkaT.Net]] 12:45, 27 сентября 2010 (UTC) 
Редактирование — [[Участник:Pihan13|Pihan13]] 16:04, 27 сентября 2010 (UTC)

[[Категория:Конфигурационные файлы]][[Категория:Скрипты]]

SoC. Создание новых веток диалогов

2013-08-03T16:24:56Z

91.217.2.224: /* Дополение от XiaNi */

==<center>Создание новых веток диалогов.</center>==
===Теория:===

(Если где то чего то напутал исправляйте, многое писал интуитивно)

'''1)''' Списки веток диалогов содержатся в файлах вида '''gamedata/config/gameplay/character_desc_*.xml'''

Это например:
 '''character_desc_zombied.xml'''
 '''character_desc_stalker.xml'''
 '''character_desc_garbage.xml'''
и т. д.

Файлы '''character_desc_*.xml''' можно сравнить со стволом дерева диалогов.
В них перечисляется названия прикрепляемых к НПС веток диалогов.

Например, вот список веток диалогов с Сидоровичем, взятый из файла '''character_desc_escape.xml'''

<pre> <start_dialog>escape_trader_start_dialog</start_dialog>
<actor_dialog>escape_trader_talk_info</actor_dialog>
<actor_dialog>escape_trader_jobs</actor_dialog>
<actor_dialog>tm_trader_dialog</actor_dialog>
<actor_dialog>tm_trader_reward</actor_dialog>
<actor_dialog>escape_trader_done_blockpost_box</actor_dialog></pre>

В свою очередь, каждая ветка диалога также может ветвится.

'''2)''' Ветвление веток прописывается уже в других файлах.
Например, ветвление веток диалога с Сидоровичем содержится в файле '''gamedata/config/gameplay/dialogs_escape.xml'''
Возьмем оттуда, к примеру, ветвление ветки ''escape_trader_jobs''

(ветвление веток обычно очень большое, поэтому я приведу только часть):

<xml><dialog id="escape_trader_talk_info">
<precondition>escape_dialog.trader_has_talk_info_wr</precondition>
<has_info>tutorial_end</has_info>
<phrase_list>
<phrase id="1">
<text>escape_trader_talk_info_1</text>
<next>100</next>
<next>99</next>
<next>9995</next>
</phrase>

…
…
…
<phrase id="0">
<text>escape_trader_talk_info_0</text>
<next>1</next>
</phrase>
</phrase_list>
</dialog></xml>

Здесь ''<precondition>…</precondition>'' - это скриптовая проверка выполнения условия. Ветка появится в диалоге, только если условие выполняется.
Конкретно ''<precondition>escape_dialog.trader_has_talk_info_wr</precondition>'' из ветки ''escape_trader_talk_info'' есть обращение к функции ''trader_has_talk_info_wr'', находящейся в файле-скрипте '''gamedata/scripts/escape_dialog.script'''.

Функция выглядит так:

<lua>function trader_has_talk_info_wr( trader, actor )
return true
end</lua>

''<precondition>escape_dialog.trader_has_talk_info_wr</precondition>'' в принципе выполняется всегда, т. к. функция всегда возвращает истbну и ''<dialog id="escape_trader_talk_info">'' пропускается в списке реплик.
Но для конкретной ветки может быть несколько ''precondition'' и других условий.

Далее.
 ''<has_info>tutorial_end</has_info>'' - это также своего рода проверка условия. В данном случае проверка на то, закончена стадия ''tutorial'а'' или нет. Т. е. ветка будет допущена в список реплик, если стадия ''tutorial'а'' закончена.
более детально об этом в конце данной статьи. При окончании ''tutorial'а'' выдается инфопорция ''tutorial_end'', которая и является стержнем данной проверки.

А далее идут конкретные фразы содержащие ссылки на вытекающие фразы

Фраза:
<xml><phrase id="0">
<text>escape_trader_talk_info_0</text>
<next>1</next>
</phrase></xml>

это основа ветки ''escape_trader_talk_inf''o.
Вообще, в любой основной ветке любого диалога фраза ''<phrase id="0">'' будет основой, из которой далее будет все вытекать.

''<next>1</next>'' - это ссылка на вытекающую фразу ''<phrase id="1">'':

<xml> <phrase id="1">
<text>escape_trader_talk_info_1</text>
<next>100</next>
<next>99</next>
<next>9995</next>
</phrase></xml>

В свою очередь ''<next>100</next>'', ''<next>99</next>'', ''<next>9995</next>'' - это ссылки на фразы веточки растущие из фразы ''<phrase id="1">''.

'''3)''' Текст каждой фразы содержится уже в четвертом файле. Для диалога с Сидоровичем тексты лежат в файле '''gamedata/config/text/rus/stable_dialogs_escape.xml'''

<xml> <string id="escape_trader_talk_info_0">
<text>Есть несколько вопросов.</text>
</string>
<string id="escape_trader_talk_info_1">
<text>Спрашивай, только я ведь всего не знаю. Сам понимаешь, сижу тут целыми днями, а жизнь - она вся там, снаружи, в Зоне. Могу рассказать о Зоне вообще, а немного могу о ближайших окрестностях, где сам ходил.</text>
</string></xml>

Эти строки содержат тексты для фраз ''<phrase id="0">'' и ''<phrase id="1">''

Итого диалоги разложены по 4 а то и более файлам.

Да кстати, путь по веткам может быть зацикленным если того требует диалог. Например так:

<xml><phrase id="0">
<text>…</text>
<next>1</next>
<next>2</next>
</phrase>
<phrase id="1">
<text>…</text>
<next>11</next>
<next>12</next>
</phrase>
<phrase id="11">
<text>…</text>
<next>1</next> - Это возврат к фразе 1. (зацикливание)
<next>111</next>
</phrase></xml>

===Практика:===
Добавим в диалог с Сидоровичем ветку своего собственного изготовления.Например такую:

<pre>
Меченый: Сидрыч а почему это у тебя зеленые человечки, что по столу бегают, такие худые?
Сидорович: Чего?!!
Меченый: Ты их совсем, совсем не кормишь?
Сидорович: В следующий раз, как пойдешь в зону, бери-ка вместо водяры побольше антирада. А то мало что таким перегаром дышишь, уже до зеленых человечков долечился… Шутник.</pre>

Для этого:

'''1)''' В файле gamedata/config/gameplay/character_desc_escape.xml в конце списка веток для trader_а суем свою ветку с произвольным названием. (например <actor_dialog>escape_trader_letat_gusi</actor_dialog>)

Т.е у нас получится так
<xml> …
<specific_character id="escape_trader" no_random = "1">
…
…
…
<start_dialog>escape_trader_start_dialog</start_dialog>
<actor_dialog>escape_trader_talk_info</actor_dialog>
<actor_dialog>escape_trader_jobs</actor_dialog>
<actor_dialog>tm_trader_dialog</actor_dialog>
<actor_dialog>tm_trader_reward</actor_dialog>
<actor_dialog>escape_trader_done_blockpost_box</actor_dialog>
<actor_dialog>escape_trader_letat_gusi</actor_dialog>
</specific_character>
…</xml>
Записываем изменения, и с файлом '''character_desc_escape.xml''' уже все.

'''2)''' Теперь берем файл '''gamedata/config/gameplay/dialogs_escape.xml'''

Диалогу:

<pre>Меченый: Сидрыч а почему это у тебя зеленые человечки, что по столу бегают, такие худые?
Сидорович: Чего?!!
Меченый: Ты их совсем, совсем не кормишь?
Сидорович: В следующий раз, как пойдешь в зону, бери-ка вместо водяры побольше антирада. А то мало что таким перегаром дышишь, уже до зеленых человечков долечился… Шутник.</pre>

который мы хотим реализовать, будет соответствовать такая структура:

<xml><phrase id="0">
<text>escape_trader_letat_gusi_0</text>
<next>1</next>
</phrase>
<phrase id="1">
<text>escape_trader_letat_gusi_1</text>
<next>2</next>
</phrase>
<phrase id="2">
<text> escape_trader_letat_gusi_2</text>
<next>3</next>
</phrase>
<phrase id="3">
<text> escape_trader_letat_gusi_3</text>
</phrase></xml>

Условия наличия ветки в диалоге можно взять из ветки ''<dialog id="escape_trader_talk_info">''
Т. е. берем условия
<code><precondition>escape_dialog.trader_has_talk_info_wr</precondition></code>
и
<code><has_info>tutorial_end</has_info></code>
(Можно было конечно прописать в скрипте еще одно условие для ветки, чтоб она появилась только один раз,
а потом больше не возникала. Но об этом как-нибудь позже допишу.)

В итоге у нас получилась такая структура:

<xml><dialog id="escape_trader_letat_gusi">
<precondition>escape_dialog.trader_has_talk_info_wr</precondition>
<has_info>tutorial_end</has_info>
<phrase_list>
<phrase id="0">
<text>escape_trader_letat_gusi_0</text>
<next>1</next>
</phrase>
<phrase id="1">
<text>escape_trader_letat_gusi_1</text>
<next>2</next>
</phrase>
<phrase id="2">
<text> escape_trader_letat_gusi_2</text>
<next>3</next>
</phrase>
<phrase id="3">
<text> escape_trader_letat_gusi_3</text>
</phrase>
</phrase_list>
</dialog></xml>

Ее нужно вставить в любом месте между dialog id_шниками других веток в файле '''dialogs_escape.xml'''.

Главное не промахнутся и засунуть именно между, а не внутрь одного из dialog id

Все что находится между тегами <dialog id="***"> и </dialog> это внутенности конкретного dialog id

Т.е совать наш
<pre><dialog id="escape_trader_letat_gusi">
…
</dialog></pre>

надо

<pre><dialog id="*** ">
…
</dialog>
здесь
<dialog id="*** ">
…
</dialog></pre>

но

<pre><dialog id="*** ">
не здесь
</dialog></pre>

После сохранения внесенных изменений с файлом '''dialogs_escape.xml''' все.

'''3)''' Теперь вбиваем сами текстовички в файле '''gamedata/config/text/rus/stable_dialogs_escape.xml'''

Т.е нам надо в файле '''stable_dialogs_escape.xml''' вставить такую конструкцию:

<xml> <string id="escape_trader_letat_gusi_0">
<text>Сидрыч а почему это у тебя зеленые человечки, что по столу бегают, такие худые?</text>
</string>
<string id="escape_trader_letat_gusi_1">
<text>Чего?!!</text>
</string>
<string id="escape_trader_letat_gusi_2">
<text>Ты их совсем, совсем не кормишь?</text>
</string>
<string id="escape_trader_letat_gusi_3">
<text>В следующий раз, как пойдешь в зону, бери-ка вместо водяры побольше антирада. А то мало что таким перегаром дышишь, уже до зеленых человечков долечился… Шутник.</text>
</string></xml>

в любом месте между уже существующими string id
<pre>
<string id="*** ">
</string>
сюда
<string id="*** ">
</string></pre>

Но не внутрь одного из существующих string id
<pre>
<string id="*** ">
не сюда
</string>
</pre>
После сохранения изменений, у нас все готово. Можно грузить игру и смотреть что получилось.

===Практический пример не работает со вторым патчем - решение проблемы===

По крайней мере со вторым патчем несовместимо условие

<pre><precondition>escape_dialog.trader_has_talk_info_wr</precondition></pre>

Использование этого условия приведет к вылету

так как со вторым патчем из файла '''escape_dialog.script''' была удалена функция:

<lua>function trader_has_talk_info_wr( trader, actor )
return true
end</lua>

можно либо воткнуть эту функцию обратно в '''escape_dialog.scrip'''t

либо использовать другие более мение подходящие условия, например:

<pre><precondition>escape_dialog.trader_alredy_give_job</precondition></pre>

====Дополение от XiaNi====
По поводу <precondition> в данном примере.. он тут реально вообще не нужен тем более что возвращает всегда одно и то же... тут уж или реально надо использовать функцию которая хоть чтото проверяет нужное для диалога... а так... диалог и так будет активным если убрать <precondition> (в данном случае это 100%)

''<has_info>'' и ''<dont_has_info>'' это условия на присутствие и соответственно отсутствие у игрока "информации" которая, на самом деле, всего лишь флажок, что пользователь слышал о чем-то или видел что-то который выдается:
1. условиями "логики" прописанной объектам или неписям.
2. скриптами
3. диалогами через например "<give_info>tutorial_end</give_info>"

В принципе ''<has_info>'' соответствует скриптовому аналогу функции ''has_alife_info''
так например ''<has_info>tutorial_end</has_info>'' можно заменить на ''<precondition>escape_dialog.check_tutor_end</precondition>'' и дописать в '''escape_dialog.script''' строчки :
<lua>
function check_tutor_end(actor, npc)
if has_alife_info("tutorial_end")
then
return true
else
return false
end
end
</lua>
в которой мы проверяем есть ли информация ''tutorial_end'' у игрока.

==Авторы==

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

* [[Участник:BAC9-FLCL|BAC9-FLCL]]
* [[Участник:Keha|Keha]]
* [[Участник:XiaNi|XiaNi]]
[[Категория:Конфигурационные_файлы]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2013-06-13T11:49:00Z

91.217.2.224: /* Необходимые для стабилизации игры правки в модулях */

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

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

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

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

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

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

<code>smart_terrain:1143 "attempt to index a nil value"</code>

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

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

Это кусок родного кода из версии 1,0005 игры. Я долго пытался разными способами отсечь этот вылет, вводя предварительные проверки, однако это совершенно ничего не давало - вылет всё равно периодически случался, так как проверки эти сами его вызывали. Тогда я зарылся в документацию по Lua и обнаружил замечательную родную базовую функцию, введённую ещё с первых версий Lua, которой почему-то не пользовались ни разработчики игры, ни моддеры (хотя сама она в Lua сталкера присутствует, и работает отлично, без каких-либо нареканий). Вот она:

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызванной функции, не передаётся наружу - вызывавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

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

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применяем полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно игнорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинале игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тексту. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая функция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда функции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой функции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту функцию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после проверки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

Примечание другого автора: в Зове Припяти большая часть вылетов всё также не вылетает. Вы можете себя неприятно удивить, если раскомментируете в файле _g.script строку
<code lua>-- error_log(reason)</code>

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

По поводу частичной неработоспособности ф-ции '''abort''' я беседовал с Колмогором, и он пришёл к выводу, что видимо вылет игры должен был бы производиться при обработке функции '''printf("%s")''' - ей тут передаётся заведомо отсутствующий оператор и она по уму должна бы сразу крашить игру. Однако в релизе функция printf фактически не работает(она реализована в _g.script через вырезанную функцию log). В результате игра не крашится. Но что поделать, в итоге мне пришлось модифицировать его таким образом, чтобы вылет при его срабатывании был гарантирован:

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
local crash
local ooops = 1/crash
end</code>

Вылет происходит при попытке произвести арифметическую операцию с неинициализированной переменной crash.

----

Дополнение от cjayho (ecb team): Вообще крэшить игру ошибкой в скриптовом коде - далеко не самое очевидное решение. В windows-подобных системах статус, возвращаемый программой после ее выполнения, не имеет ни малейшего смысла, поэтому корректно ли мы выключим игру или некорректно - разницы не будет никакой. Поэтому есть смысл сделать крэш игры более очевидным и стопроцентно работающим способом: использовать консольную команду quit:

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
get_console():execute( 'quit' )
end</code>

А для тех кто задается вопросом: почему разработчики не сделали так изначально? отвечу: вероятнее всего ошибка в скрипте была не очень очевидным заклинанием по призыву волшебного зеленого жука, которое после выпуска не-дебаг версии потеряло свой изначальный сакральный смысл.

----

== Лечение зависаний алайфа при смерти персонажей ==

Недавно, отлаживая проблемы с зависанием алайфа, мне удалось найти причину этого периодически во всех модах всплывающего сбоя, приводящего к порче сейвов и сильно мешающего нормально играть. Сбой этот возникает при смерти некоторых NPC, обычно квестовых. В частности в моём случае изолировать и отладить это зависание удалось на Юрике, новичке со Свалке, учавствующем в сцене с гоп-стопом. Причина оказалась в обработке посмертной отрегистрации NPC из гулагов, причём сбой там был настоящей матрёшкой, составной из нескольких частей. Правок в итоге было совсем немного, но чтобы сделать их мне пришлось несколько часов распутывать клубок из кросс-вызовов между скриптами smart_terrain и xr_gulag. Итак, начнём с самого начала. Работая над OGSE 069 и 0691 я периодически сталкивался с зависаниями и вылетами в посмертных обработках неписей. Один из таких вылетов - всем хорошо знакомый вылет:

<code>smart_terrain:1143 "attempt to index a nil value"</code>

Происходящий в функции '''smart_terrain.on_death( obj_id )''' - я тогда его заблокировал вызовом его внутри безопасного кода функцией '''pcall''', однако, как теперь выяснилось, этого оказалось недостаточно - баг тут состоит из нескольких частей, и этот вылет указывает только на одну из них. Вот исходный код:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- первый вылет/зависнаие алайфа происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id) -- а вот в этой обработке происходит зависание алайфа. Она очень комплексная, и её сложно распутывать.
end
end
end</code>

Во-первых выяснилось, что изредка вызов '''obj:smart_terrain_id()''' вызывает зависание алайфа даже когда он производится изнутри защищённого кода. Тогда я решил избавиться от использования этой функции в данном месте совсем. После нескольких экспериментов выяснилось, что самым простым, быстрым и вылетобезопасным способом будет считать нетпакет существа в таблицу и выудить идентификатор смарттеррейна из неё. Для этого можно написать свою обработку, однако я, как весьма ленивый программист, не склонен изобретать велосипеды, поэтому я воспользовался уже проверенной у нас и активно используемой в OGSE библиотекой функций для работы с нетпакетами '''m_net_utils''' Артоса. Кроме того, я сразу сделал более безопасным вызов обработки на отрегистрацию в гулагах. Вот, собственно, что в итоге получилось:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if (obj and obj.smart_terrain_id) then
local strn_id = 65535 -- значение по умолчанию

local t = nil -- сюда запихнём табличку из пакета
if IsStalker(obj) then t = m_net_utils.get_stalker_data(obj) elseif IsMonster(obj) then t = m_net_utils.get_monster_data(obj) end
-- вызываем парсинг пакета для неписей и монстров отдельно

-- print_table_inlog(t)
if t.smtrid then
strn_id = tonumber(t.smtrid) -- получаем идентификатор смарта, если его нету даже в пакете, хрен с ним, будет 65535
end

if strn_id ~= 65535 then -- если сняли идентификатор, попробуем отрегать...
local gulag = sim:object(strn_id)
if gulag and gulag.gulag then -- ...но сначала выясним если вообще такой гулаг и инициализирован ли он
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end
end</code>

При этом сделаю отсупление и предупрежу об одном очень странном сбое с которым я столкнулся редактируя эту функцию. Так вот, всё нормально работает только тогда когда у ф-ции этой есть строго определённая структура. '''Стоит только добавить пару строк, убрать закомментированную и сдвинуть пару условий, просто в тексте сдвинуть, не меняя внутренней логики, как игра начинает вылетать, причём ещё до загрузки сейва, при кэшировании (!) и с очень странными логами, хотя код написан синтаксически безупречно! Например с таким:'''

<code>Description: xr_gulag:1035 value not found ObjectJobPathName[obj_id]</code>

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

Итак, теперь проблема с получением идентификатора смарта разрешилась, однако алайф всё равно зависал! Простая трассировка показала, что теперь зависание происходило внутри обработки

<code lua>sim:object(strn_id).gulag:clear_dead(obj_id)</code>

И мне пришлость распутывать её по частям, доискиваясь до причины. Обработка честно говоря мерзкая, размазана по smart_terrain и xr_gulag, при этом взаимные вызовы идут не менее десятка раз, в следующем стиле: ф-ция в смарте вызывает ф-цию в гулаге, которая вызывает фцию в смарте, которая обрабатывает параметр фцией в гулаге, который передётся ф-цией в логике, которая получает её из смарта. Нечто подобное. Опуская все нецензурные выражения, употребленные мной при трассировке, я лучше расскажу что собственно вышло в итоге. А в итоге я вышел вот на этот код в xr_gulag, именно в нём при отрегистрации некоторых мёртвых неписей происходит зависание алайфа:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)

local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- вот эта обработка вешает алайф
end
end</code>

Я, честно говоря, ни разу не понимаю, на кой чёрт нужно переконфигурировать схемы логики и выбирать из них активную '''трупу, который лежит себе спокойно и никого не трогает.''' Может быть в это есть некий высший смысл, или это было продиктовано неким аккуратизмом, однако одно я могу сказать однозначно - подобная переинициализация у некоторых трупов неписей приводит к глухому зависанию алайфа. При этом если для трупов эту обработку заблокировать, то трупы разрегистрируются вполне нормально и спокойно лежат с нетронутой логикой, не вызывая никаких проблем. Итоговый код после правок выглядит вот так:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)
local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
if check_game() then -- тут проверяется, запущена ли игра, если ли актор и жив ли он. Если да, делаем по новому.
local s_obj = alife():object(obj_id) -- проверим есть ли у цели разрегистрации валидный серверный объект
if s_obj and (IsStalker(s_obj) or IsMonster(s_obj)) and s_obj:alive() then -- если есть, он жив и сталкер или монстр
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- только тогда инициализируем логику
end
else -- а если игра не запущена, то как раньше. Это нужно для того, чтобы обработка запуска игры нормально работала.
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) )
end
end
end

-- Проверка, запущена ли игра
function check_game()
if level.present() and (db.actor ~= nil) and db.actor:alive() then
return true
end
return false
end
</code>

После этих поправок зависания алайфа при смерти неписей удалось побороть окончательно. Решение с отрезанием реинита логики для трупов несколько грубовато, но честно говоря, у меня нет ни малейшего желания трассировать и разбирать на части функцию xr_logic.initialize_obj, выясняя, чем же ей так данный конкретный труп не приглянулся. Если хотите - займитесь, найдёте причину - дополните данную статью. Я же успокоился на том, что заблокировал баг, периодически убивающий людям игру, так как многие пользователи, игнорируя предупреждения, играют на одном-двух сейвах, а то и вовсе на квиксейвах всю игру.

= Другие частые проблемы =

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

== Вылеты при удалении объектов из игры ==

При использовании для удаления объектов родной движковой функции '''alife():release(alife():object(id), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:

1) Вылет при удалении непися или монстра, находящегося в онлайне.
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, который жив и находится в онлайне, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.

2) Вылет при удалении оружия или артефакта.
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:

<code lua> local obj = alife():object(i)
if obj then
alife():release(obj, true)
end</code>

Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.

3) Вылет при удалении аномалии.
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.

== Вылет при открытии закладки "Контакты" в ПДА ==

Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.

== Вылеты при вызове несуществующих функций из XML ==

В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:

<code xml>
<info_portion id="barman_document_have">
<action>dialogs.set_actor_prebandit1</action>
<action>bar_spawn.bandits2</action>
<action>bar_spawn.bandits3</action>
<action>bar_spawn.bandit7</action>
<action>bar_spawn.bandit8</action>
</info_portion>
</code>

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

== Повреждения сейвов на Радаре и других местах в модах, основанных на OGSM ==

В оригинале ОГСМ и основанных на нём модах часто встречались проблемы с сохранениями на Радаре. Эту проблему долго не удавалось победить, пока наконец благодаря помощи Маландринуса не удалось выявить её первопричину. Как выяснилось, она очень проста - гражданские зомби в моде (монстры) имели в конфиге ту же пропись вида (параметр конфига specie), что и монолитовцы и зомбированные (неписи). И там и тут было проставлено "zombie", и так оно было ещё с оригинала. Как оказалось, так делать категорически нельзя. Дело в том, что у неписей есть такой функционал, как хитовая память - в ней какое-то время хранятся ссылки на атакующие объекты. У монстров тоже есть остатки этого функционала, но он неработоспособен, и использовать его нельзя. В случае же когда монстры и неписи попадают в один вид, в ситуации когда они находятся рядом в бою, хитовая память монстров автоматически получает от неписей того же вида распространяемую внутри вида информацию об атакующих - а хранить её монстрам нельзя. Если после создания такой ситуации сохраниться - сейв будет вызывать вылет при загрузке. То есть проще говоря, если в бою с монолитовцами рядом оказывались гражданские зомби - и игрок сохранял игру - сейв этот не загружался. Чтобы предотвратить эти проблемы, вполне достаточно создать для гражданских зомби свой отдельный вид, добавив его прописи в конфиг game_relations.

== Застывания NPC после боя / лечения ранения в модах, использующих дополнительные схемы поведения ==

Во многих модах, использующих дополнительные схемы поведения часто можно заметить NPC, которые после боя застывают, прицелившись в одну точку. Аналогично часто это встречается с вылеченными от ранения NPC - они встают и замирают намертво, до тех пор пока их не выведет из этого состояния атаковавший враг. Как правило сейв/загрузка этой проблемы не решают. В ходе работы над OGSE 0.6.9.3 мне удалось выяснить причину таких проблем и успешно её устранить. Причина проблемы заключается в том, что NPC управляются не только скриптовыми схемами, но и движком, и для переключения управления между одним и другим используется скрипт ''state_mgr'' - менеджер состояний. Его директивы имеют наивысший приоритет. Аналогичный же приоритет себе как правило назначают доп. схемы поведения, используя пропись эвалуатора в ''xr_motivatior.addCommonPrecondition(action)''. В итоге при выходе из движковой боевки или при переключении на движковый алайф (это происходит после излечения ранения) доп. схемы поведения вступают с менеджером состояний в конфликт, блокируя смену состояния NPC. Для того чтобы этого не происходило, '''необходимо во всех схемах поведения, использующих принудительное назначение состояния через функцию ''state_mgr.set_state'' сделать блокировку перехвата управления менеджером состояний''', добавив соответствующие прописи в биндер. Вот таким образом, как в этом примере - тут я правил биндер схемы лечения/самолечения ''xrs_medic'':

<code lua>
function add_to_binder(object, ini, scheme, section, storage)
local operators = {}
local properties = {}

local manager = object:motivation_action_manager()

operators["medic"] = actid_medic
operators["self_medic"] = actid_self_medic

properties["medic"] = evid_medic
properties["self_medic"] = evid_self_medic

local state_mgr_to_idle_combat = xr_actions_id.state_mgr + 1 ---< Это переключение на движковую боевку, но оно тут не использовано
local state_mgr_to_idle_alife = xr_actions_id.state_mgr + 2 ---< Это переключение на движковый алайф
local state_mgr_to_idle_off = xr_actions_id.state_mgr + 3 ---< Это переключение в статичное состояние

local zombi=object:character_community()=="zombied" or object:character_community()=="trader" or
object:character_community()=="arena_enemy" or object:name()=="mil_stalker0012" or object:name()=="yantar_ecolog_general"

if zombi then
manager:add_evaluator (properties["medic"], property_evaluator_const(false))
manager:add_evaluator (properties["self_medic"], property_evaluator_const(false))
else
manager:add_evaluator (properties["medic"], evaluator_medic("medic", storage))
manager:add_evaluator (properties["self_medic"], evaluator_self_medic("self_medic", storage))
end

local action = action_medic (object,"medic", storage)
action:add_precondition(world_property(stalker_ids.property_alive, true))
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))
action:add_precondition (world_property(properties["medic"], true))
action:add_effect (world_property(properties["medic"], false))
manager:add_action (operators["medic"], action)

local action = action_self_medic (object,"self_medic", storage)
action:add_precondition(world_property(stalker_ids.property_alive, true))
action:add_precondition(world_property(stalker_ids.property_enemy,false))
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))
action:add_precondition (world_property(properties["medic"], false))
action:add_precondition (world_property(properties["self_medic"], true))
action:add_effect (world_property(properties["self_medic"], false))
manager:add_action (operators["self_medic"], action)

action = manager:action (stalker_ids.action_alife_planner)
action:add_precondition (world_property(properties["medic"], false))
action:add_precondition (world_property(properties["self_medic"], false))

action = manager:action(state_mgr_to_idle_alife)
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться на движковый алайф пока работает самолечение

action = manager:action(state_mgr_to_idle_off)
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться статичное состояние пока работает самолечение

end
</code>

Вставка этих директив в биндеры всех схем, которые меняют состояния принудительно устраняет конфликты, и NPC больше не виснут при смене схем.

== Зависания алайфа из-за ошибок в конфигах торговли ==

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

<code>
novice_outfit ;NO TRADE
</code>

Запомните - в секции ''buy_supplies'' конфига торговли таких записей быть не должно вообще. Если вы хотите убрать вещь из общего ассортимента - удалите её строку из ''buy_supplies''.

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 31 марта 2011 (UTC)

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

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