Настройка логики. Часть 4

2009-12-05T18:18:50Z

95.59.36.67: /* 3.10.6. Ph_sound */

{{Шаблон:Настройка логики}}

==3.10.3. Схема работы прожектора:==

В точках look пути, в которые смотрит прожекторщик, нужно прописать
sl=имя_прожектора

Например 
wp00|sl=esc_sl1 

Тогда при повороте в эту точку персонаж повернет в нее и прожектор.

==3.10.4. Кодовые замки:==

При введении указанного кода выдает инфопоршн

[logic] 
active = ph_code@lock 

[ph_code@lock] 
code = 1243 
on_code = %+infoportion% 

Файл: \gamedata\scripts\ph_code.script

==3.10.5. Ph_gate:==

То же самое, что и ph_door, но для ворот, состоящих из двух дверей:
Вместо параметров closed и locked сейчас используются параметры: 
state: состояние, в котором дверь находится при инициализации (по умолчанию none) 
open - в открытом 
closed - в закрытом 
none - в текущем (дефолтном или оставшемся от предыдущей схемы) 

locking: блокировка дверей (по умолчанию none) 
stick - прилипание дверей к крайним состояниям (пока в процессе настройки) 

soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной
Состояния в этом положении: 
open - блокировать в открытом состоянии 
closed - в закрытом 
none - не используется (мягкая блокировка возможна только в крайних положениях) 

hard - блокировка двери с помощью границ. Ворота можно только сломать
Состояния в этом положении: 
open - блокировать в открытом состоянии 
closed - в закрытом 
none - в текущем 

none - дверь не заблокирована

Общие параметры:
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. 
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true. 

Звуковые параметры аналогичны ph_door 

Примеры: 
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые. 
state = opened 
locking = soft 
left_limit = 130 
rigt_limit = 60 
breakable = false 

[ph_gate@opened] 
state = opened 
locking = stick 

[ph_gate@closed] 
state = closeded 

Файл: \gamedata\scripts\ph_gate.script 

==3.10.6. Ph_sound==

Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник). 

[ph_sound] 
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes 
*looped = true/false зацикленое воспроизведение звука (default - false) 
*min_idle = минимальное время простоя перед включением звука (мс) 
*max_idle = максимальное время простоя перед включением звука (мс) 
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения 

NB! Если мы задаем random = true и looped = true, то версия сыпется 

Также поддерждивается кондлист. 
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil 

Пример подобной извращенной логики: 
[logic] 
active = ph_sound 

[ph_sound] 
snd = gar_seryi_shooting 
looped = true 
max_idle = 5000 
on_actor_in_zone = gar_seryi_factory| ph_sound@end 

[ph_sound@end] 
snd = gar_seryi_shooting_2 
looped = false 
on_signal = sound_end| nil 

Кроме того специфическим образом создается звуковая схема. 
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. 
Например: 
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]} 

Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет. Однако в оригинале такое встречается, например в бункере Выжигателя мозгов есть рестриктор bun_space_restrictor_sound1 на который как раз и повешан ph_sound. 

Файл: \gamedata\scripts\ph_sound.script 

==3.10.7. Ph_force==

Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета. 

force = сила, которая прикладывается к объекту. Измеряется в убитых енотах 
time = время прикладывания силы к предмету (в секундах) 
*delay = задержка (в секундах) перед применением силы 
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет) 
point_index = индекс точки патрульного пути, в стону которого полетит предмет. 

==3.10.8. Ph_on_death==

Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов 
Пример: 

[logic] 
active = ph_on_death 

[ph_on_death] 
on_info = %эффекты% 

Юзать исключительно с разрушаемыми физ. Объектами 

==3.10.9. Ph_car==

Настройка возможности игроку управлять машиной. 
секция: [ph_car] 
поле: usable = <condlist> 

usable - кондлист возвращающий true (по умолчанию) или false. 

Пример: 
[logic] 
active = ph_car 

[ph_car] 
usable = {+val_actor_has_car_key} 

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

==3.10.10. Ph_heavy==
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.
В кастом дате пишем:

[ph_heavy]

==3.10.11. Ph_oscillate==
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)
Пример логики 

[ph_oscillate] 
joint = provod - имя кости к которой будет применена сила 
force = 5 - собственно сила (в ньютонах) 
period = 1000 - время прикладывания силы. 

Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.

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

Как поставить smart terrain? 
Для всех smart terrain нужно: 
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность). 
2) В его custom data прописать настройки. 
3) Расставить пути для соответствующих схем поведения. 

Параметры custom data: 
[gulag1] 
type = тип гулага 
capacity = макс. вместимость в людях
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)
*groups = набор group через запятые
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)
*idle = min, max время бездействия smart_terrain после ухода последнего npc
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.

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

Пути: 
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep. 

Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) 

Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов. 

==3.11.1.1. Стандартные типы смарттеррейнов.==

Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку: 
[smart_terrains] 
none = true 

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

===campers===
Кемперы. custom data: 
[gulag1] 
type = campers 
capacity = от 1 до 3 

Пути: 
camper_walk1, camper_look1 
camper_walk2, camper_look2 
camper_walk3, camper_look3 

===walkers===
Ходячие. На базе этого можна сделать поиск, обыск и куча всего. 
custom data: 
[gulag1] 
type = walkers 
capacity = от 1 до 3 

Пути: 
walker_walk1, walker_look1 
walker_walk2, walker_look2 
walker_walk3, walker_look3 

===search===
Ходячие. На базе этого можна сделать поиск, обыск и куча всего. 
custom data: 
[gulag1] 
type = search 
capacity = 1 

Пути: 
search_walk, search_look 

Схема следующая: 
1. Персонаж ходит по точкам, смотрит по сторонам 
2. В определенных точках останавливается и что-то высматривает (caution, search, hide) 
3. При этом говорит определенные реплики (…) 

===rest===
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).
custom data: 
[gulag1] 
type = rest 
capacity = 1 

Пути: 
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит. 
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит. 
rest_walk, rest_look 

==3.11.2. Гулаги.==
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: 
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения);
Б) Работы имеют приоритеты; 
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом;
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага. 

Гулаг создается следующим образом: 

1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше. 

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

3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет. 

4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага. 
[gulag1] 
type = тип гулага 
capacity = макс. вместимость в людях 
*offline = может ли гулаг образоваться в offline (true/false)
*squad = squad, который будет проставлен всем сталкерам под гулагом
*groups = набор group через запятые
*stay = min, max время пребывания npc под smart_terrain
*idle = min, max время бездействия smart_terrain после ухода последнего npc
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)

Capacity нужно задавать всегда. Она может быть равна или меньше числа работ. 
Указывать тип гулага нужно без кавычек. 
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет. 
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться. 
Все времена задаются в часах игрового времени и могут быть дробными. 

5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:
<code>
if gulag_type == "gar_dolg" then
return npc_community == "dolg"
end
</code>
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг. 

6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. 

function loadStates(gname, type) 
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например: 
<code>
if type == "gar_maniac" then
return function(gulag)
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then
return 0 -- день
else
return 1 -- ночь
end
end
end
</code>
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном. 

8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры: 
function loadJob(sj, gname, type, squad, groups) 
sj – сама табличка работ гулагов, 
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс. 
Type – тип гулага 
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу. 

Примерное описание работ гулага: 
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу. 
<code>
--' Garbage maniac
if type == "gar_maniac" then
t = { section = "logic@gar_maniac_camper",
idle = 0,
prior = 5, state = {0},
squad = squad, groups = groups[1],
in_rest = "", out_rest = "",
info_rest = ""
}
table.insert(sj, t)
t = { section = "logic@gar_maniac_sleeper",
idle = 0,
prior = 5, state = {1},
squad = squad, groups = groups[1],
in_rest = "", out_rest = "",
info_rest = ""
}
table.insert(sj, t)
end
</code>
Описание полей: 
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль. 
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет. 
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание. 
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе. 
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1. 
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе 
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: 
<code>
predicate = function(obj)
return obj:profile_name() == "soldier_commander”
end
</code>
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander. 

9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac: 
<code>
;----------------------------
;-- GARBAGE MANIAC
;----------------------------
[logic@gar_maniac_camper]
active = camper@gar_maniac_camper

[camper@gar_maniac_camper]
path_walk = walk1
path_look = look1

[logic@gar_maniac_sleeper]
active = sleeper@gar_maniac_sleeper

[sleeper@gar_maniac_sleeper]
path_main = sleep
wakeable = true
</code>
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей: 
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1. 
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate) 
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2). 

В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них. 

==3.11.3. Новые особенности смарттеррейнов==
Возможности нового смарттеррейна (СТ): 

1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус. 
2) Сталкеры идут на ближайшие работы. 
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне. 
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ. 
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие. 
6) Работы могут находиться на разных уровнях. 
7) Скриптовая зона СТ теперь не используется для захвата персонажей. 
8) Симуляция заключается в миграции персонажей между разными СТ. 

Что нужно переделать: 

1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже) 
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай) 
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже) 
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain]. 

------------- Настройки: -------------

---- Разрешения персонажам идти в определённые СТ ----

Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример: 

[smart_terrains] 
strn_1 = условие1 
strn_2 = условие2 

Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным. 
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.
Если не появилось ни одного эксклюзивного, то он согласен идти в любой. 

Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой. 

Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать: 

communities = группирвка1, группировка2, ... 

Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется). 

---- Изменение функций predicate() ---- 

В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля: 
name 
community 
class_id 
story_id 
profile_name 

Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать: 
<code>
predicate = function(npc_info)
return npc_info.is_sniper == true
end
</code>

---- Изменение функций переключения состояния СТ ----

Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п. 

---- Состояния работ online/offline
<code>
t = { section = "logic@ЧЧЧЧЧЧЧЧ",
idle = 0,
prior = 5, state = {0}, squad = squad, group = groups[1],
online = true,
in_rest = "", out_rest = ""
}
table.insert(sj, t)
</code>
Варианты задания этого поля 
online = true - на этой работе персонаж всегда в онлайне, 
online = false - на этой работе персонаж всегда в офлайне, 
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению. 
3.11.3.1. Более доступное описание новых смарттеррейнов 
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски. 
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее: 
1. Пишем в кастом дате где [gulag1] -> [smart_terrain] 
2. В кастом дате товарищей по смарттеррейну пишем 
[smart_terrains] 
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true. 
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату. 
[smart_terrains] 
none = true 

==3.12. Логика вертолёта==
Общие сведения: 

Вертолёт работает на «логике». 
На вертолёт реагируют аномалии. 
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит. 
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта. 
У вертолёта есть универсальная боевая схема на манер сталкеров. 
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает. 

==3.12.1. Схема heli_move:==
Общие сведения:
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.

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

Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.

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

По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень).

Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.

Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.

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

Настройки:

*engine_sound = true/false (по умолчанию true)
Вкл/выкл звук двигателя вертолёта.

*invulnerable = true/false (по умолчанию false)
Неуязвимость. Если true, вертолёт игнорирует все хиты.

*immortal = true/false (по умолчанию false)
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.

*mute = true/false (по умолчанию false)
Отключает универсальные реплики пилотов вертолета.

*rocket_delay = msec (время в миллисекундах реального времени)
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)

*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)

Параметры, задаваемые в именах вершин пути path_move:

«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.

«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.

«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.

«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.

«die» - убить вертолёт.

«flame» - начать дымить (как будто подбили).

Параметры, задаваемые в именах вершин пути path_look:

«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.

«w» – см. такой же параметр для пути path_move.

«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.

==3.12.2. Универсальная боевая схема:==
Общие сведения:

В универсальной боевой схеме вертолёт не привязан к путям.

Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.

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

Настройки:

Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:

combat_ignore = true/false
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.

combat_enemy = nil/actor/StoryID
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.

combat_use_rocket = true/false
Можно ли вертолёту пользоваться рокетами.

combat_use_mgun = true/false
Можно ли вертолёту пользоваться пулемётом.

combat_velocity = <число>
Скорсть, с которой вертолет будет делать боевые заходы

combat_safe_altitude = <число>
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)

К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:

heli_set_enemy_actor - сделать актёра врагом вертолёту
heli_start_flame - поджечь вертолёт
heli_die - убить вертолёт

combat_velocity = - боевая скорость в этой секции указывается в м/с
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения
combat_use_rocket = - true/false использовать ли ракеты в этой секции
combat_use_mgun = - true/false использовать ли пулемет в этой секции

==3.13. Meet_manager==

Синтаксис:

[logic] 
meet = meet 

[walker] 
meet = meet 

[meet] 
meet_state = 30| state@sound| 20| state@sound| 10| state@sound 
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound 
victim = 30| nil| 20| actor 
victim_wpn = 30| nil| 20| actor 
use = self 
use_wpn = false 
zone = name| state@sound 
meet_dialog = dialog_id 
synpairs = state@sound|state@sound 
abuse = true/false 

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

Перечень полей: 
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно. 
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть. 
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться  
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе 
meet_dialog – стартовый диалог НПС. 
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела. 
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться. 
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% ) 

Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:

[walker] 
meet = default_meet

Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.

Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):

===Ситуация 1===
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.

[meet] 
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait 
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap 
victim = 50| actor 
victim_wpn = 50| actor 
use = true 
use_wpn = false 

===Ситуация 2===
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.

[meet] 
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state 
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait 
victim = 50| actor 
victim_wpn = 50| actor 
use = {-info2} self, false 
use_wpn = false

Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС 
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел. 
Killactor – функция в xr_effects которая обижает НПС на игрока.

===Ситуация 3===
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.

[camper] 
path_walk = path_walk 
path_look = path_look 
meet = meet 

[meet] 
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back 
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back 
victim = 30| actor 
victim_wpn = 30| actor 
use = true 
use_wpn = true 
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse 
meet_dialog = {+info} dialog1, dialog2 

Здесь: 
True – вместо анимации, атаковать игрока. 
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю 
Warnzone – рестриктор, в котором нас предупреждают 
Kampzone – рестриктор, в котором нас убивают 
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь 
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь. 
Дефолтные настройки: 
По дефолту встреча настроена со следующими параметрами: 

meet_state = 30|hello@hail|20|wait@wait 
meet_state_wpn = 30|backoff@threat_weap 
victim = 30|actor 
victim_wpn = 30|actor 
use = true 
use_wpn = false 
syndata = hello@hail|backoff@threat_weap 

NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet

==3.14. Отметки на минимапе==
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:

[camper] 
show_spot = false (будучи в этой секции сталкер не показывается на карте)

[walker] 
show_spot = {+info1} false

Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.

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

NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.

Описание функций с параметрами присутствующих в xr_conditions и xr_effects.

---------------------------------------------------------------------
xr_conditions:

fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока
(в метрах)

distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного story_id. 
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.

health_le(health) - проверка того, что здоровье npc <= health

heli_health_le(health) - аналогично предыдущему, только для вертолета.

enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)

hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.
Пример:
[hit] 
on_info = {=hitted_by(407:408)} %+val_escort_combat%

killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.

is_alive(sid) 
is_alive_one(sid1:sid2:...) 
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы

is_dead(sid) 
is_dead_one(sid1:sid2:...) 
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".

check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.

gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.

gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num

gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.

signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал

--------------------------------------------------------------------
xr_effects:

heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.

set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага

hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры: 
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит. 
bone - строка. Имя кости, по которой наносится удар. 
power - сила удара 
impulse - импульс 
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.
Пример: 
[death] 
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%

set_friends(sid1:sid2:...) 
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.

play_snd(snd_name:delay=0) - играть звук в голове актёра. 
snd_name - путь к звуку относительно папки sounds 
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.

play_snd_now (sid:snd_name) – играть звук от указанного объекта 
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла

hit_obj(sid, bone, power, impulse, hit_src=npc:position()) 
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()] 
1. sid - story_id обьекта, по которому наносится хит. 
2. bone - строка. Имя кости, по которой наносится удар. 
3. power - сила удара 
4. impulse - импульс 
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.

actor_has_item(section) 
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx

Функции для работы с HUD'ом.

disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.

Параметры: 
-- weapon - спрятать/показать руки с оружием 
-- input - отключить/включить клавиатуру 
-- hud - спрятать/показать индикаторы на экране 
-- all - отключить/включить все элементы

Пример: 
on_info = %=disable_ui_elements(weapon:input)%

Есть также сокращенные варианты:

disable_ui, enable_ui (вызываются без скобок и параметров). 
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.

Пример: 
on_info = %=enable_ui%

Функция запуска camera_effector'а.

run_cam_effector(имя_файла)

имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)
из папки S:\GameData\anims\camera_effects\.

Пример: 
on_info = %=run_cam_effector(prison_0)%

Функция запуска постпроцесса.

В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск. 
Теперь есть 2 функции для работы с постпроцессами:

run_postprocess(file_name:id:loop) - запуск постпроцесса. 

-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения. 
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess. 
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false. 

stop_postprocess(id) - принудительная остановка постпроцесса.

-- id - номер постпроцесса заданный в run_postprocess.

Функция выброса содержимого инвентаря актера в определенную точку.

drop_actor_inventory(имя_пути)

выбрасываем все предметы из инвентаря актера в первую точку заданного
пути.

Пример: 
on_info = %=drop_actor_inventory(drop_point)% 

==3.16. Настройка звуковых групп.==
Новый принцип создания звуковых групп: 
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе. 
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка> 
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например: 
soundgroup = bar_dolg_kampfire1 
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. 
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group 

Пример: 
[kamp@esc_bridge_post1] 
center_point = kamp_point 
soundgroup = esc_bridge_soldiers 

==Ссылки==
Оригинальный doc ([http://stalkerin.gameru.net//downloads/other/for_wiki_articles/logic_setup.doc Ссылка]) 

Доки скриптеров 1935([http://stalkerin.gameru.net//downloads/other/for_wiki_articles/doc_scripters.rar Ссылка])

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

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

Настройка логики. Часть 4