http://stalkerin.gameru.net/wiki/api.php?action=feedcontributions&feedformat=atom&user=78.106.25.142&*S.T.A.L.K.E.R. Inside Wiki - Вклад участника [ru]2026-04-29T12:08:13ZВклад участникаMediaWiki 1.22.6http://stalkerin.gameru.net/wiki/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8Шаблон:Настройка логики2007-08-14T21:07:42Z<p>78.106.25.142: </p>
<hr />
<div>{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
Часть 1: [[Настройка_логики]]<br/><br />
[[Часть_2]]<br/><br />
[[Часть_3]]<br/><br />
[[Часть_4]]<br />
|-<br />
|}</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8Шаблон:Настройка логики2007-08-14T21:03:13Z<p>78.106.25.142: </p>
<hr />
<div>{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
Часть 1: [[Настройка_логики]]<br/><br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_2 Часть вторая]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_3 Часть третья]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_4 Часть четвертая]<br />
|-<br />
|}</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8Шаблон:Настройка логики2007-08-14T21:01:33Z<p>78.106.25.142: </p>
<hr />
<div>{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
[[Настройка_логики Часть первая]]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_2 Часть вторая]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_3 Часть третья]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_4 Часть четвертая]<br />
|-<br />
|}</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8Шаблон:Настройка логики2007-08-14T20:57:24Z<p>78.106.25.142: </p>
<hr />
<div>{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
[http://www.stalkerin.gameru.net/wiki/index.php/Настройка_логики Часть первая]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_2 Часть вторая]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_3 Часть третья]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_4 Часть четвертая]<br />
|-<br />
|}</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8Шаблон:Настройка логики2007-08-14T20:56:22Z<p>78.106.25.142: </p>
<hr />
<div>{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
| [http://www.stalkerin.gameru.net/wiki/index.php/Настройка_логики Часть первая]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_2 Часть вторая]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_3 Часть третья]<br />
<br><br />
[http://www.stalkerin.gameru.net/wiki/index.php/Часть_4 Часть четвертая]<br />
|-<br />
|}</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_4Настройка логики. Часть 42007-08-14T20:54:56Z<p>78.106.25.142: </p>
<hr />
<div>{{Шаблон:Настройка логики}}<br />
<br />
==3.10.3. Схема работы прожектора:==<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
==3.10.4. Кодовые замки:==<br />
<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
==3.10.5. Ph_gate:==<br />
<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
==3.10.6. Ph_sound==<br />
<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
==3.10.7. Ph_force==<br />
<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
==3.10.8. Ph_on_death==<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
==3.10.9. Ph_car==<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
==3.10.10. Ph_heavy==<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
==3.10.11. Ph_oscillate==<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
==3.11. Смарттерейны и гулаги.==<br />
==3.11.1. Смарттеррейн.==<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
==3.11.1.1. Стандартные типы смарттеррейнов.==<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
==3.11.3. Новые особенности смарттеррейнов==<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
==3.12.1. Схема heli_move:==<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
==3.12.2. Универсальная боевая схема:==<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
==3.14. Отметки на минимапе==<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
==3.15. Передача параметров в функции.==<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_3Настройка логики. Часть 32007-08-14T20:54:29Z<p>78.106.25.142: </p>
<hr />
<div>{{Шаблон:Настройка логики}}<br />
<br />
==3.8.1. Синтаксис скрипта Logic==<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
<br />
==3.8.2. Вот пример достаточно сложной логики:== <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
==3.9. Схемы логики space_restrictor==<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
<br />
==3.9.1. Схема [sr_idle]== <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
<br />
==3.9.2. Секция [sr_no_weapon]==<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
==3.9.3. Секция [sr_sound]==<br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
==3.9.4. Секция [sr_tip]==<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
==3.9.5. Sr_light==<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
<br />
==3.9.6. Sr_territory==<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
==3.9.7. Sr_mapspot==<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
==3.9.8. Sr_particle==<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
==3.9.9. Sr_sound_act==<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
==3.9.10 Sr_timer==<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
==3.9.11. Sr_psy_antenna==<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
==3.9.12. Sr_teleport==<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
==3.9.13. Sr_sleep и настройка снов.==<br />
<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
==3.9.14. Sr_cutscene==<br />
<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
==3.10. Набор дополнительных настроек логики у разных объектов.==<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
==3.10.1. Схема работы двери, секция [ph_door]==<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
==3.10.2. Схема работы кнопки, секция [ph_button]==<br />
<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
===[[Часть 4]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_2Настройка логики. Часть 22007-08-14T20:54:12Z<p>78.106.25.142: </p>
<hr />
<div>{{Шаблон:Настройка логики}}<br />
<br />
==3.3.7. Секция dont_spawn_character_supplies==<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
==3.3.8. Секция no_smart==<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
==3.3.9. Секция treshhold==<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
==3.3.10. Danger==<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
==3.3.11. Байки из склепа (Истории у костра)==<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
==3.3.12. dont_spawn_loot==<br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
==3.4. Оверрайды:==<br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
==3.5. Схемы для монстров==<br />
<br />
==3.5.1. Схема mob_walker.==<br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
==3.5.2. Схема mob_eluder==<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
==3.5.3. Схема mob_remark==<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
==3.5.4. Схема mob_combat, mob_death==<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
<br />
==3.5.6 Схема mob_jump (монстр-пружинка)==<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
<br />
==3.5.7. Mob_camp==<br />
<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
==3.5.8. Mob_home==<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
==3.5.9. Mob_fake_death==<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
==3.6. Оверрайды для монстров:==<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
<br />
==3.7. Секция spawner==<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
==3.7.1. Спавн монстров дневных и ночных.==<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
==3.8. Скрипт logic==<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
<br />
===[[Часть 3]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8Шаблон:Настройка логики2007-08-14T20:53:17Z<p>78.106.25.142: </p>
<hr />
<div>{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
| [http://www.stalkerin.gameru.net/wiki/index.php/Настройка_логики Часть первая]<br />
|-<br />
| [http://www.stalkerin.gameru.net/wiki/index.php/Часть_2 Часть вторая]<br />
|-<br />
|[http://www.stalkerin.gameru.net/wiki/index.php/Часть_3 Часть третья]<br />
|-<br />
|[http://www.stalkerin.gameru.net/wiki/index.php/Часть_4 Часть четвертая]<br />
|-<br />
|}</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T20:46:06Z<p>78.106.25.142: </p>
<hr />
<div>'''GSC GameWorld'''<br />
<br />
{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
{{Шаблон:Настройка логики}}<br />
|-<br />
|}<br />
<br />
=Настройки логики=<br />
<br />
==3.1. Система флагов (path_walk, path_look)==<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
==3.1.1. Более подробное описание путей. ==<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
==3.2. Схемы поведения сталкеров.==<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
==3.2.2. Схема remark==<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
==3.2.4. Схема kamp==<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
<br />
==3.2.5. Схема camper==<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
<br />
==3.2.5.1. Схема sniper==<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
==3.2.6. Схема follower== <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
==3.2.7. Схема zoneguard==<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
==3.2.8. Схема wounded (раненый)==<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
==3.2.9. Схема rest==<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
==3.2.10. Схема heli_hunter==<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
==3.2.11. Patrol==<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
==3.3. Секции.==<br />
==3.3.1. Секция combat==<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
==3.3.2 Секция death==<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
==3.3.3. Cекция hit==<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
==3.3.4. Секция actor_dialogs==<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
==3.3.5. Секция use==<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
==3.3.6. Секция combat_ignore==<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
===[[Часть 2]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_4Настройка логики. Часть 42007-08-14T20:44:40Z<p>78.106.25.142: </p>
<hr />
<div>==3.10.3. Схема работы прожектора:==<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
==3.10.4. Кодовые замки:==<br />
<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
==3.10.5. Ph_gate:==<br />
<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
==3.10.6. Ph_sound==<br />
<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
==3.10.7. Ph_force==<br />
<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
==3.10.8. Ph_on_death==<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
==3.10.9. Ph_car==<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
==3.10.10. Ph_heavy==<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
==3.10.11. Ph_oscillate==<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
==3.11. Смарттерейны и гулаги.==<br />
==3.11.1. Смарттеррейн.==<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
==3.11.1.1. Стандартные типы смарттеррейнов.==<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
==3.11.3. Новые особенности смарттеррейнов==<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
==3.12.1. Схема heli_move:==<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
==3.12.2. Универсальная боевая схема:==<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
==3.14. Отметки на минимапе==<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
==3.15. Передача параметров в функции.==<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_3Настройка логики. Часть 32007-08-14T20:44:08Z<p>78.106.25.142: </p>
<hr />
<div>==3.8.1. Синтаксис скрипта Logic==<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
<br />
==3.8.2. Вот пример достаточно сложной логики:== <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
==3.9. Схемы логики space_restrictor==<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
<br />
==3.9.1. Схема [sr_idle]== <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
<br />
==3.9.2. Секция [sr_no_weapon]==<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
==3.9.3. Секция [sr_sound]==<br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
==3.9.4. Секция [sr_tip]==<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
==3.9.5. Sr_light==<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
<br />
==3.9.6. Sr_territory==<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
==3.9.7. Sr_mapspot==<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
==3.9.8. Sr_particle==<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
==3.9.9. Sr_sound_act==<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
==3.9.10 Sr_timer==<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
==3.9.11. Sr_psy_antenna==<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
==3.9.12. Sr_teleport==<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
==3.9.13. Sr_sleep и настройка снов.==<br />
<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
==3.9.14. Sr_cutscene==<br />
<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
==3.10. Набор дополнительных настроек логики у разных объектов.==<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
==3.10.1. Схема работы двери, секция [ph_door]==<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
==3.10.2. Схема работы кнопки, секция [ph_button]==<br />
<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
===[[Часть 4]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_2Настройка логики. Часть 22007-08-14T20:43:00Z<p>78.106.25.142: </p>
<hr />
<div>==3.3.7. Секция dont_spawn_character_supplies==<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
==3.3.8. Секция no_smart==<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
==3.3.9. Секция treshhold==<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
==3.3.10. Danger==<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
==3.3.11. Байки из склепа (Истории у костра)==<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
==3.3.12. dont_spawn_loot==<br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
==3.4. Оверрайды:==<br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
==3.5. Схемы для монстров==<br />
<br />
==3.5.1. Схема mob_walker.==<br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
==3.5.2. Схема mob_eluder==<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
==3.5.3. Схема mob_remark==<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
==3.5.4. Схема mob_combat, mob_death==<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
<br />
==3.5.6 Схема mob_jump (монстр-пружинка)==<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
<br />
==3.5.7. Mob_camp==<br />
<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
==3.5.8. Mob_home==<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
==3.5.9. Mob_fake_death==<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
==3.6. Оверрайды для монстров:==<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
<br />
==3.7. Секция spawner==<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
==3.7.1. Спавн монстров дневных и ночных.==<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
==3.8. Скрипт logic==<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
<br />
===[[Часть 3]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T20:40:53Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by GSC GameWorld'''<br />
<br />
{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
{{Шаблон:Настройка логики}}<br />
|-<br />
|}<br />
<br />
=Настройки логики=<br />
<br />
==3.1. Система флагов (path_walk, path_look)==<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
==3.1.1. Более подробное описание путей. ==<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
==3.2. Схемы поведения сталкеров.==<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
==3.2.2. Схема remark==<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
==3.2.4. Схема kamp==<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
<br />
==3.2.5. Схема camper==<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
<br />
==3.2.5.1. Схема sniper==<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
==3.2.6. Схема follower== <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
==3.2.7. Схема zoneguard==<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
==3.2.8. Схема wounded (раненый)==<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
==3.2.9. Схема rest==<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
==3.2.10. Схема heli_hunter==<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
==3.2.11. Patrol==<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
==3.3. Секции.==<br />
==3.3.1. Секция combat==<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
==3.3.2 Секция death==<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
==3.3.3. Cекция hit==<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
==3.3.4. Секция actor_dialogs==<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
==3.3.5. Секция use==<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
==3.3.6. Секция combat_ignore==<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
===[[Часть 2]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T20:33:20Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by GSC GameWorld'''<br />
<br />
=Настройки логики=<br />
<br />
==3.1. Система флагов (path_walk, path_look)==<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
==3.1.1. Более подробное описание путей. ==<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
==3.2. Схемы поведения сталкеров.==<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
==3.2.2. Схема remark==<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
==3.2.4. Схема kamp==<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
<br />
==3.2.5. Схема camper==<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
<br />
==3.2.5.1. Схема sniper==<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
==3.2.6. Схема follower== <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
==3.2.7. Схема zoneguard==<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
==3.2.8. Схема wounded (раненый)==<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
==3.2.9. Схема rest==<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
==3.2.10. Схема heli_hunter==<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
==3.2.11. Patrol==<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
==3.3. Секции.==<br />
==3.3.1. Секция combat==<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
==3.3.2 Секция death==<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
==3.3.3. Cекция hit==<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
==3.3.4. Секция actor_dialogs==<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
==3.3.5. Секция use==<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
==3.3.6. Секция combat_ignore==<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
===[[Часть 2]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_4Настройка логики. Часть 42007-08-14T20:31:59Z<p>78.106.25.142: </p>
<hr />
<div>==3.10.3. Схема работы прожектора:==<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
==3.10.4. Кодовые замки:==<br />
<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
==3.10.5. Ph_gate:==<br />
<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
==3.10.6. Ph_sound==<br />
<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
==3.10.7. Ph_force==<br />
<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
==3.10.8. Ph_on_death==<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
==3.10.9. Ph_car==<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
==3.10.10. Ph_heavy==<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
==3.10.11. Ph_oscillate==<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
==3.11. Смарттерейны и гулаги.==<br />
==3.11.1. Смарттеррейн.==<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
==3.11.1.1. Стандартные типы смарттеррейнов.==<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
==3.11.3. Новые особенности смарттеррейнов==<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
==3.12.1. Схема heli_move:==<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
==3.12.2. Универсальная боевая схема:==<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
==3.14. Отметки на минимапе==<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
==3.15. Передача параметров в функции.==<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_3Настройка логики. Часть 32007-08-14T20:31:25Z<p>78.106.25.142: </p>
<hr />
<div>==3.8.1. Синтаксис скрипта Logic==<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
<br />
==3.8.2. Вот пример достаточно сложной логики:== <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
==3.9. Схемы логики space_restrictor==<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
<br />
==3.9.1. Схема [sr_idle]== <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
<br />
==3.9.2. Секция [sr_no_weapon]==<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
==3.9.3. Секция [sr_sound]==<br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
==3.9.4. Секция [sr_tip]==<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
==3.9.5. Sr_light==<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
<br />
==3.9.6. Sr_territory==<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
==3.9.7. Sr_mapspot==<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
==3.9.8. Sr_particle==<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
==3.9.9. Sr_sound_act==<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
==3.9.10 Sr_timer==<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
==3.9.11. Sr_psy_antenna==<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
==3.9.12. Sr_teleport==<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
==3.9.13. Sr_sleep и настройка снов.==<br />
<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
==3.9.14. Sr_cutscene==<br />
<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
==3.10. Набор дополнительных настроек логики у разных объектов.==<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
==3.10.1. Схема работы двери, секция [ph_door]==<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
==3.10.2. Схема работы кнопки, секция [ph_button]==<br />
<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
===[[Часть 4]]===</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_2Настройка логики. Часть 22007-08-14T20:28:43Z<p>78.106.25.142: </p>
<hr />
<div>==3.3.7. Секция dont_spawn_character_supplies==<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
==3.3.8. Секция no_smart==<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
==3.3.9. Секция treshhold==<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
==3.3.10. Danger==<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
==3.3.11. Байки из склепа (Истории у костра)==<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
==3.3.12. dont_spawn_loot==<br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
==3.4. Оверрайды:==<br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
==3.5. Схемы для монстров==<br />
<br />
==3.5.1. Схема mob_walker.==<br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
==3.5.2. Схема mob_eluder==<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
==3.5.3. Схема mob_remark==<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
==3.5.4. Схема mob_combat, mob_death==<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
<br />
==3.5.6 Схема mob_jump (монстр-пружинка)==<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
<br />
==3.5.7. Mob_camp==<br />
<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
==3.5.8. Mob_home==<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
==3.5.9. Mob_fake_death==<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
==3.6. Оверрайды для монстров:==<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
<br />
==3.7. Секция spawner==<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
==3.7.1. Спавн монстров дневных и ночных.==<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
==3.8. Скрипт logic==<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
<br />
===[[Часть 3]]===</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T20:24:53Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by GSC GameWorld'''<br />
<br />
=Настройки логики=<br />
<br />
==3.1. Система флагов (path_walk, path_look)==<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
==3.1.1. Более подробное описание путей. ==<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
==3.2. Схемы поведения сталкеров.==<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
==3.2.2. Схема remark==<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
==3.2.4. Схема kamp==<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
<br />
==3.2.5. Схема camper==<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
<br />
==3.2.5.1. Схема sniper==<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
==3.2.6. Схема follower== <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
==3.2.7. Схема zoneguard==<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
==3.2.8. Схема wounded (раненый)==<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
==3.2.9. Схема rest==<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
==3.2.10. Схема heli_hunter==<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
==3.2.11. Patrol==<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
==3.3. Секции.==<br />
==3.3.1. Секция combat==<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
==3.3.2 Секция death==<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
==3.3.3. Cекция hit==<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
==3.3.4. Секция actor_dialogs==<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
==3.3.5. Секция use==<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
==3.3.6. Секция combat_ignore==<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
==3.3.7. Секция dont_spawn_character_supplies==<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
==3.3.8. Секция no_smart==<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
==3.3.9. Секция treshhold==<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
==3.3.10. Danger==<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
==3.3.11. Байки из склепа (Истории у костра)==<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
==3.3.12. dont_spawn_loot==<br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
==3.4. Оверрайды:==<br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
==3.5. Схемы для монстров==<br />
<br />
==3.5.1. Схема mob_walker.==<br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
==3.5.2. Схема mob_eluder==<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
==3.5.3. Схема mob_remark==<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
==3.5.4. Схема mob_combat, mob_death==<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
<br />
==3.5.6 Схема mob_jump (монстр-пружинка)==<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
<br />
==3.5.7. Mob_camp==<br />
<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
==3.5.8. Mob_home==<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
==3.5.9. Mob_fake_death==<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
==3.6. Оверрайды для монстров:==<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
<br />
==3.7. Секция spawner==<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
==3.7.1. Спавн монстров дневных и ночных.==<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
==3.8. Скрипт logic==<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
<br />
==3.8.1. Синтаксис скрипта Logic==<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
<br />
==3.8.2. Вот пример достаточно сложной логики:== <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
==3.9. Схемы логики space_restrictor==<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
<br />
==3.9.1. Схема [sr_idle]== <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
<br />
==3.9.2. Секция [sr_no_weapon]==<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
==3.9.3. Секция [sr_sound]==<br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
==3.9.4. Секция [sr_tip]==<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
==3.9.5. Sr_light==<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
<br />
==3.9.6. Sr_territory==<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
==3.9.7. Sr_mapspot==<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
==3.9.8. Sr_particle==<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
==3.9.9. Sr_sound_act==<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
==3.9.10 Sr_timer==<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
==3.9.11. Sr_psy_antenna==<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
==3.9.12. Sr_teleport==<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
==3.9.13. Sr_sleep и настройка снов.==<br />
<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
==3.9.14. Sr_cutscene==<br />
<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
==3.10. Набор дополнительных настроек логики у разных объектов.==<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
==3.10.1. Схема работы двери, секция [ph_door]==<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
==3.10.2. Схема работы кнопки, секция [ph_button]==<br />
<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
<br />
==3.10.3. Схема работы прожектора:==<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
==3.10.4. Кодовые замки:==<br />
<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
==3.10.5. Ph_gate:==<br />
<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
==3.10.6. Ph_sound==<br />
<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
==3.10.7. Ph_force==<br />
<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
==3.10.8. Ph_on_death==<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
==3.10.9. Ph_car==<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
==3.10.10. Ph_heavy==<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
==3.10.11. Ph_oscillate==<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
==3.11. Смарттерейны и гулаги.==<br />
==3.11.1. Смарттеррейн.==<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
==3.11.1.1. Стандартные типы смарттеррейнов.==<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
==3.11.3. Новые особенности смарттеррейнов==<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
==3.12.1. Схема heli_move:==<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
==3.12.2. Универсальная боевая схема:==<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
==3.14. Отметки на минимапе==<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
==3.15. Передача параметров в функции.==<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
===[[Часть 2]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T20:23:01Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by GSC GameWorld'''<br />
<br />
=Настройки логики=<br />
<br />
==3.1. Система флагов (path_walk, path_look)==<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
==3.1.1. Более подробное описание путей. ==<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
==3.2. Схемы поведения сталкеров.==<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
==3.2.2. Схема remark==<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
==3.2.4. Схема kamp==<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
<br />
==3.2.5. Схема camper==<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
<br />
==3.2.5.1. Схема sniper==<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
==3.2.6. Схема follower== <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
==3.2.7. Схема zoneguard==<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
==3.2.8. Схема wounded (раненый)==<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
==3.2.9. Схема rest==<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
==3.2.10. Схема heli_hunter==<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
==3.2.11. Patrol==<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
==3.3. Секции.==<br />
==3.3.1. Секция combat==<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
==3.3.2 Секция death==<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
==3.3.3. Cекция hit==<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
==3.3.4. Секция actor_dialogs==<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
==3.3.5. Секция use==<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
==3.3.6. Секция combat_ignore==<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
==3.3.7. Секция dont_spawn_character_supplies==<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
==3.3.8. Секция no_smart==<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
==3.3.9. Секция treshhold==<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
==3.3.10. Danger==<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
==3.3.11. Байки из склепа (Истории у костра)==<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
==3.3.12. dont_spawn_loot==<br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
==3.4. Оверрайды:==<br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
==3.5. Схемы для монстров==<br />
<br />
==3.5.1. Схема mob_walker.==<br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
==3.5.2. Схема mob_eluder==<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
==3.5.3. Схема mob_remark==<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
==3.5.4. Схема mob_combat, mob_death==<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
<br />
==3.5.6 Схема mob_jump (монстр-пружинка)==<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
<br />
==3.5.7. Mob_camp==<br />
<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
==3.5.8. Mob_home==<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
==3.5.9. Mob_fake_death==<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
==3.6. Оверрайды для монстров:==<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
<br />
==3.7. Секция spawner==<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
==3.7.1. Спавн монстров дневных и ночных.==<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
==3.8. Скрипт logic==<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
<br />
==3.8.1. Синтаксис скрипта Logic==<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
<br />
==3.8.2. Вот пример достаточно сложной логики:== <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
==3.9. Схемы логики space_restrictor==<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
<br />
==3.9.1. Схема [sr_idle]== <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
<br />
==3.9.2. Секция [sr_no_weapon]==<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
==3.9.3. Секция [sr_sound]==<br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
==3.9.4. Секция [sr_tip]==<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
==3.9.5. Sr_light==<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
<br />
==3.9.6. Sr_territory==<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
==3.9.7. Sr_mapspot==<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
==3.9.8. Sr_particle==<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
==3.9.9. Sr_sound_act==<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
==3.9.10 Sr_timer==<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
==3.9.11. Sr_psy_antenna==<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
==3.9.12. Sr_teleport==<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
==3.9.13. Sr_sleep и настройка снов.==<br />
<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
==3.9.14. Sr_cutscene==<br />
<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
==3.10. Набор дополнительных настроек логики у разных объектов.==<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
==3.10.1. Схема работы двери, секция [ph_door]==<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
==3.10.2. Схема работы кнопки, секция [ph_button]==<br />
<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
<br />
==3.10.3. Схема работы прожектора:==<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
==3.10.4. Кодовые замки:==<br />
<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
==3.10.5. Ph_gate:==<br />
<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
==3.10.6. Ph_sound==<br />
<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
==3.10.7. Ph_force==<br />
<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
==3.10.8. Ph_on_death==<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
==3.10.9. Ph_car==<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
==3.10.10. Ph_heavy==<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
==3.10.11. Ph_oscillate==<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
==3.11. Смарттерейны и гулаги.==<br />
==3.11.1. Смарттеррейн.==<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
==3.11.1.1. Стандартные типы смарттеррейнов.==<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
==3.11.3. Новые особенности смарттеррейнов==<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
==3.12.1. Схема heli_move:==<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
==3.12.2. Универсальная боевая схема:==<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
==3.14. Отметки на минимапе==<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
==3.15. Передача параметров в функции.==<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
===[[Настройка логики #2]]===<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T20:19:18Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by GSC GameWorld'''<br />
<br />
3. Настройки логики<br />
3.1. Система флагов path_walk, path_look<br />
3.1.1. Более подробное описание путей.<br />
3.2. Схемы поведения сталкеров<br />
3.2.1. Walker<br />
3.2.2. Remark<br />
3.2.3. Sleeper<br />
3.2.4. Kamp<br />
3.2.5. Camper<br />
3.2.5.1. Sniper<br />
3.2.6. Follower (Отключен)<br />
3.2.7. Zoneguard<br />
3.2.8. Wounded<br />
3.2.9. Rest<br />
3.2.10. Схема heli_hunter<br />
3.2.11. Patrol<br />
3.3. Секции<br />
3.3.1. Combat<br />
3.3.2. Death<br />
3.3.3. Hit<br />
3.3.4. Actors_dialog<br />
3.3.5. Use<br />
3.3.6. Combat_ignore<br />
3.3.7. Секция dont_spawn_character_supplies<br />
3.3.8. Секция no_smart<br />
3.3.9. Treshhold<br />
3.3.10. Danger<br />
3.3.11. Истории у костров <br />
3.4. Оверрайды<br />
3.5. Схемы поведения для монстров<br />
3.5.1. Mob_walker<br />
3.5.2. Mob_eluder<br />
3.5.3. Mob_remark<br />
3.5.4. Mob_combat<br />
3.5.5. Mob_death<br />
3.5.6. Mob_jump<br />
3.5.7. Mob_camp<br />
3.5.8. Mob_home<br />
3.5.9. Mob_fake_death<br />
3.6. Оверрайды для монстров<br />
3.7. Секция спавнер<br />
3.7.1. Спавн дневных и ночных монстров<br />
3.8. Скрипт Logic<br />
3.8.1. Синтаксис logic-а<br />
3.8.2. Примеры достаточно сложной логики<br />
3.9. Схемы space_restictor<br />
3.9.1. Sr_idle<br />
3.9.2. Sr_no_weapon<br />
3.9.3. Sr_sound<br />
3.9.4. Sr_tip<br />
3.9.5. Sr_light<br />
3.9.6. Sr_territory<br />
3.9.7. Sr_mapspot<br />
3.9.8. Sr_particle<br />
3.9.9. Sr_sound_act<br />
3.9.10. Sr_timer<br />
3.9.11. Sr_psy_antenna<br />
3.9.12. Sr_teleport<br />
3.9.13. Sr_sleep и настройка снов<br />
3.9.14. Sr_cutscene<br />
3.10. Дополнительные настройки логики у разных объектов<br />
3.10.1. Ph_door<br />
3.10.2. Ph_button<br />
3.10.3. Работа прожектора<br />
3.10.4. Ph_code<br />
3.10.5. Ph_gate<br />
3.10.6. Ph_sound<br />
3.10.7. Ph_force<br />
3.10.8. Ph_on_death<br />
3.10.9. Ph_car<br />
3.10.10. Ph_heavy<br />
3.10.11. Ph_oscillate<br />
3.11. Смарттерейны и гулаги<br />
3.11.1. Смарттеррейны<br />
3.11.1.1 Стандартный набор смарттеррейнов<br />
3.11.2. Гулаги.<br />
3.11.3. Новые особенности смарттерейнов.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
3.12. Логика вертолета<br />
3.12.1. Схема heli_move<br />
3.12.2. Универсальная боевая схема<br />
3.13. Meet_manager<br />
3.14. Отметки на минимапе<br />
3.15. Передача параметров в функции.<br />
3.16. Настройка звуковых групп.<br />
<br />
==3.1. Система флагов (path_walk, path_look)==<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
==3.1.1. Более подробное описание путей. ==<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
==3.2. Схемы поведения сталкеров.==<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
==3.2.2. Схема remark==<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
==3.2.4. Схема kamp==<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
<br />
==3.2.5. Схема camper==<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
<br />
==3.2.5.1. Схема sniper==<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
==3.2.6. Схема follower== <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
==3.2.7. Схема zoneguard==<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
==3.2.8. Схема wounded (раненый)==<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
==3.2.9. Схема rest==<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
==3.2.10. Схема heli_hunter==<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
==3.2.11. Patrol==<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
==3.3. Секции.==<br />
==3.3.1. Секция combat==<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
==3.3.2 Секция death==<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
==3.3.3. Cекция hit==<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
==3.3.4. Секция actor_dialogs==<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
==3.3.5. Секция use==<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
==3.3.6. Секция combat_ignore==<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
==3.3.7. Секция dont_spawn_character_supplies==<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
==3.3.8. Секция no_smart==<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
==3.3.9. Секция treshhold==<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
==3.3.10. Danger==<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
==3.3.11. Байки из склепа (Истории у костра)==<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
==3.3.12. dont_spawn_loot==<br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
==3.4. Оверрайды:==<br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
==3.5. Схемы для монстров==<br />
<br />
==3.5.1. Схема mob_walker.==<br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
==3.5.2. Схема mob_eluder==<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
==3.5.3. Схема mob_remark==<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
==3.5.4. Схема mob_combat, mob_death==<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
<br />
==3.5.6 Схема mob_jump (монстр-пружинка)==<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
<br />
==3.5.7. Mob_camp==<br />
<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
==3.5.8. Mob_home==<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
==3.5.9. Mob_fake_death==<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
==3.6. Оверрайды для монстров:==<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
<br />
==3.7. Секция spawner==<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
==3.7.1. Спавн монстров дневных и ночных.==<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
==3.8. Скрипт logic==<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
<br />
==3.8.1. Синтаксис скрипта Logic==<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
<br />
==3.8.2. Вот пример достаточно сложной логики:== <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
==3.9. Схемы логики space_restrictor==<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
<br />
==3.9.1. Схема [sr_idle]== <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
<br />
==3.9.2. Секция [sr_no_weapon]==<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
==3.9.3. Секция [sr_sound]==<br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
==3.9.4. Секция [sr_tip]==<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
==3.9.5. Sr_light==<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
<br />
==3.9.6. Sr_territory==<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
==3.9.7. Sr_mapspot==<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
==3.9.8. Sr_particle==<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
==3.9.9. Sr_sound_act==<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
==3.9.10 Sr_timer==<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
==3.9.11. Sr_psy_antenna==<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
==3.9.12. Sr_teleport==<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
==3.9.13. Sr_sleep и настройка снов.==<br />
<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
==3.9.14. Sr_cutscene==<br />
<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
==3.10. Набор дополнительных настроек логики у разных объектов.==<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
==3.10.1. Схема работы двери, секция [ph_door]==<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
==3.10.2. Схема работы кнопки, секция [ph_button]==<br />
<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
<br />
==3.10.3. Схема работы прожектора:==<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
==3.10.4. Кодовые замки:==<br />
<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
==3.10.5. Ph_gate:==<br />
<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
==3.10.6. Ph_sound==<br />
<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
==3.10.7. Ph_force==<br />
<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
==3.10.8. Ph_on_death==<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
==3.10.9. Ph_car==<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
==3.10.10. Ph_heavy==<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
==3.10.11. Ph_oscillate==<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
==3.11. Смарттерейны и гулаги.==<br />
==3.11.1. Смарттеррейн.==<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
==3.11.1.1. Стандартные типы смарттеррейнов.==<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
==3.11.3. Новые особенности смарттеррейнов==<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
==3.12.1. Схема heli_move:==<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
==3.12.2. Универсальная боевая схема:==<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
==3.14. Отметки на минимапе==<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
==3.15. Передача параметров в функции.==<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T20:07:21Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by GSC GameWorld'''<br />
<br />
3. Настройки логики<br />
3.1. Система флагов path_walk, path_look<br />
3.1.1. Более подробное описание путей.<br />
3.2. Схемы поведения сталкеров<br />
3.2.1. Walker<br />
3.2.2. Remark<br />
3.2.3. Sleeper<br />
3.2.4. Kamp<br />
3.2.5. Camper<br />
3.2.5.1. Sniper<br />
3.2.6. Follower (Отключен)<br />
3.2.7. Zoneguard<br />
3.2.8. Wounded<br />
3.2.9. Rest<br />
3.2.10. Схема heli_hunter<br />
3.2.11. Patrol<br />
3.3. Секции<br />
3.3.1. Combat<br />
3.3.2. Death<br />
3.3.3. Hit<br />
3.3.4. Actors_dialog<br />
3.3.5. Use<br />
3.3.6. Combat_ignore<br />
3.3.7. Секция dont_spawn_character_supplies<br />
3.3.8. Секция no_smart<br />
3.3.9. Treshhold<br />
3.3.10. Danger<br />
3.3.11. Истории у костров <br />
3.4. Оверрайды<br />
3.5. Схемы поведения для монстров<br />
3.5.1. Mob_walker<br />
3.5.2. Mob_eluder<br />
3.5.3. Mob_remark<br />
3.5.4. Mob_combat<br />
3.5.5. Mob_death<br />
3.5.6. Mob_jump<br />
3.5.7. Mob_camp<br />
3.5.8. Mob_home<br />
3.5.9. Mob_fake_death<br />
3.6. Оверрайды для монстров<br />
3.7. Секция спавнер<br />
3.7.1. Спавн дневных и ночных монстров<br />
3.8. Скрипт Logic<br />
3.8.1. Синтаксис logic-а<br />
3.8.2. Примеры достаточно сложной логики<br />
3.9. Схемы space_restictor<br />
3.9.1. Sr_idle<br />
3.9.2. Sr_no_weapon<br />
3.9.3. Sr_sound<br />
3.9.4. Sr_tip<br />
3.9.5. Sr_light<br />
3.9.6. Sr_territory<br />
3.9.7. Sr_mapspot<br />
3.9.8. Sr_particle<br />
3.9.9. Sr_sound_act<br />
3.9.10. Sr_timer<br />
3.9.11. Sr_psy_antenna<br />
3.9.12. Sr_teleport<br />
3.9.13. Sr_sleep и настройка снов<br />
3.9.14. Sr_cutscene<br />
3.10. Дополнительные настройки логики у разных объектов<br />
3.10.1. Ph_door<br />
3.10.2. Ph_button<br />
3.10.3. Работа прожектора<br />
3.10.4. Ph_code<br />
3.10.5. Ph_gate<br />
3.10.6. Ph_sound<br />
3.10.7. Ph_force<br />
3.10.8. Ph_on_death<br />
3.10.9. Ph_car<br />
3.10.10. Ph_heavy<br />
3.10.11. Ph_oscillate<br />
3.11. Смарттерейны и гулаги<br />
3.11.1. Смарттеррейны<br />
3.11.1.1 Стандартный набор смарттеррейнов<br />
3.11.2. Гулаги.<br />
3.11.3. Новые особенности смарттерейнов.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
3.12. Логика вертолета<br />
3.12.1. Схема heli_move<br />
3.12.2. Универсальная боевая схема<br />
3.13. Meet_manager<br />
3.14. Отметки на минимапе<br />
3.15. Передача параметров в функции.<br />
3.16. Настройка звуковых групп.<br />
<br />
==3.1. Система флагов (path_walk, path_look)==<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
==3.1.1. Более подробное описание путей. ==<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
==3.2. Схемы поведения сталкеров.==<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
==3.2.2. Схема remark==<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
==3.2.4. Схема kamp==<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
<br />
==3.2.5. Схема camper==<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
<br />
==3.2.5.1. Схема sniper==<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
==3.2.6. Схема follower== <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
==3.2.7. Схема zoneguard==<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
==3.2.8. Схема wounded (раненый)==<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
==3.2.9. Схема rest==<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
==3.2.10. Схема heli_hunter==<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
==3.2.11. Patrol==<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
==3.3. Секции.==<br />
==3.3.1. Секция combat==<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
3.3.2 Секция death<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
3.3.3. Cекция hit<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
3.3.4. Секция actor_dialogs<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
3.3.5. Секция use<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
3.3.6. Секция combat_ignore<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
3.3.7. Секция dont_spawn_character_supplies<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
3.3.8. Секция no_smart<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
3.3.9. Секция treshhold<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
3.3.10. Danger<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
3.3.11. Байки из склепа (Истории у костра)<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
3.3.12. dont_spawn_loot <br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
3.4. Оверрайды: <br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
3.5. Схемы для монстров<br />
<br />
3.5.1. Схема mob_walker. <br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
3.5.2. Схема mob_eluder<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
3.5.3. Схема mob_remark<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
3.5.4. Схема mob_combat, mob_death<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
3.5.6 Схема mob_jump (монстр-пружинка)<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
3.5.7. Mob_camp<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
3.5.8. Mob_home<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
3.5.9. Mob_fake_death<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
3.6. Оверрайды для монстров:<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
3.7. Секция spawner<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
3.7.1. Спавн монстров дневных и ночных.<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
3.8. Скрипт logic<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
3.8.1. Синтаксис скрипта Logic<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
3.8.2. Вот пример достаточно сложной логики: <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
3.9. Схемы логики space_restrictor<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
3.9.1. Схема [sr_idle] <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
3.9.2. Секция [sr_no_weapon]<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
3.9.3. Секция [sr_sound], <br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
3.9.4. Секция [sr_tip]<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
3.9.5. Sr_light<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
3.9.6. Sr_territory<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
3.9.7. Sr_mapspot<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
3.9.8. Sr_particle<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
3.9.9. Sr_sound_act<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
3.9.10 Sr_timer<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
3.9.11. Sr_psy_antenna<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
3.9.12. Sr_teleport<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
3.9.13. Sr_sleep и настройка снов.<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
3.9.14. Sr_cutscene<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
3.10. Набор дополнительных настроек логики у разных объектов.<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
3.10.1. Схема работы двери, секция [ph_door]<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
3.10.2. Схема работы кнопки, секция [ph_button]<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
<br />
3.10.3. Схема работы прожектора:<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
3.10.4. Кодовые замки:<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
3.10.5. Ph_gate:<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
3.10.6. Ph_sound<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
3.10.7. Ph_force<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
3.10.8. Ph_on_death<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
3.10.9. Ph_car<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
3.10.10. Ph_heavy<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
3.10.11. Ph_oscillate<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
3.11. Смарттерейны и гулаги.<br />
3.11.1. Смарттеррейн.<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
3.11.1.1. Стандартные типы смарттеррейнов.<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
3.11.3. Новые особенности смарттеррейнов<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
3.12.1. Схема heli_move:<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
3.12.2. Универсальная боевая схема:<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
<br />
<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
3.14. Отметки на минимапе<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
3.15. Передача параметров в функции.<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T20:06:02Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by GSC GameWorld'''<br />
<br />
{| border="0" cellpadding="3" align="right" width="250" cellspacing="1" style="background:#5e5e5e;"<br />
|-<br />
! style="background:#ffffff;" align="left" | Содержание<br />
|-<br />
| style="background:#ffffff;" align="left"|<br />
{{Шаблон:Содержание руководства по настройке}}<br />
|-<br />
|}<br />
<br />
<br />
3. Настройки логики<br />
3.1. Система флагов path_walk, path_look<br />
3.1.1. Более подробное описание путей.<br />
3.2. Схемы поведения сталкеров<br />
3.2.1. Walker<br />
3.2.2. Remark<br />
3.2.3. Sleeper<br />
3.2.4. Kamp<br />
3.2.5. Camper<br />
3.2.5.1. Sniper<br />
3.2.6. Follower (Отключен)<br />
3.2.7. Zoneguard<br />
3.2.8. Wounded<br />
3.2.9. Rest<br />
3.2.10. Схема heli_hunter<br />
3.2.11. Patrol<br />
3.3. Секции<br />
3.3.1. Combat<br />
3.3.2. Death<br />
3.3.3. Hit<br />
3.3.4. Actors_dialog<br />
3.3.5. Use<br />
3.3.6. Combat_ignore<br />
3.3.7. Секция dont_spawn_character_supplies<br />
3.3.8. Секция no_smart<br />
3.3.9. Treshhold<br />
3.3.10. Danger<br />
3.3.11. Истории у костров <br />
3.4. Оверрайды<br />
3.5. Схемы поведения для монстров<br />
3.5.1. Mob_walker<br />
3.5.2. Mob_eluder<br />
3.5.3. Mob_remark<br />
3.5.4. Mob_combat<br />
3.5.5. Mob_death<br />
3.5.6. Mob_jump<br />
3.5.7. Mob_camp<br />
3.5.8. Mob_home<br />
3.5.9. Mob_fake_death<br />
3.6. Оверрайды для монстров<br />
3.7. Секция спавнер<br />
3.7.1. Спавн дневных и ночных монстров<br />
3.8. Скрипт Logic<br />
3.8.1. Синтаксис logic-а<br />
3.8.2. Примеры достаточно сложной логики<br />
3.9. Схемы space_restictor<br />
3.9.1. Sr_idle<br />
3.9.2. Sr_no_weapon<br />
3.9.3. Sr_sound<br />
3.9.4. Sr_tip<br />
3.9.5. Sr_light<br />
3.9.6. Sr_territory<br />
3.9.7. Sr_mapspot<br />
3.9.8. Sr_particle<br />
3.9.9. Sr_sound_act<br />
3.9.10. Sr_timer<br />
3.9.11. Sr_psy_antenna<br />
3.9.12. Sr_teleport<br />
3.9.13. Sr_sleep и настройка снов<br />
3.9.14. Sr_cutscene<br />
3.10. Дополнительные настройки логики у разных объектов<br />
3.10.1. Ph_door<br />
3.10.2. Ph_button<br />
3.10.3. Работа прожектора<br />
3.10.4. Ph_code<br />
3.10.5. Ph_gate<br />
3.10.6. Ph_sound<br />
3.10.7. Ph_force<br />
3.10.8. Ph_on_death<br />
3.10.9. Ph_car<br />
3.10.10. Ph_heavy<br />
3.10.11. Ph_oscillate<br />
3.11. Смарттерейны и гулаги<br />
3.11.1. Смарттеррейны<br />
3.11.1.1 Стандартный набор смарттеррейнов<br />
3.11.2. Гулаги.<br />
3.11.3. Новые особенности смарттерейнов.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
3.12. Логика вертолета<br />
3.12.1. Схема heli_move<br />
3.12.2. Универсальная боевая схема<br />
3.13. Meet_manager<br />
3.14. Отметки на минимапе<br />
3.15. Передача параметров в функции.<br />
3.16. Настройка звуковых групп.<br />
<br />
==3.1. Система флагов (path_walk, path_look)==<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
==3.1.1. Более подробное описание путей. ==<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
==3.2. Схемы поведения сталкеров.==<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
==3.2.2. Схема remark==<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
==3.2.4. Схема kamp==<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
<br />
==3.2.5. Схема camper==<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
<br />
==3.2.5.1. Схема sniper==<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
==3.2.6. Схема follower== <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
==3.2.7. Схема zoneguard==<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
==3.2.8. Схема wounded (раненый)==<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
==3.2.9. Схема rest==<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
==3.2.10. Схема heli_hunter==<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
==3.2.11. Patrol==<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
==3.3. Секции.==<br />
==3.3.1. Секция combat==<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
3.3.2 Секция death<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
3.3.3. Cекция hit<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
3.3.4. Секция actor_dialogs<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
3.3.5. Секция use<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
3.3.6. Секция combat_ignore<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
3.3.7. Секция dont_spawn_character_supplies<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
3.3.8. Секция no_smart<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
3.3.9. Секция treshhold<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
3.3.10. Danger<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
3.3.11. Байки из склепа (Истории у костра)<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
3.3.12. dont_spawn_loot <br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
3.4. Оверрайды: <br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
3.5. Схемы для монстров<br />
<br />
3.5.1. Схема mob_walker. <br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
3.5.2. Схема mob_eluder<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
3.5.3. Схема mob_remark<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
3.5.4. Схема mob_combat, mob_death<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
3.5.6 Схема mob_jump (монстр-пружинка)<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
3.5.7. Mob_camp<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
3.5.8. Mob_home<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
3.5.9. Mob_fake_death<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
3.6. Оверрайды для монстров:<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
3.7. Секция spawner<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
3.7.1. Спавн монстров дневных и ночных.<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
3.8. Скрипт logic<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
3.8.1. Синтаксис скрипта Logic<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
3.8.2. Вот пример достаточно сложной логики: <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
3.9. Схемы логики space_restrictor<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
3.9.1. Схема [sr_idle] <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
3.9.2. Секция [sr_no_weapon]<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
3.9.3. Секция [sr_sound], <br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
3.9.4. Секция [sr_tip]<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
3.9.5. Sr_light<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
3.9.6. Sr_territory<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
3.9.7. Sr_mapspot<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
3.9.8. Sr_particle<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
3.9.9. Sr_sound_act<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
3.9.10 Sr_timer<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
3.9.11. Sr_psy_antenna<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
3.9.12. Sr_teleport<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
3.9.13. Sr_sleep и настройка снов.<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
3.9.14. Sr_cutscene<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
3.10. Набор дополнительных настроек логики у разных объектов.<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
3.10.1. Схема работы двери, секция [ph_door]<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
3.10.2. Схема работы кнопки, секция [ph_button]<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
<br />
3.10.3. Схема работы прожектора:<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
3.10.4. Кодовые замки:<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
3.10.5. Ph_gate:<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
3.10.6. Ph_sound<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
3.10.7. Ph_force<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
3.10.8. Ph_on_death<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
3.10.9. Ph_car<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
3.10.10. Ph_heavy<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
3.10.11. Ph_oscillate<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
3.11. Смарттерейны и гулаги.<br />
3.11.1. Смарттеррейн.<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
3.11.1.1. Стандартные типы смарттеррейнов.<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
3.11.3. Новые особенности смарттеррейнов<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
3.12.1. Схема heli_move:<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
3.12.2. Универсальная боевая схема:<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
<br />
<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
3.14. Отметки на минимапе<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
3.15. Передача параметров в функции.<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T19:55:34Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by GSC GameWorld'''<br />
<br />
<br />
3. Настройки логики<br />
3.1. Система флагов path_walk, path_look<br />
3.1.1. Более подробное описание путей.<br />
3.2. Схемы поведения сталкеров<br />
3.2.1. Walker<br />
3.2.2. Remark<br />
3.2.3. Sleeper<br />
3.2.4. Kamp<br />
3.2.5. Camper<br />
3.2.5.1. Sniper<br />
3.2.6. Follower (Отключен)<br />
3.2.7. Zoneguard<br />
3.2.8. Wounded<br />
3.2.9. Rest<br />
3.2.10. Схема heli_hunter<br />
3.2.11. Patrol<br />
3.3. Секции<br />
3.3.1. Combat<br />
3.3.2. Death<br />
3.3.3. Hit<br />
3.3.4. Actors_dialog<br />
3.3.5. Use<br />
3.3.6. Combat_ignore<br />
3.3.7. Секция dont_spawn_character_supplies<br />
3.3.8. Секция no_smart<br />
3.3.9. Treshhold<br />
3.3.10. Danger<br />
3.3.11. Истории у костров <br />
3.4. Оверрайды<br />
3.5. Схемы поведения для монстров<br />
3.5.1. Mob_walker<br />
3.5.2. Mob_eluder<br />
3.5.3. Mob_remark<br />
3.5.4. Mob_combat<br />
3.5.5. Mob_death<br />
3.5.6. Mob_jump<br />
3.5.7. Mob_camp<br />
3.5.8. Mob_home<br />
3.5.9. Mob_fake_death<br />
3.6. Оверрайды для монстров<br />
3.7. Секция спавнер<br />
3.7.1. Спавн дневных и ночных монстров<br />
3.8. Скрипт Logic<br />
3.8.1. Синтаксис logic-а<br />
3.8.2. Примеры достаточно сложной логики<br />
3.9. Схемы space_restictor<br />
3.9.1. Sr_idle<br />
3.9.2. Sr_no_weapon<br />
3.9.3. Sr_sound<br />
3.9.4. Sr_tip<br />
3.9.5. Sr_light<br />
3.9.6. Sr_territory<br />
3.9.7. Sr_mapspot<br />
3.9.8. Sr_particle<br />
3.9.9. Sr_sound_act<br />
3.9.10. Sr_timer<br />
3.9.11. Sr_psy_antenna<br />
3.9.12. Sr_teleport<br />
3.9.13. Sr_sleep и настройка снов<br />
3.9.14. Sr_cutscene<br />
3.10. Дополнительные настройки логики у разных объектов<br />
3.10.1. Ph_door<br />
3.10.2. Ph_button<br />
3.10.3. Работа прожектора<br />
3.10.4. Ph_code<br />
3.10.5. Ph_gate<br />
3.10.6. Ph_sound<br />
3.10.7. Ph_force<br />
3.10.8. Ph_on_death<br />
3.10.9. Ph_car<br />
3.10.10. Ph_heavy<br />
3.10.11. Ph_oscillate<br />
3.11. Смарттерейны и гулаги<br />
3.11.1. Смарттеррейны<br />
3.11.1.1 Стандартный набор смарттеррейнов<br />
3.11.2. Гулаги.<br />
3.11.3. Новые особенности смарттерейнов.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
3.12. Логика вертолета<br />
3.12.1. Схема heli_move<br />
3.12.2. Универсальная боевая схема<br />
3.13. Meet_manager<br />
3.14. Отметки на минимапе<br />
3.15. Передача параметров в функции.<br />
3.16. Настройка звуковых групп.<br />
<br />
3.1. Система флагов (path_walk, path_look)<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
3.1.1. Более подробное описание путей.<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
3.2. Схемы поведения сталкеров.<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
3.2.2. Схема remark<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
3.2.4. Схема kamp<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
3.2.5. Схема camper<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
3.2.5.1. Схема sniper<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
3.2.6. Схема follower <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
3.2.7. Схема zoneguard<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
3.2.8. Схема wounded (раненый)<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
3.2.9. Схема rest<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
3.2.10. Схема heli_hunter<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
3.2.11. Patrol<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
3.3. Секции.<br />
3.3.1. Секция combat<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
3.3.2 Секция death<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
3.3.3. Cекция hit<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
3.3.4. Секция actor_dialogs<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
3.3.5. Секция use<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
3.3.6. Секция combat_ignore<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
3.3.7. Секция dont_spawn_character_supplies<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
3.3.8. Секция no_smart<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
3.3.9. Секция treshhold<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
3.3.10. Danger<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
3.3.11. Байки из склепа (Истории у костра)<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
3.3.12. dont_spawn_loot <br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
3.4. Оверрайды: <br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
3.5. Схемы для монстров<br />
<br />
3.5.1. Схема mob_walker. <br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
3.5.2. Схема mob_eluder<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
3.5.3. Схема mob_remark<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
3.5.4. Схема mob_combat, mob_death<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
3.5.6 Схема mob_jump (монстр-пружинка)<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
3.5.7. Mob_camp<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
3.5.8. Mob_home<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
3.5.9. Mob_fake_death<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
3.6. Оверрайды для монстров:<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
3.7. Секция spawner<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
3.7.1. Спавн монстров дневных и ночных.<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
3.8. Скрипт logic<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
3.8.1. Синтаксис скрипта Logic<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
3.8.2. Вот пример достаточно сложной логики: <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
3.9. Схемы логики space_restrictor<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
3.9.1. Схема [sr_idle] <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
3.9.2. Секция [sr_no_weapon]<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
3.9.3. Секция [sr_sound], <br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
3.9.4. Секция [sr_tip]<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
3.9.5. Sr_light<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
3.9.6. Sr_territory<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
3.9.7. Sr_mapspot<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
3.9.8. Sr_particle<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
3.9.9. Sr_sound_act<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
3.9.10 Sr_timer<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
3.9.11. Sr_psy_antenna<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
3.9.12. Sr_teleport<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
3.9.13. Sr_sleep и настройка снов.<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
3.9.14. Sr_cutscene<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
3.10. Набор дополнительных настроек логики у разных объектов.<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
3.10.1. Схема работы двери, секция [ph_door]<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
3.10.2. Схема работы кнопки, секция [ph_button]<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
<br />
3.10.3. Схема работы прожектора:<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
3.10.4. Кодовые замки:<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
3.10.5. Ph_gate:<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
3.10.6. Ph_sound<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
3.10.7. Ph_force<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
3.10.8. Ph_on_death<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
3.10.9. Ph_car<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
3.10.10. Ph_heavy<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
3.10.11. Ph_oscillate<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
3.11. Смарттерейны и гулаги.<br />
3.11.1. Смарттеррейн.<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
3.11.1.1. Стандартные типы смарттеррейнов.<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
3.11.3. Новые особенности смарттеррейнов<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
3.12.1. Схема heli_move:<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
3.12.2. Универсальная боевая схема:<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
<br />
<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
3.14. Отметки на минимапе<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
3.15. Передача параметров в функции.<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8._%D0%A7%D0%B0%D1%81%D1%82%D1%8C_1Настройка логики. Часть 12007-08-14T19:54:02Z<p>78.106.25.142: </p>
<hr />
<div>3. Настройки логики<br />
3.1. Система флагов path_walk, path_look<br />
3.1.1. Более подробное описание путей.<br />
3.2. Схемы поведения сталкеров<br />
3.2.1. Walker<br />
3.2.2. Remark<br />
3.2.3. Sleeper<br />
3.2.4. Kamp<br />
3.2.5. Camper<br />
3.2.5.1. Sniper<br />
3.2.6. Follower (Отключен)<br />
3.2.7. Zoneguard<br />
3.2.8. Wounded<br />
3.2.9. Rest<br />
3.2.10. Схема heli_hunter<br />
3.2.11. Patrol<br />
3.3. Секции<br />
3.3.1. Combat<br />
3.3.2. Death<br />
3.3.3. Hit<br />
3.3.4. Actors_dialog<br />
3.3.5. Use<br />
3.3.6. Combat_ignore<br />
3.3.7. Секция dont_spawn_character_supplies<br />
3.3.8. Секция no_smart<br />
3.3.9. Treshhold<br />
3.3.10. Danger<br />
3.3.11. Истории у костров <br />
3.4. Оверрайды<br />
3.5. Схемы поведения для монстров<br />
3.5.1. Mob_walker<br />
3.5.2. Mob_eluder<br />
3.5.3. Mob_remark<br />
3.5.4. Mob_combat<br />
3.5.5. Mob_death<br />
3.5.6. Mob_jump<br />
3.5.7. Mob_camp<br />
3.5.8. Mob_home<br />
3.5.9. Mob_fake_death<br />
3.6. Оверрайды для монстров<br />
3.7. Секция спавнер<br />
3.7.1. Спавн дневных и ночных монстров<br />
3.8. Скрипт Logic<br />
3.8.1. Синтаксис logic-а<br />
3.8.2. Примеры достаточно сложной логики<br />
3.9. Схемы space_restictor<br />
3.9.1. Sr_idle<br />
3.9.2. Sr_no_weapon<br />
3.9.3. Sr_sound<br />
3.9.4. Sr_tip<br />
3.9.5. Sr_light<br />
3.9.6. Sr_territory<br />
3.9.7. Sr_mapspot<br />
3.9.8. Sr_particle<br />
3.9.9. Sr_sound_act<br />
3.9.10. Sr_timer<br />
3.9.11. Sr_psy_antenna<br />
3.9.12. Sr_teleport<br />
3.9.13. Sr_sleep и настройка снов<br />
3.9.14. Sr_cutscene<br />
3.10. Дополнительные настройки логики у разных объектов<br />
3.10.1. Ph_door<br />
3.10.2. Ph_button<br />
3.10.3. Работа прожектора<br />
3.10.4. Ph_code<br />
3.10.5. Ph_gate<br />
3.10.6. Ph_sound<br />
3.10.7. Ph_force<br />
3.10.8. Ph_on_death<br />
3.10.9. Ph_car<br />
3.10.10. Ph_heavy<br />
3.10.11. Ph_oscillate<br />
3.11. Смарттерейны и гулаги<br />
3.11.1. Смарттеррейны<br />
3.11.1.1 Стандартный набор смарттеррейнов<br />
3.11.2. Гулаги.<br />
3.11.3. Новые особенности смарттерейнов.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
3.12. Логика вертолета<br />
3.12.1. Схема heli_move<br />
3.12.2. Универсальная боевая схема<br />
3.13. Meet_manager<br />
3.14. Отметки на минимапе<br />
3.15. Передача параметров в функции.<br />
3.16. Настройка звуковых групп.<br />
<br />
3.1. Система флагов (path_walk, path_look)<br />
В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00":<br />
wp00|flag1|flag2<br />
Флаги точек пути path_walk:<br />
a=state<br />
Выбирает состояние тела при перемещении (Только из раздела –Ходячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
p=percent<br />
Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br />
sig=name<br />
Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look. <br />
Флаги точек пути path_look:<br />
a =state<br />
Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния)<br />
Список состояний можно взять в gamedata\scripts\state_lib.script<br />
t=msec<br />
- время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br />
‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br />
Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.<br />
sig=name<br />
После поворота в точку path_look, установить сигнал с именем name.<br />
syn<br />
Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.<br />
sigtm=signal<br />
Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку. <br />
В пути path_look можно сделать: wp00|a=press|t=0|sigtm=pressed <br />
А затем переключить схему: on_signal = pressed | другая_схема<br />
<br />
<br />
<br />
3.1.1. Более подробное описание путей.<br />
<br />
Walker.<br />
<br />
Настройка:<br />
<br />
<br />
На карту для каждого walker-а нужно поставить:<br />
1) Путь path_walk, по которому walker ходит.<br />
2) Путь path_look, состоящий из точек, в которые walker смотрит.<br />
<br />
Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br />
<br />
[walker]<br />
team = …<br />
имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.<br />
path_walk = …<br />
имя пути, описанного в п. 1<br />
path_look = …<br />
(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.<br />
Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look<br />
<br />
Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br />
<br />
Пример 1:<br />
<br />
Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br />
<br />
<br />
Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.<br />
У каждого вейпоинта есть имя: wp00, wp01 и т.д.<br />
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!<br />
<br />
Пример 2:<br />
<br />
<br />
<br />
Разговор персонажа.<br />
<br />
Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br />
s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.<br />
<br />
<br />
Пример 3:<br />
<br />
<br />
В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.<br />
Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.<br />
Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.<br />
Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.<br />
<br />
Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br />
<br />
Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br />
<br />
Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.<br />
<br />
Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.<br />
<br />
Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.<br />
<br />
По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:<br />
<br />
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).<br />
Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.<br />
По умолчанию у всех точек p = 100.<br />
<br />
t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br />
<br />
Пример 5:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.<br />
<br />
По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.<br />
<br />
Если требуется другая анимация, можно ее указать с помощью флажка:<br />
<br />
a = имя_анимации (по умолчанию idle). <br />
Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д. <br />
<br />
NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!<br />
<br />
<br />
3.2. Схемы поведения сталкеров.<br />
Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br />
В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.<br />
3.2.1. Схема walker<br />
Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия. <br />
<br />
[walker]<br />
path_walk = <имя пути>- основной путь, по которому ходит NPC<br />
*path_look = <имя пути>- путь, куда смотрит NPC<br />
*team - команда для синхронизации<br />
<br />
В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br />
* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)<br />
* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)<br />
* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)<br />
* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br />
<br />
<br />
Файл: \gamedata\scripts\xr_walker.script<br />
3.2.2. Схема remark<br />
Схема используется для синхронизации\связки других схем.<br />
<br />
[remark]<br />
*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет<br />
*snd = звук ремарка, по умолчанию nil<br />
*anim = анимация ремарка, по умолчанию wait<br />
*target = Куда смотрит сталкер. Есть следующие варианты<br />
story_id – числовое значение<br />
actor – без комментариев<br />
nil – позиция вычисленная АИ автоматически<br />
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).<br />
Пример:<br />
target = logic@cit_killers_base_guard, cit_killers<br />
<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).<br />
<br />
Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.<br />
<br />
<br />
Стандартные сигналы для remark: <br />
sound_end – по окончании проигрывания звуковой схемы<br />
anim_end – по окончании проигрывания анимации<br />
action_end – по окончании проигрывания и того и другого, если они синхронизированы<br />
<br />
Пример синхронизации анимации и звука в схеме Remark:<br />
[remark]<br />
anim = анимация<br />
snd = звук<br />
snd_anim_sync = true<br />
on_signal = action_end | следующая схема<br />
3.2.3. Схема sleeper<br />
Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки. <br />
<br />
[sleeper]<br />
path_main = <имя пути><br />
*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)<br />
<br />
NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br />
<br />
Файл: \gamedata\scripts\xr_sleeper.script<br />
<br />
3.2.4. Схема kamp<br />
Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br />
<br />
[kamp]<br />
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.<br />
*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)<br />
*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)<br />
<br />
Файл: \gamedata\scripts\xr_kamp.script<br />
<br />
NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task<br />
<br />
*path_walk = <path_kamp_name>_task<br />
<br />
Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.<br />
3.2.5. Схема camper<br />
Свойства кемперов:<br />
- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям <br />
- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера. <br />
- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага. <br />
- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br />
<br />
[camper]<br />
path_walk = patrol_path<br />
path_look = patrol_path<br />
*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.<br />
*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br />
*def_state_moving = состояние из стейт менеджера<br />
Состояние, в котором мы движемся на ближайшую точку пути при враге<br />
*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)<br />
Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.<br />
*def_state_campering = состояние из стейт менеджера (hide)<br />
Состояние, в котором мы ожидаем врага, находясь на пути<br />
*def_state_campering_fire = состояние из стейт менеджера (hide_fire)<br />
Состояние, в котором мы отстреливаемся от врага, находясь на пути<br />
*attack_sound = имя_звуковой_темы<br />
Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =<br />
*shoot = тип.<br />
Задаем тип стрельбы. Возможные значения - always|none|terminal<br />
always - значение по умолчанию, стреляет всегда, когда можно<br />
none - не стреляет вообще.<br />
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br />
<br />
NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.<br />
Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.<br />
3.2.5.1. Схема sniper<br />
Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.<br />
NB! Ставить снайперу только 2 точки look<br />
<br />
В кастом дате кемпера прописать:<br />
sniper = true<br />
<br />
<br />
Файл: \gamedata\scripts\xr_camper.script<br />
<br />
3.2.6. Схема follower <br />
В custom_data прописан как follower<br />
NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.<br />
<br />
[follower]<br />
leader = story id лидера из game.ltx (число!)<br />
*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади<br />
*distance = расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br />
*state_if_leader_in_meet. Это есть строка с именем состояния из state_manager, которое будет назначено follower-ам, если командир пребывает в состоянии meet.<br />
*anim_walk = state (состояние, в котором фолловер идет за лидером)<br />
*anim_run = state (состояние, в котором фолловер бежит за лидером)<br />
*anim_sprint = state (состояние, в котором фолловер спринтует за лидером)<br />
Файл: \gamedata\scripts\xr_ attendant.script<br />
<br />
Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:<br />
<br />
t = { section = "logic@bar_arena_follower_2", <br />
idle = 0,<br />
prior = 7, state = {0}, squad = squad, group = groups[0],<br />
in_rest = "", out_rest = "",<br />
dependent = "logic@bar_arena_leader",<br />
predicate = function(obj)<br />
return obj:character_community() == "dolg"<br />
end<br />
}<br />
<br />
3.2.7. Схема zoneguard<br />
NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока <br />
<br />
[zoneguard]<br />
path_walk = путь перемещения<br />
*path_look = путь обзора<br />
team = имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)<br />
*zone_guard = имя зоны, в пределах которой игрок будет атакован<br />
zone_warn = имя зоны, в пределах которой начинать разговор с игроком<br />
*walker_team = team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)<br />
*no_move = если true, персонаж окликнет игрока с места и не будет подбегать к нему<br />
*snd_greet = имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа<br />
*ignore_friends = true, будет игнорировать дружественных ему персонажей.<br />
*ignore_cond = {+info -info =func !func} условия, при которых NPC игнорирует игрока<br />
*no_danger = если true, то не отыгрывает угрожающую анимацию, нейтралам.<br />
*anim = какую отыгрывает анимацию, если игрок ему не враждебен.<br />
*snd_anim_sync = если true, то npc будет синхронизировать звук с анимацией<br />
Файл: \gamedata\scripts\xr_zoneguard.script<br />
<br />
3.2.8. Схема wounded (раненый)<br />
<br />
[logic]<br />
wounded = wounded<br />
<br />
[walker]<br />
wounded = wounded<br />
<br />
[wounded]<br />
hp_state = HP|condstate@condsound|HP|condstate@condsound<br />
hp_state_see = HP|condstate@condsound|HP|condstate@condsound<br />
psy_state = PSY|condstate@condsound|PSY|condstate@condsound<br />
hp_victim = HP|condvictim|HP|condvictim<br />
hp_cover = HP|condbool|HP|condbool<br />
hp_fight = HP|condbool|HP|condbool<br />
*syndata = state@sound|state@sound<br />
*help_dialog = story_id <br />
*help_start_dialog = story_id<br />
<br />
Где:<br />
Condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока<br />
Condsound – кондлист, возвращающий саунд тему.<br />
HP – пороговые значение здоровья персонажа<br />
PSY – пороговые значения пси здоровья персонажа<br />
Condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.<br />
Condbool – кондлист, возвращаюзий true либо false.<br />
<br />
Значения полей:<br />
hp_state – поведение персонажа когда он не видит игрока<br />
hp_state_see – поведение персонажа, когда он видит игрока<br />
psy_state – поведение персонажа при псиатаках<br />
hp_victim – куда смотреть, в зависимости от ХП<br />
hp_cover – идти в укрытие или нет, в зависимости от ХП<br />
hp_fight – разрешено воевать или нет, в зависимости от ХП<br />
syndata – синхропары для красоты.<br />
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.<br />
Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.<br />
<br />
Пример. В качестве примера взята дефолтная настройка.<br />
<br />
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy<br />
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy<br />
psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20| {=best_pistol}psy_shoot,psy_pain@{=best_pistol}wounded_psy_shoot,wounded_psy<br />
hp_victim = 30|actor|10|nil<br />
hp_cover = 30|true|10|false<br />
hp_fight = 30|true|10|false<br />
syndata = wounded@help<br />
<br />
Где:<br />
Best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.<br />
<br />
Файл: \gamedata\scripts\xr_wounded.script<br />
<br />
3.2.9. Схема rest<br />
Чувак гуляет, хавает, спит.<br />
Пока нормально не работает.<br />
Файл: \gamedata\scripts\xr_rest.script<br />
<br />
3.2.10. Схема heli_hunter<br />
Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br />
<br />
[camper@bar_freedom_attack_sniper_1]<br />
path_walk = camper_1_walk<br />
path_look = camper_1_look<br />
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%<br />
meet_talk_enabled = true<br />
meet_dialog = bar_svoboda_dialog<br />
heli_hunter = {-bar_ecolog_crush_heli_down} true, false<br />
<br />
Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.<br />
<br />
3.2.11. Patrol<br />
Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:<br />
<br />
[patrol]<br />
path_walk = path_walk<br />
path_look = path_look<br />
*formation = back<br />
*commander = true (типа назначат командиром, желательно, чтобы такой красивый он был один)<br />
*move_type = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib<br />
<br />
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:<br />
back - мужики идут чуть позади командира в два ряда (по умолчанию)<br />
line - шеренга<br />
around - вокруг командира<br />
<br />
При остановке командора в meet мужики останавливаются.<br />
<br />
Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br />
ret=0...2<br />
0 - линия<br />
1 – вокруг старшего<br />
2 – по бокам<br />
<br />
При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a=assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br />
<br />
Что еще не сделано или глючит:<br />
- нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)<br />
- все идут молча (когда будет манагер баек, то сделаем)<br />
- командор пока не отдает команд (нет озвучки)<br />
- не рекомендуется включать спринт (глючит)<br />
<br />
3.3. Секции.<br />
3.3.1. Секция combat<br />
Показывает, что происходит, когда NPC срывается в бой.<br />
on_combat = combat<br />
<br />
[combat]<br />
on_info = %+info -info =func% эффекты, которые вызываются на каждом раунде боя.<br />
<br />
Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.<br />
<br />
В следующем примере сталкер сражается:<br />
* по-кемперски, если враг=актёр и он дальше Х метров<br />
* по-монолитовски, если любой враг дальше Y метров<br />
* иначе - движковый бой<br />
<br />
[logic]<br />
active = walker<br />
on_combat = combat<br />
<br />
[walker]<br />
path_walk = ...<br />
<br />
[combat]<br />
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith<br />
<br />
Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров npc переходил бы в кемперский комбат.<br />
function fighting_dist_ge_20(actor, npc)<br />
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400 <br />
end<br />
400 – это 202 . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.<br />
<br />
<br />
Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:<br />
<br />
[logic]<br />
active = nil<br />
on_combat = combat<br />
<br />
[combat]<br />
combat_type = zombied<br />
<br />
Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type.<br />
Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:<br />
<br />
[logic]<br />
active = walker1<br />
on_combat = combat<br />
<br />
[walker1]<br />
...<br />
[walker2]<br />
...<br />
[walker3]<br />
...<br />
[walker4]<br />
...<br />
[walker5]<br />
...<br />
combat_type = monolith<br />
<br />
[combat]<br />
combat_type = camper<br />
(scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)<br />
<br />
<br />
<br />
disable_combat_handler – функция отключающая секцию combat.<br />
Файл: \gamedata\scripts\xr_combat.script<br />
<br />
3.3.2 Секция death<br />
Схема показывает, что происходит при смерти NPC.<br />
on_death = death<br />
<br />
[death]<br />
on_info = %+info -info =func%<br />
Файл: \gamedata\scripts\xr_death.script<br />
<br />
3.3.3. Cекция hit<br />
Схема показывает, что происходит при, нанесении повреждения NPC. on_hit НЕ СРАБАТЫВАЕТ на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как аггрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).<br />
on_hit = hit<br />
<br />
[hit]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_hit.script<br />
<br />
<br />
<br />
3.3.4. Секция actor_dialogs<br />
Показывает, какие диалоги будут доступны или недоступны игроку при разговоре с этим NPC. Пишется практически в любой схеме.<br />
actor_dialogs = actor_dialogs<br />
<br />
[actor_dialogs]<br />
id = доступные диалоги через запятую.<br />
disable = запрещенные диалоги, тоже через запятую.<br />
Файл: \gamedata\scripts\xr_meet.script<br />
<br />
<br />
3.3.5. Секция use<br />
Схема показывает, что произойдет, если игрок юзнет NPC.<br />
<br />
on_use = use<br />
<br />
[use]<br />
on_info = %+info -info =func%<br />
<br />
Файл: \gamedata\scripts\xr_use.script<br />
<br />
<br />
3.3.6. Секция combat_ignore<br />
Если NPC в этой схеме то он, не переходит в боевой режим. В любой другой схеме:<br />
<br />
[walker]<br />
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).<br />
<br />
В схеме нет дополнительных полей<br />
[walker]<br />
combat_ignore = combat_ignore <br />
<br />
[combat_ignore]<br />
<br />
Функции, используемые для работы с кондлистом комбат игнора:<br />
fighting_dist_ge_20 -- текущий враг на расстоянии больше или равном 20м<br />
fighting_dist_ge(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
<br />
<br />
fighting_actor -- текущий враг актёр?<br />
check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка<br />
<br />
Файл: \gamedata\scripts\xr_combat_ignore.script<br />
<br />
3.3.7. Секция dont_spawn_character_supplies<br />
Если прописать эту секцию в кастом дату персонажу, то у него внутри не заспавниться стандартный набор барахла, прописанный в профиле.<br />
<br />
[dont_spawn_character_supplies]<br />
<br />
3.3.8. Секция no_smart<br />
Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам.<br />
[no_smart]<br />
<br />
<br />
3.3.9. Секция treshhold<br />
Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:<br />
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.<br />
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.<br />
<br />
В секции логики либо в текущей схеме указываете:<br />
<br />
threshold = threshold@tratata<br />
<br />
[threshold@tratata]<br />
max_ignore_distance = <number><br />
ignore_monster = <number><br />
<br />
Второй параметр следует менять ОЧЕНЬ осторожно.<br />
<br />
3.3.10. Danger<br />
<br />
Настройка может задаваться только в какой-то схеме, например:<br />
<br />
[walker]<br />
danger = danger_condition<br />
<br />
[danger_condition]<br />
ignore_distance = 50 (расстояние указывается в метрах)<br />
ignore_ distance_grenade = <br />
ignore_ distance_corpse = <br />
ignore_ distance_hit = <br />
ignore_ distance_sound = <br />
<br />
Можно также указывать время ожидания для денжера в зависимости от типа:<br />
<br />
danger_inertion_time_grenade = <br />
danger_inertion_time_corpse =<br />
danger_inertion_time_hit =<br />
danger_inertion_time_sound =<br />
<br />
Дефолтовые настройки:<br />
danger_inertion_time_grenade = 20000<br />
danger_inertion_time_corpse = 10000<br />
danger_inertion_time_hit = 60000<br />
danger_inertion_time_sound = 15000<br />
<br />
NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.<br />
<br />
Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.<br />
<br />
В данный момент установлены следующие дефолты:<br />
<br />
ignore_distance = 50<br />
ignore_distance_grenade = 15<br />
ignore_distance_corpse = 10<br />
ignore_distance_hit = 50<br />
ignore_distance_sound = 50<br />
<br />
NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.<br />
<br />
* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.<br />
* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.<br />
<br />
3.3.11. Байки из склепа (Истории у костра)<br />
Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.<br />
Делается это так: в кастом дате пишется секция:<br />
<br />
[game_info]<br />
stories = "story_01, legend_01"<br />
<br />
В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:<br />
<br />
story_01 - Граница зоны и граната за 1 действие.<br />
story_02 - Про трамплин и про камешки<br />
story_03 - Про то как группа Вильнова вернулась<br />
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.<br />
story_05 - Про то как духманам с контролером стражаться.<br />
story_06 - Про дверцу, водку и избушку.<br />
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.<br />
legend_02 - Об особо засекреченных лабораториях в зоне.<br />
legend_03 - Легенда о проводнике<br />
legend_04 - Легенда о темном сталкере<br />
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.<br />
<br />
О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.<br />
<br />
3.3.12. dont_spawn_loot <br />
Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию <br />
[dont_spawn_loot]<br />
<br />
3.4. Оверрайды: <br />
Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)<br />
*meet_enabled = true (запускает схему встречи)<br />
*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)<br />
*meet_dialog = <название диалога>, который будет запущен при юзе.<br />
*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли<br />
*wounded_enabled = true (включает NPC возможность использовать схему раненого)<br />
*combat_ignore_cond = см. выше<br />
*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)<br />
*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы<br />
*on_combat = см. выше<br />
*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).<br />
<br />
<br />
3.5. Схемы для монстров<br />
<br />
3.5.1. Схема mob_walker. <br />
Работает аналогично схеме обычного walker. Но есть некоторые отличия<br />
<br />
Флаги пути движения<br />
s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic <br />
Флаги пути обзора:<br />
t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) <br />
В customdata персонажа задайте (* отмечены обязательные поля): <br />
[walker]<br />
path_walk = путь перемещения<br />
path_look = путь обзора<br />
*no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.<br />
*actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.<br />
*npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).<br />
*friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.<br />
Файл: \gamedata\scripts\mob_walker.script<br />
<br />
У кровосососов можно управлять невидимостью:<br />
[mob_walker]<br />
...<br />
state = vis<br />
или<br />
state = invis<br />
Задает значение по умолчанию.<br />
<br />
Также в флагах walk пути mob_walker-а можно использовать флажок b<br />
(behaviour) с теми же параметрами:<br />
wp00|b=vis<br />
wp00|b=invis<br />
<br />
3.5.2. Схема mob_eluder<br />
Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.<br />
path = … работает как обычно path_walk. Набор точек патрульного пути.<br />
*Time_capture = …. (время в секундах) время, которое монстр находится под этой схемой. Default – 10.<br />
*Time_release = …. (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.<br />
*Min_dist = …. (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.<br />
*Max_dist = …. (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10<br />
Замечание – работает нестабильно.<br />
Файл: \gamedata\scripts\mob_eluder.script<br />
<br />
<br />
3.5.3. Схема mob_remark<br />
Ремарковая схема, только не для сталкеров, а для монстров.<br />
<br />
*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)<br />
*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога<br />
*anim = анимации монстра, перечисляются через запятую.<br />
*anim.head = анимации головы монстра, через запятую перечисляются<br />
*tip = какой значок подсветится, при наведении на него курсора<br />
*snd = какой звук издает<br />
*time = время проигрывания анимаций, используется только для отладки.<br />
Файл \gamedata\scripts\mob_remark.script<br />
На этой схеме сделан торговец. <br />
<br />
<br />
3.5.4. Схема mob_combat, mob_death<br />
Работают точно также как и у сталкеров соответствующие схемы.<br />
Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script<br />
3.5.6 Схема mob_jump (монстр-пружинка)<br />
Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.<br />
<br />
Пример:<br />
<br />
[logic]<br />
active = mob_jump<br />
<br />
[mob_jump]<br />
path_jump = path<br />
ph_jump_factor =2.8<br />
offset = 0,10,0<br />
on_signal = jumped | nil<br />
<br />
path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.<br />
offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). <br />
ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8<br />
<br />
Примечание:<br />
Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.<br />
При выборе позиции используется первая точка патрульного пути (0-вой индекс)<br />
3.5.7. Mob_camp<br />
Механика:<br />
1. Сидит на позиции, смотрит в точку <br />
2. Можно задать несколько позиций и время смены позиции.<br />
3. Перемещается между позициями бегом<br />
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)<br />
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции<br />
6. Если враг уходит далеко - монстр возвращается на позицию<br />
<br />
Использование:<br />
<br />
[logic]<br />
active = mob_camp<br />
<br />
[mob_camp]<br />
path_look = way_look<br />
path_home = way_home<br />
time_change_point = 30000<br />
home_min_radius = 20<br />
home_max_radius = 50<br />
skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)<br />
<br />
Описание параметров:<br />
*path_home - путь, состоящий из точек, в которых будет находиться монстр <br />
path_look - путь, состоящий из точек, в которые будет смотреть монстр <br />
*time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс<br />
* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м<br />
* home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м<br />
<br />
Особенности:<br />
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.<br />
Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.<br />
Выбор текущей позиции производится случайным образом<br />
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)<br />
<br />
Единственным необходимым параметром является path_look<br />
Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.<br />
<br />
Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.<br />
<br />
Обязательные требования:<br />
home_min_radius < home_max_radius<br />
Количество точек путей path_look и path_home должно быть равным<br />
P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами<br />
<br />
3.5.8. Mob_home<br />
Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать. <br />
<br />
Пример:<br />
[mob_home]<br />
path_home = path1<br />
home_min_radius = 10<br />
home_max_radius = 30<br />
aggressive_home - в назначенную точку path_home монстры бегут а не идут.<br />
<br />
Описание:<br />
Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».<br />
<br />
Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.<br />
<br />
3.5.9. Mob_fake_death<br />
<br />
Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби...<br />
Использование:<br />
<br />
[logic]<br />
active = mob_fake_death<br />
<br />
[mob_fake_death]<br />
on_actor_dist_le = 5 | nil<br />
<br />
При входе в схему зомби падает, при выходе из схемы встает.<br />
<br />
<br />
3.6. Оверрайды для монстров:<br />
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него<br />
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него<br />
friendly = если true, то монстр не атакует никого до первой атаки на него<br />
braindead = если true, то монстр игнорирует любые атаки.<br />
<br />
Секции для монстров<br />
[mob_death], [mob_hit]<br />
3.7. Секция spawner<br />
Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic<br />
Работает spawner следующим образом:<br />
<br />
[spawner]<br />
cond = {+info -info =func !func}<br />
<br />
Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн.<br />
Пример: <br />
[spawner]<br />
cond = {=is_day}<br />
(объект заспавниться днем и уйдет в оффлайн ночью)<br />
<br />
После того, как объект заспавнился, его берет под управление скрипт Logic<br />
<br />
3.7.1. Спавн монстров дневных и ночных.<br />
[spawner]<br />
cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day})<br />
check_distance = true – проверка на наличие персонажа рядом.<br />
min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).<br />
<br />
3.8. Скрипт logic<br />
<br />
NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)<br />
<br />
Скрипт logic управляет переключением схем. <br />
В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic]. <br />
<br />
Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.<br />
<br />
В секции должно присутствовать одно из полей: <br />
active = активная схема, запускающаяся первой.<br />
cfg = имя_ltx_файла_с_настройками<br />
<br />
Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. <br />
Пример. Настройки простого walker-а: <br />
<br />
[logic]<br />
active = walker<br />
<br />
[walker]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: <br />
Список доступных схем перечислен в главе схемы.<br />
Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.<br />
<br />
on_actor_dist_le = number | scheme - дистанция до игрока <= number<br />
on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость<br />
on_actor_dist_ge = number | scheme - если дистанция до игрока > number<br />
on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость<br />
on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы<br />
on_info = scheme - срабатывает всегда<br />
on_timer = msec | scheme - срабатывает через msec мс после включения схемы<br />
on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы<br />
on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора)<br />
on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора)<br />
on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора<br />
on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора<br />
on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее<br />
on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами<br />
<br />
NB: с любыми из вышеперечисленных параметров можно работать следующим образом:<br />
on_info = {….} %...%<br />
on_info2 = {….} %...%<br />
on_info3 = {…} %...%<br />
и так далее до посинения<br />
<br />
<br />
а также условия для переключения на описанные выше секции.<br />
combat_ignore_cond = <br />
on_hit = <br />
on_death = <br />
on_combat = <br />
on_use =<br />
3.8.1. Синтаксис скрипта Logic<br />
<br />
Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее: <br />
<br />
[logic]<br />
active = walker1<br />
<br />
[walker1]<br />
path_walk = walk1<br />
path_look = look1<br />
on_actor_dist_le = 5 | walker2<br />
<br />
[walker2]<br />
path_walk = walk2<br />
path_look = look2<br />
<br />
Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет. <br />
<br />
Пример: <br />
<br />
on_actor_dist_le = 5 | {условие} walker2 %эффекты%<br />
<br />
Условия могут быть следующими: <br />
<br />
+infoportion - требуется присутствие infoportion у actor<br />
-infoportion - требуется отсутствие infoportion у actor<br />
=func - требуется, чтобы func вернула true<br />
!func - требуется, чтобы func вернулся false<br />
<br />
Эффекты могут быть следующими: <br />
<br />
+infoportion - в случае включения секции у actor будет установлен infoportion<br />
-infoportion - в случае включения секции у actor будет убран infoportion<br />
=func - в случае включения секции стартует функция func<br />
<br />
Несколько условия или эффектов разделяются проблемами: <br />
<br />
on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%<br />
<br />
Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4: <br />
<br />
on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4<br />
<br />
В описанном выше поле active секции logic, можно также задавать условия, например: <br />
<br />
[logic]<br />
active = {=actor_friend} walker@friendly, walker@enemy<br />
В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например:<br />
combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%<br />
<br />
Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.<br />
<br />
Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока.<br />
NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя <br />
ее.<br />
3.8.2. Вот пример достаточно сложной логики: <br />
<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
on_hit = hit<br />
on_death = death<br />
<br />
[hit]<br />
on_info = %+alert%<br />
<br />
[death]<br />
on_info = %+alert +trup3%<br />
<br />
[walker]<br />
path_walk = walk_svoboda3<br />
path_look = look_svoboda3<br />
combat_ignore_cond = {-alert}<br />
on_timer = 25000 | remark<br />
<br />
[remark]<br />
anim = idle<br />
snd = stalker_talk_kampfire<br />
no_move = true<br />
no_rotate = true<br />
on_hit = hit<br />
on_death = death<br />
combat_ignore_cond = {-alert}<br />
<br />
[combat_ignore]<br />
<br />
Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.<br />
<br />
А вот логика его противника:<br />
[logic]<br />
active = walker<br />
combat_ignore = combat_ignore<br />
<br />
[walker]<br />
path_walk = soldier_walk1<br />
path_look = soldier_look1<br />
combat_ignore_cond = always<br />
team = assault_group<br />
on_signal = assault | camper<br />
<br />
[camper]<br />
path_walk = soldier_walk1_2<br />
path_look = soldier_look1_2<br />
radius = 5<br />
on_info = {+trup1 +trup2 +trup3} walker2<br />
<br />
[walker2]<br />
path_walk = soldier_walk1_3<br />
path_look = soldier_look1_3<br />
<br />
<br />
[combat_ignore]<br />
<br />
Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).<br />
<br />
3.9. Схемы логики space_restrictor<br />
<br />
Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.<br />
3.9.1. Схема [sr_idle] <br />
Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.<br />
Сама по себе схема ничего не делает.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_idle<br />
<br />
[sr_idle]<br />
on_actor_inside = nil %+esc_actor_inside%<br />
<br />
Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.<br />
Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.<br />
<br />
файл \gamedata\scripts\sr_idle.script<br />
3.9.2. Секция [sr_no_weapon]<br />
Данная схема убирает оружие у игрока при входе в зону.<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_no_weapon<br />
<br />
[sr_no_weapon]<br />
<br />
файл \gamedata\scripts\sr_no_weapon.script<br />
<br />
<br />
3.9.3. Секция [sr_sound], <br />
<br />
snd = Перечень имён звуков разделенных запятыми.<br />
<br />
type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.<br />
<br />
*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.<br />
<br />
*idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.<br />
<br />
*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.<br />
<br />
*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.<br />
<br />
*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3<br />
<br />
*slide_sound_once = true\false<br />
true - проиграть звук один раз, даже если он не дошел до последней точки пути.<br />
false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.<br />
<br />
*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет<br />
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.<br />
<br />
Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.<br />
<br />
Поддерживается sound_end.<br />
<br />
Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.<br />
<br />
Место, из которого может отыграться звук, задаётся одним из трёх:<br />
- случайное;<br />
- случайная вершина заданного пути;<br />
- позиция игрока.<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = floor_wooden<br />
snd = ambient\wind1, ambient\sparks1<br />
rnd = 50<br />
position = random<br />
idle = 120<br />
delay = 3<br />
<br />
Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity. <br />
<br />
[logic]<br />
active = sr_sound<br />
<br />
[sr_sound]<br />
type = random<br />
position = way<br />
slide_velocity = 8<br />
slide_sound_once = true<br />
<br />
Файл \gamedata\scripts\sr_sound.script<br />
<br />
<br />
<br />
3.9.4. Секция [sr_tip]<br />
Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор<br />
<br />
name = Название новости.<br />
type = по умолчанию «news»<br />
Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a<br />
*sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.<br />
<br />
*cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.<br />
<br />
*single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,<br />
<br />
Пример настроек рестриктора:<br />
<br />
[logic]<br />
active = sr_tip<br />
<br />
[sr_tip]<br />
name = tips_esc_trader_about_pda<br />
type = tips<br />
cond = {+infoportion1 –infoportion2 }<br />
*showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!<br />
<br />
Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку:<br />
on_actor_inside = nil <br />
<br />
файл \gamedata\scripts\sr_tip.script<br />
<br />
3.9.5. Sr_light<br />
Зона, в которой фонарики у неписей будут включены независимо от времени суток.<br />
<br />
Работает следующим образом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
<br />
Также работает вместе с кондлистом:<br />
<br />
[logic]<br />
active = sr_light<br />
<br />
[sr_light]<br />
light_on = true/false (свет включен/выключен)<br />
on_info = {+info1} section %+info2% <br />
3.9.6. Sr_territory<br />
<br />
Занимается эта схема тем, что отлавливает всякие события, происходящие внутри рестриктора.<br />
Пока что она отлавливает только хиты и смерть сталкеров. Пример использования примерно следующий:<br />
<br />
[logic]<br />
active = sr_territory@outside<br />
<br />
[sr_territory@outside]<br />
on_actor_inside = sr_territory@inside<br />
<br />
[sr_territory@inside]<br />
on_actor_outside = sr_territory@outside<br />
territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit}<br />
%+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit%<br />
territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%<br />
<br />
<br />
То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.<br />
<br />
<br />
3.9.7. Sr_mapspot<br />
<br />
При входе в рестриктор он сам себя подсвечивает на карте.<br />
<br />
Параметры:<br />
hint - id подсказки в string table (обязательный параметр)<br />
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")<br />
<br />
Пример:<br />
[logic]<br />
active = sr_mapspot<br />
<br />
[sr_mapspot]<br />
hint = “gar_swamp”<br />
location = crcl_big<br />
<br />
<br />
3.9.8. Sr_particle<br />
<br />
Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:<br />
<br />
1) для партикловой системы с путем камеры:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = particle_test.anm -имя пути камеры<br />
mode = 1 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов<br />
<br />
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.<br />
<br />
2) для партикловой системы с обычным патрульным путем:<br />
[sr_particle]<br />
name = explosions\campfire_03 -имя партикловой системы<br />
path = part_points -имя патрульного пути<br />
mode = 2 (обязательно !!!)<br />
looped = true/false -флаг зацикленности партиклов <br />
<br />
В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах. Если не задано, то 0). s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз.. Результат = партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).<br />
При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. <br />
Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.<br />
<br />
3.9.9. Sr_sound_act<br />
Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки<br />
<br />
[sr_sound_act]<br />
snd = ambient\random\new_drone1 --имя звукового файла<br />
*delay = 2000 --задержка перед проигрыванием <br />
*delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.<br />
*on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.<br />
theme = <имя темы из ph_sound_themes><br />
* stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который<br />
задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.<br />
<br />
Если указывается тема, то звук будет играть зациклено, случайным образом выбирая один из звуков прописанных в теме, если указывается звук, то он отыгрывается один раз. Схема поддерживает кондлист.<br />
<br />
3.9.10 Sr_timer<br />
<br />
Пример использования:<br />
<br />
[logic]<br />
active = sr_timer@1<br />
<br />
[sr_timer@1]<br />
type = dec<br />
start_value = 10000<br />
on_value = 0 | sr_timer@2<br />
<br />
[sr_timer@2]<br />
type = inc<br />
on_value = 15000 | nil %+info1%<br />
<br />
Описания полей:<br />
type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec).<br />
Если поле не задано - счетчик будет инкриментирующий<br />
start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.<br />
<br />
Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:<br />
<br />
on_value = 5000| %+info1% | 1000| %+info2%<br />
<br />
3.9.11. Sr_psy_antenna<br />
Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.<br />
<br />
Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга. <br />
<br />
eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения.<br />
hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.<br />
<br />
Пример зоны, которая добавляет 70% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
eff_intensity = 70<br />
hit_ intensity = 70<br />
<br />
Пример зоны, которая убирает 30% излучения:<br />
<br />
[logic]<br />
active = sr_psy_antenna<br />
<br />
[sr_psy_antenna]<br />
intensity = -30<br />
<br />
<br />
3.9.12. Sr_teleport<br />
Собственно, телепорт. Настраиваются следующим образом:<br />
<br />
[logic]<br />
active = sr_teleport<br />
<br />
[sr_teleport]<br />
timeout = 0<br />
<br />
point1 = point1<br />
look1 = look1<br />
prob1 = 10<br />
<br />
point2 = point2<br />
look2 = look2<br />
prob2 = 20 <br />
<br />
где:<br />
timeout - задержка в срабатывании телепорта в миллисекундах.<br />
point - одноточечный патрульный путь куда переместить<br />
look - одноточечный патрульный путь куда повернуть.<br />
<br />
Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.<br />
<br />
<br />
3.9.13. Sr_sleep и настройка снов.<br />
Появилась возможность задавать зоны сна.<br />
<br />
[sr_sleep]<br />
*cond = <condlist><br />
*type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.<br />
*dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.<br />
<br />
Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую.<br />
Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.<br />
<br />
В файле misc\dream.ltx задаются настройки снов.<br />
<br />
Секция videos.<br />
Полями задаются пути к видеофайлам со снами.<br />
<br />
Секция dreams. Поля:<br />
regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом <br />
regular - список секций с настройками для обычных сновидений<br />
scene - список секций с настройками для сценарных сновидений<br />
<br />
Настройки обычных сновидений:<br />
dream - имя поля из секции videos<br />
probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна.<br />
type = nightmare/normal/happy - тип сна.<br />
<br />
Настройки сценарных сновидений:<br />
dream - имя поля из секции videos<br />
cond = <condlist> - условия срабатывания<br />
to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.<br />
<br />
3.9.14. Sr_cutscene<br />
Эта схема предназначена для проведения анимации камеры c некоторым эффектом <br />
(pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.<br />
<br />
[sr_cutscene]<br />
point = <имя пути> - путь в первую точку которого переносится игрок<br />
look = <имя пути> - путь в первую точку которого смотрит игрок<br />
*pp_effector = <имя файла с эффектом> - файл, расположенный в папке <br />
gamedata\anims\ и содержащий эффект (имя файла пишется без расширения)<br />
cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без <br />
расширения)<br />
<br />
<br />
3.10. Набор дополнительных настроек логики у разных объектов.<br />
Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.<br />
<br />
3.10.1. Схема работы двери, секция [ph_door]<br />
<br />
NB! Для двухстворчатых ворот задается все аналогично.<br />
<br />
locked = false\true<br />
Заперта ли дверь. По дефолту – false.<br />
<br />
Closed = false\true<br />
Закрыта ли дверь. По дефолту - true<br />
<br />
tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.<br />
<br />
tip_close = (если locked == false, то tip_door_close, иначе пустое значение)<br />
Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.<br />
<br />
snd_init = Звук, который будет отыгран сразу при включении схемы.<br />
<br />
snd_open_start = Звук, который будет отыгран при попытке открыть дверь.<br />
<br />
snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.<br />
<br />
snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.<br />
<br />
Примеры:<br />
Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:<br />
<br />
[logic]<br />
active = ph_door@locked<br />
<br />
[ph_door@locked]<br />
locked = true<br />
snd_open_start = trader_door_locked<br />
on_info = {+esc_trader_can_leave} ph_door@unlocked<br />
<br />
[ph_door@unlocked]<br />
locked = false<br />
snd_init = trader_door_unlock<br />
snd_open_start = trader_door_open_start<br />
snd_close_start = trader_door_close_start<br />
snd_close_stop = trader_door_close_stop<br />
файл \gamedata\scripts\ph_door.script<br />
<br />
3.10.2. Схема работы кнопки, секция [ph_button]<br />
При нажатии на кнопку переключает секции и выдает инфопоршн.<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim_blend = false<br />
anim = button_false<br />
on_press = ph_button@unlocked %+cit_jail_door_opened%<br />
<br />
on_press – что происходит при нажатии<br />
anim – анимация, которая отигрывается при нажатии на кнопку<br />
anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false<br />
<br />
Файл \Gamedata\scripts\ph_button.script<br />
<br />
*tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.<br />
Пример настройки кнопки:<br />
<br />
[logic]<br />
active = ph_button@active<br />
<br />
[ph_button@active]<br />
anim = lab_switcher_idle<br />
tooltip = tips_labx16switcher_press<br />
on_press = ph_button@deactivated %+terrain_test%<br />
<br />
[ph_button@deactivated]<br />
anim = lab_switcher_off<br />
<br />
Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:<br />
<br />
<string id="tips_labx16switcher_press"><br />
<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text><br />
</string><br />
<br />
<br />
Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:<br />
<br />
[logic]<br />
active = ph_button@locked<br />
<br />
[ph_button@locked]<br />
anim = button_false – анимация несрабатывания кнопки.<br />
on_info = {+val_prisoner_door_unlocked} ph_button@unlocked<br />
on_press = ph_button@unlocked %+val_prisoner_door_unlocked%<br />
<br />
[ph_button@unlocked]<br />
anim = button_true<br />
on_info = {-val_prisoner_door_unlocked} ph_button@locked<br />
on_press = ph_button@locked %-val_prisoner_door_unlocked%<br />
<br />
<br />
3.10.3. Схема работы прожектора:<br />
<br />
В точках look пути, в которые смотрит прожекторщик, нужно прописать<br />
sl=имя_прожектора<br />
<br />
Например<br />
wp00|sl=esc_sl1<br />
<br />
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.<br />
<br />
3.10.4. Кодовые замки:<br />
При введении указанного кода выдает инфопоршн<br />
<br />
[logic]<br />
active = ph_code@lock<br />
<br />
[ph_code@lock]<br />
code = 1243<br />
on_code = %+infoportion%<br />
<br />
Файл: \gamedata\scripts\ph_code.script<br />
<br />
<br />
3.10.5. Ph_gate:<br />
То же самое, что и ph_door, но для ворот, состоящих из двух дверей:<br />
Вместо параметров closed и locked сейчас используются параметры:<br />
state: состояние, в котором дверь находится при инициализации (по умолчанию none)<br />
open - в открытом<br />
closed - в закрытом<br />
none - в текущем (дефолтном или оставшемся от предыдущей схемы)<br />
<br />
locking: блокировка дверей (по умолчанию none)<br />
stick - прилипание дверей к крайним состояниям (пока в процессе настройки)<br />
<br />
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - не используется (мягкая блокировка возможна только в крайних положениях) <br />
<br />
hard - блокировка двери с помощью границ. Ворота можно только сломать<br />
Состояния в этом положении:<br />
open - блокировать в открытом состоянии<br />
closed - в закрытом<br />
none - в текущем<br />
<br />
none - дверь не заблокирована<br />
<br />
Общие параметры:<br />
left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. <br />
breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.<br />
<br />
Звуковые параметры аналогичны ph_door<br />
<br />
Примеры:<br />
[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.<br />
state = opened<br />
locking = soft<br />
left_limit = 130<br />
rigt_limit = 60<br />
breakable = false<br />
<br />
[ph_gate@opened]<br />
state = opened<br />
locking = stick<br />
<br />
[ph_gate@closed]<br />
state = closeded<br />
<br />
Файл: \gamedata\scripts\ph_gate.script<br />
<br />
3.10.6. Ph_sound<br />
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).<br />
<br />
[ph_sound]<br />
snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes<br />
*looped = true/false зацикленое воспроизведение звука (default - false)<br />
*min_idle = минимальное время простоя перед включением звука (мс)<br />
*max_idle = максимальное время простоя перед включением звука (мс)<br />
*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения<br />
<br />
NB! Если мы задаем random = true и looped = true, то версия сыпется<br />
<br />
Также поддерждивается кондлист.<br />
Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil<br />
<br />
Пример подобной извращенной логики:<br />
[logic]<br />
active = ph_sound<br />
<br />
[ph_sound]<br />
snd = gar_seryi_shooting<br />
looped = true<br />
max_idle = 5000<br />
on_actor_in_zone = gar_seryi_factory| ph_sound@end<br />
<br />
[ph_sound@end]<br />
snd = gar_seryi_shooting_2<br />
looped = false<br />
on_signal = sound_end| nil<br />
<br />
<br />
Кроме того специфическим образом создается звуковая схема.<br />
В sound_theme.script в начале файла есть секция ph_themes в которой и описываются темы для физ объектов. <br />
Например:<br />
ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}<br />
<br />
Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.<br />
<br />
Файл: \gamedata\scripts\ph_sound.script<br />
<br />
3.10.7. Ph_force<br />
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.<br />
<br />
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах<br />
time = время прикладывания силы к предмету (в секундах)<br />
*delay = задержка (в секундах) перед применением силы<br />
point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)<br />
point_index = индекс точки патрульного пути, в стону которого полетит предмет.<br />
<br />
3.10.8. Ph_on_death<br />
<br />
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов<br />
Пример:<br />
<br />
[logic]<br />
active = ph_on_death<br />
<br />
[ph_on_death]<br />
on_info = %эффекты%<br />
<br />
Юзать исключительно с разрушаемыми физ. Объектами<br />
<br />
3.10.9. Ph_car<br />
<br />
Настройка возможности игроку управлять машиной.<br />
секция: [ph_car]<br />
поле: usable = <condlist><br />
<br />
usable - кондлист возвращающий true (по умолчанию) или false.<br />
<br />
Пример:<br />
[logic]<br />
active = ph_car<br />
<br />
[ph_car]<br />
usable = {+val_actor_has_car_key}<br />
<br />
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее. <br />
<br />
3.10.10. Ph_heavy<br />
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.<br />
В кастом дате пишем:<br />
<br />
[ph_heavy]<br />
<br />
<br />
3.10.11. Ph_oscillate<br />
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)<br />
Пример логики<br />
<br />
[ph_oscillate]<br />
joint = provod - имя кости к которой будет применена сила<br />
force = 5 - собственно сила (в ньютонах)<br />
period = 1000 - время прикладывания силы.<br />
<br />
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.<br />
<br />
3.11. Смарттерейны и гулаги.<br />
3.11.1. Смарттеррейн.<br />
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.<br />
<br />
Как поставить smart terrain?<br />
Для всех smart terrain нужно:<br />
1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).<br />
2) В его custom data прописать настройки.<br />
3) Расставить пути для соответствующих схем поведения. <br />
<br />
Параметры custom data:<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
<br />
Указывать тип гулага нужно без кавычек.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
Пути:<br />
Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.<br />
<br />
Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2) <br />
<br />
Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.<br />
<br />
3.11.1.1. Стандартные типы смарттеррейнов.<br />
<br />
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:<br />
[smart_terrains]<br />
none = true<br />
<br />
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.<br />
<br />
<br />
campers<br />
Кемперы. custom data:<br />
[gulag1]<br />
type = campers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
camper_walk1, camper_look1<br />
camper_walk2, camper_look2<br />
camper_walk3, camper_look3<br />
<br />
<br />
walkers<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = walkers<br />
capacity = от 1 до 3<br />
<br />
Пути:<br />
walker_walk1, walker_look1<br />
walker_walk2, walker_look2<br />
walker_walk3, walker_look3<br />
<br />
<br />
search<br />
Ходячие. На базе этого можна сделать поиск, обыск и куча всего.<br />
custom data:<br />
[gulag1]<br />
type = search<br />
capacity = 1<br />
<br />
Пути:<br />
search_walk, search_look<br />
<br />
Схема следующая:<br />
1. Персонаж ходит по точкам, смотрит по сторонам<br />
2. В определенных точках останавливается и что-то высматривает (caution, search, hide)<br />
3. При этом говорит определенные реплики (…)<br />
<br />
rest<br />
Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).<br />
custom data:<br />
[gulag1]<br />
type = rest<br />
capacity = 1<br />
<br />
Пути:<br />
rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.<br />
sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.<br />
rest_walk, rest_look<br />
<br />
3.11.2. Гулаги.<br />
Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: <br />
А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); <br />
Б) Работы имеют приоритеты; <br />
В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; <br />
Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.<br />
<br />
<br />
<br />
Гулаг создается следующим образом:<br />
<br />
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.<br />
<br />
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.<br />
<br />
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.<br />
<br />
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.<br />
[gulag1] <br />
type = тип гулага<br />
capacity = макс. вместимость в людях<br />
*offline = может ли гулаг образоваться в offline (true/false)<br />
*squad = squad, который будет проставлен всем сталкерам под гулагом<br />
*groups = набор group через запятые<br />
*stay = min, max время пребывания npc под smart_terrain<br />
*idle = min, max время бездействия smart_terrain после ухода последнего npc<br />
*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.<br />
*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)<br />
<br />
Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.<br />
Указывать тип гулага нужно без кавычек.<br />
Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.<br />
Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.<br />
Все времена задаются в часах игрового времени и могут быть дробными.<br />
<br />
5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:<br />
if gulag_type == "gar_dolg" then<br />
return npc_community == "dolg"<br />
end<br />
<br />
В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.<br />
<br />
6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага. <br />
<br />
function loadStates(gname, type)<br />
в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:<br />
if type == "gar_maniac" then<br />
return function(gulag)<br />
if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then<br />
return 0 -- день<br />
else<br />
return 1 -- ночь<br />
end<br />
end<br />
end<br />
В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.<br />
<br />
8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:<br />
function loadJob(sj, gname, type, squad, groups)<br />
sj – сама табличка работ гулагов,<br />
gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.<br />
Type – тип гулага<br />
Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.<br />
<br />
Примерное описание работ гулага:<br />
Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.<br />
<br />
--' Garbage maniac<br />
if type == "gar_maniac" then<br />
t = { section = "logic@gar_maniac_camper",<br />
idle = 0,<br />
prior = 5, state = {0},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
t = { section = "logic@gar_maniac_sleeper",<br />
idle = 0,<br />
prior = 5, state = {1},<br />
squad = squad, groups = groups[1],<br />
in_rest = "", out_rest = "",<br />
info_rest = “”<br />
}<br />
table.insert(sj, t) <br />
end<br />
<br />
Описание полей:<br />
Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.<br />
Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.<br />
In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание.<br />
Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе.<br />
Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.<br />
Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе<br />
Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например: <br />
<br />
predicate = function(obj) <br />
return obj:profile_name() == "soldier_commander” <br />
end<br />
то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.<br />
<br />
<br />
9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:<br />
<br />
;----------------------------<br />
;-- GARBAGE MANIAC<br />
;----------------------------<br />
[logic@gar_maniac_camper]<br />
active = camper@gar_maniac_camper<br />
<br />
[camper@gar_maniac_camper]<br />
path_walk = walk1<br />
path_look = look1<br />
<br />
<br />
[logic@gar_maniac_sleeper]<br />
active = sleeper@gar_maniac_sleeper<br />
<br />
[sleeper@gar_maniac_sleeper]<br />
path_main = sleep<br />
wakeable = true<br />
<br />
Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:<br />
1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.<br />
2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)<br />
3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).<br />
<br />
В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.<br />
<br />
3.11.3. Новые особенности смарттеррейнов<br />
Возможности нового смарттеррейна (СТ):<br />
<br />
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус.<br />
2) Сталкеры идут на ближайшие работы.<br />
3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне.<br />
4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ.<br />
5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие.<br />
6) Работы могут находиться на разных уровнях.<br />
7) Скриптовая зона СТ теперь не используется для захвата персонажей.<br />
8) Симуляция заключается в миграции персонажей между разными СТ.<br />
<br />
Что нужно переделать:<br />
<br />
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже)<br />
2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай)<br />
3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже)<br />
4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже)<br />
5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли.<br />
6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].<br />
<br />
------------- Настройки: -------------<br />
<br />
---- Разрешения персонажам идти в определённые СТ ----<br />
<br />
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:<br />
<br />
[smart_terrains]<br />
strn_1 = условие1<br />
strn_2 = условие2<br />
<br />
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным.<br />
Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него.<br />
Если не появилось ни одного эксклюзивного, то он согласен идти в любой.<br />
<br />
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.<br />
<br />
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:<br />
<br />
communities = группирвка1, группировка2, ...<br />
<br />
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).<br />
<br />
---- Изменение функций predicate() ----<br />
<br />
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля:<br />
name<br />
community<br />
class_id<br />
story_id<br />
profile_name<br />
<br />
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:<br />
<br />
predicate = function(npc_info)<br />
return npc_info.is_sniper == true<br />
end<br />
<br />
<br />
---- Изменение функций переключения состояния СТ ----<br />
<br />
Обращайтесь индивидуально. Все переделки связаны с работой этой функции в офлайне. Например, таблица gulag.Object[] не содержит game_object-ы, если персонаж в офлайне и т.п.<br />
<br />
---- Состояния работ online/offline<br />
<br />
t = { section = "logic@ЧЧЧЧЧЧЧЧ", <br />
idle = 0,<br />
prior = 5, state = {0}, squad = squad, group = groups[1],<br />
online = true,<br />
in_rest = "", out_rest = ""<br />
}<br />
table.insert(sj, t)<br />
<br />
Варианты задания этого поля<br />
online = true - на этой работе персонаж всегда в онлайне,<br />
online = false - на этой работе персонаж всегда в офлайне,<br />
online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению.<br />
3.11.3.1. Более доступное описание новых смарттеррейнов<br />
Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски.<br />
Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее:<br />
1. Пишем в кастом дате где [gulag1] -> [smart_terrain]<br />
2. В кастом дате товарищей по смарттеррейну пишем <br />
[smart_terrains]<br />
sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.<br />
Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.<br />
[smart_terrains]<br />
none = true<br />
<br />
<br />
3.12. Логика вертолёта<br />
Общие сведения:<br />
<br />
Вертолёт работает на «логике».<br />
На вертолёт реагируют аномалии.<br />
Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.<br />
Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.<br />
У вертолёта есть универсальная боевая схема на манер сталкеров.<br />
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.<br />
<br />
3.12.1. Схема heli_move:<br />
Общие сведения:<br />
Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.<br />
<br />
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.<br />
<br />
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.<br />
<br />
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.<br />
<br />
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень). <br />
<br />
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.<br />
<br />
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.<br />
<br />
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look<br />
<br />
Настройки:<br />
<br />
*engine_sound = true/false (по умолчанию true)<br />
Вкл/выкл звук двигателя вертолёта.<br />
<br />
*invulnerable = true/false (по умолчанию false)<br />
Неуязвимость. Если true, вертолёт игнорирует все хиты.<br />
<br />
*immortal = true/false (по умолчанию false)<br />
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.<br />
<br />
*mute = true/false (по умолчанию false)<br />
Отключает универсальные реплики пилотов вертолета.<br />
<br />
*rocket_delay = msec (время в миллисекундах реального времени)<br />
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)<br />
<br />
*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)<br />
<br />
Параметры, задаваемые в именах вершин пути path_move:<br />
<br />
«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.<br />
<br />
«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.<br />
<br />
«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.<br />
<br />
«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.<br />
<br />
«die» - убить вертолёт.<br />
<br />
«flame» - начать дымить (как будто подбили).<br />
<br />
<br />
Параметры, задаваемые в именах вершин пути path_look:<br />
<br />
«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.<br />
<br />
«w» – см. такой же параметр для пути path_move.<br />
<br />
«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.<br />
<br />
3.12.2. Универсальная боевая схема:<br />
Общие сведения:<br />
<br />
В универсальной боевой схеме вертолёт не привязан к путям.<br />
<br />
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.<br />
<br />
Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.<br />
<br />
Настройки:<br />
<br />
Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:<br />
<br />
combat_ignore = true/false<br />
true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.<br />
<br />
combat_enemy = nil/actor/StoryID<br />
С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.<br />
<br />
combat_use_rocket = true/false<br />
Можно ли вертолёту пользоваться рокетами.<br />
<br />
combat_use_mgun = true/false<br />
Можно ли вертолёту пользоваться пулемётом.<br />
<br />
combat_velocity = <число><br />
Скорсть, с которой вертолет будет делать боевые заходы<br />
<br />
combat_safe_altitude = <число><br />
Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)<br />
<br />
К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:<br />
<br />
heli_set_enemy_actor - сделать актёра врагом вертолёту<br />
heli_start_flame - поджечь вертолёт<br />
heli_die - убить вертолёт<br />
<br />
combat_velocity = - боевая скорость в этой секции указывается в м/с<br />
combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения<br />
combat_use_rocket = - true/false использовать ли ракеты в этой секции<br />
combat_use_mgun = - true/false использовать ли пулемет в этой секции<br />
<br />
3.13. Meet_manager<br />
<br />
Синтаксис:<br />
<br />
[logic]<br />
meet = meet<br />
<br />
[walker]<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| state@sound| 20| state@sound| 10| state@sound<br />
meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound<br />
victim = 30| nil| 20| actor<br />
victim_wpn = 30| nil| 20| actor<br />
use = self<br />
use_wpn = false<br />
zone = name| state@sound<br />
meet_dialog = dialog_id<br />
synpairs = state@sound|state@sound<br />
abuse = true/false<br />
<br />
<br />
Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.<br />
<br />
Перечень полей:<br />
meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.<br />
victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.<br />
use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться <br />
zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе<br />
meet_dialog – стартовый диалог НПС.<br />
synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br />
аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.<br />
Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info% )<br />
<br />
Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:<br />
<br />
[walker]<br />
meet = default_meet<br />
<br />
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.<br />
<br />
<br />
<br />
<br />
Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):<br />
<br />
Ситуация 1<br />
Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br />
<br />
[meet]<br />
meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait<br />
meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = true<br />
use_wpn = false<br />
<br />
Ситуация 2<br />
Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br />
<br />
[meet]<br />
meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state<br />
meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait<br />
victim = 50| actor<br />
victim_wpn = 50| actor<br />
use = {-info2} self, false<br />
use_wpn = false<br />
<br />
Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС<br />
Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.<br />
Killactor – функция в xr_effects которая обижает НПС на игрока.<br />
<br />
Ситуация 3<br />
Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br />
<br />
[camper]<br />
path_walk = path_walk<br />
path_look = path_look<br />
meet = meet<br />
<br />
[meet]<br />
meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back<br />
meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back <br />
victim = 30| actor<br />
victim_wpn = 30| actor<br />
use = true<br />
use_wpn = true<br />
zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse<br />
meet_dialog = {+info} dialog1, dialog2<br />
<br />
Здесь:<br />
True – вместо анимации, атаковать игрока.<br />
Info – Инфопоршн, который говорит что мы имеем допуск к лагерю<br />
Warnzone – рестриктор, в котором нас предупреждают<br />
Kampzone – рестриктор, в котором нас убивают<br />
Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь<br />
Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.<br />
Дефолтные настройки:<br />
По дефолту встреча настроена со следующими параметрами:<br />
<br />
meet_state = 30|hello@hail|20|wait@wait<br />
meet_state_wpn = 30|backoff@threat_weap<br />
victim = 30|actor<br />
victim_wpn = 30|actor<br />
use = true<br />
use_wpn = false<br />
syndata = hello@hail|backoff@threat_weap<br />
<br />
<br />
NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet<br />
<br />
<br />
3.14. Отметки на минимапе<br />
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:<br />
<br />
[camper]<br />
show_spot = false (будучи в этой секции сталкер не показывается на карте)<br />
<br />
[walker]<br />
show_spot = {+info1} false<br />
<br />
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.<br />
<br />
3.15. Передача параметров в функции.<br />
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.<br />
<br />
NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.<br />
<br />
Описание функций с параметрами присутствующих в xr_conditions и xr_effects.<br />
<br />
---------------------------------------------------------------------<br />
xr_conditions:<br />
<br />
fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока<br />
(в метрах)<br />
<br />
distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного<br />
story_id. <br />
Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.<br />
<br />
health_le(health) - проверка того, что здоровье npc <= health<br />
<br />
heli_health_le(health) - аналогично предыдущему, только для вертолета.<br />
<br />
enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)<br />
<br />
hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.<br />
Пример:<br />
[hit]<br />
on_info = {=hitted_by(407:408)} %+val_escort_combat%<br />
<br />
killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.<br />
<br />
is_alive(sid)<br />
is_alive_one(sid1:sid2:...)<br />
is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы<br />
<br />
is_dead(sid)<br />
is_dead_one(sid1:sid2:...)<br />
is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".<br />
<br />
check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.<br />
<br />
gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.<br />
<br />
gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num<br />
<br />
gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num<br />
NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.<br />
<br />
signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал<br />
<br />
--------------------------------------------------------------------<br />
xr_effects:<br />
<br />
heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.<br />
<br />
set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага<br />
<br />
hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:<br />
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.<br />
bone - строка. Имя кости, по которой наносится удар.<br />
power - сила удара<br />
impulse - импульс<br />
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.<br />
Пример:<br />
[death]<br />
on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%<br />
<br />
set_friends(sid1:sid2:...)<br />
set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.<br />
<br />
play_snd(snd_name:delay=0) - играть звук в голове актёра.<br />
snd_name - путь к звуку относительно папки sounds<br />
delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.<br />
<br />
play_snd_now (sid:snd_name) – играть звук от указанного объекта<br />
*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла<br />
<br />
hit_obj(sid, bone, power, impulse, hit_src=npc:position())<br />
Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]<br />
1. sid - story_id обьекта, по которому наносится хит.<br />
2. bone - строка. Имя кости, по которой наносится удар.<br />
3. power - сила удара<br />
4. impulse - импульс<br />
5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.<br />
<br />
actor_has_item(section)<br />
Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx<br />
<br />
Функции для работы с HUD'ом.<br />
<br />
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.<br />
<br />
Параметры:<br />
-- weapon - спрятать/показать руки с оружием<br />
-- input - отключить/включить клавиатуру<br />
-- hud - спрятать/показать индикаторы на экране<br />
-- all - отключить/включить все элементы<br />
<br />
Пример:<br />
on_info = %=disable_ui_elements(weapon:input)%<br />
<br />
Есть также сокращенные варианты:<br />
<br />
disable_ui, enable_ui (вызываются без скобок и параметров).<br />
Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.<br />
<br />
Пример:<br />
on_info = %=enable_ui%<br />
<br />
Функция запуска camera_effector'а.<br />
<br />
run_cam_effector(имя_файла)<br />
<br />
имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)<br />
из папки S:\GameData\anims\camera_effects\.<br />
<br />
Пример:<br />
on_info = %=run_cam_effector(prison_0)%<br />
<br />
Функция запуска постпроцесса.<br />
<br />
В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.<br />
Теперь есть 2 функции для работы с постпроцессами:<br />
<br />
run_postprocess(file_name:id:loop) - запуск постпроцесса.<br />
<br />
-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.<br />
-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.<br />
-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.<br />
<br />
stop_postprocess(id) - принудительная остановка постпроцесса.<br />
<br />
-- id - номер постпроцесса заданный в run_postprocess.<br />
<br />
Функция выброса содержимого инвентаря актера в определенную точку.<br />
<br />
drop_actor_inventory(имя_пути)<br />
<br />
выбрасываем все предметы из инвентаря актера в первую точку заданного<br />
пути.<br />
<br />
Пример:<br />
on_info = %=drop_actor_inventory(drop_point)%<br />
3.16. Настройка звуковых групп.<br />
Новый принцип создания звуковых групп:<br />
1. Каждый персонаж по умолчанию считается находящимся в уникальной саундгруппе.<br />
2. Для того, чтобы объеденить нескольких персонажей в единую саундгруппу, необходимо в секции логики прописать soundgroup = <текстовая строка><br />
Звуковые группы должны быть уникальными в пределах уровня, а еще лучше в пределах всей игры. Для этого указывайте в звуковой группе идентификатор уровня и сценки, например:<br />
soundgroup = bar_dolg_kampfire1<br />
3. Объеденять в звуковые группы необходимо персонажей сидящих в кемпе и идущих в патрулях. А также при других схожих ситуациях. <br />
4. Дабы избежать ошибок при обижании, наподобие той, которая сейчас проявляется в лагере на эксейпе, необходимо чтобы все НПС, логически относящиеся к одному лагерю имели одинаковый team, squad, group<br />
<br />
Пример:<br />
[kamp@esc_bridge_post1]<br />
center_point = kamp_point<br />
soundgroup = esc_bridge_soldiers<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:30:26Z<p>78.106.25.142: /* Ссылки и дополнительный материал */</p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
== Нюансы ==<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
'''ACDC''' - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
<br />
'''Made by Bardak'''<br />
<br />
'''Added by Loxotron'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:30:14Z<p>78.106.25.142: /* Ссылки и дополнительный материал */</p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
== Нюансы ==<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
'''ACDC''' - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
<br />
'''Made by Bardak'''<br />
'''Added by Loxotron'''<br />
<br />
'''Added by Loxotron'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:30:05Z<p>78.106.25.142: /* Ссылки и дополнительный материал */</p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
== Нюансы ==<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
'''ACDC''' - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
<br />
'''Made by Bardak'''<br />
'''Added by Loxotron'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:27:44Z<p>78.106.25.142: /* Нюансы */</p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
== Нюансы ==<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
'''ACDC''' - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
<br />
'''Made by Bardak'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:27:29Z<p>78.106.25.142: /* Суть идеи */</p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
== Нюансы ==<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
'''ACDC''' - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
<br />
'''Made by Bardak'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:26:50Z<p>78.106.25.142: /* Ссылки и дополнительный материал */</p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
'''ACDC''' - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
<br />
'''Made by Bardak'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:26:37Z<p>78.106.25.142: /* Ссылки и дополнительный материал */</p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
'''ACDC''' - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
'''Made by Bardak'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:26:07Z<p>78.106.25.142: /* Ссылки и дополнительный материал */</p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
ACDC - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
'''Made by Bardak'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:25:29Z<p>78.106.25.142: </p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
==Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
ACDC - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
'''Made by Bardak'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:25:00Z<p>78.106.25.142: </p>
<hr />
<div>== Суть идеи ==<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
=Ссылки и дополнительный материал==<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
ACDC - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
'''Made by Bardak'''<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:22:19Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by Bardak'''<br />
<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn). <br />
Но там могут быть ошибки.<br />
<br />
Внизу вы найдете пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно).<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же '''acdc.pl''' методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
*Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
*Дополнительная инфа<br />
ACDC - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:20:22Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by Bardak'''<br />
<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn, ссылка в ветке про bfa). Но там могут быть ошибки.<br />
<br />
Здесь пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно):<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же acdc.pl методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
[[Категория:Скрипты]]<br />
<br />
<br />
**Дополнительные ссылки<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
[http://stalkerin.gameru.net/developer/mods/acdc.rar ACDC]<br />
<br />
**Дополнительная инфа<br />
ACDC - сборщик-разборщик двух секций в all.spawn, но подсекцию M_UPDATE он не обрабатывает пока. Вырос из автоматического обработчика.</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:11:39Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by Bardak'''<br />
<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn, ссылка в ветке про bfa). Но там могут быть ошибки.<br />
<br />
Здесь пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно):<br />
[http://stalkerin.gameru.net/developer/mods/create_anom_heli.zip Example]<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же acdc.pl методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:05:24Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by Bardak'''<br />
<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn, ссылка в ветке про bfa). Но там могут быть ошибки.<br />
<br />
Здесь пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно):<br />
http://ifolder.ru/2817099<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же acdc.pl методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
[[Категория:Скрипты]]</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:03:44Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by Bardak'''<br />
<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
</code><br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn, ссылка в ветке про bfa). Но там могут быть ошибки.<br />
<br />
Здесь пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно):<br />
http://ifolder.ru/2817099<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же acdc.pl методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.</div>78.106.25.142http://stalkerin.gameru.net/wiki/index.php?title=SoC._%D0%9E%D0%B4%D0%B8%D0%BD_%D0%B8%D0%B7_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BF%D0%B0%D0%B2%D0%BD%D0%B0SoC. Один из методов спавна2007-08-14T19:03:17Z<p>78.106.25.142: </p>
<hr />
<div>'''Made by Bardak'''<br />
<br />
Создание на лету рабочих аномалий, вертолётов, переходов между уровнями, рестрикторов, точек воспроизводства и других объектов, конструктор которых задаёт не все необходимые для полноценного функционирования параметры.<br />
<br />
Идея проста.<br />
<br />
<code lua>1) Создаём объект стандартным методом:<br />
local obj = alife():create(...)<br />
<br />
2) Создаём экземпляр класса net_packet:<br />
local packet = net_packet()<br />
<br />
3) Сохраняем состояние объекта в пакет:<br />
obj:STATE_Write(packet)<br />
<br />
4) Считываем _все_ сохраняемые свойства в переменные:<br />
local property1 = packet:r_u32()<br />
...<br />
local propertyN = packet:r_float()<br />
<br />
5) Записываем эти переменные опять, меняя или дополняя необходимые параметры:<br />
packet:w_u32(property1)<br />
...<br />
propertyN = new_value<br />
packet:w_float(propertyN)<br />
<br />
6) Считываем модифицированное состояние объекта:<br />
packet:r_seek(0)<br />
obj:STATE_Read(packet, packet:w_tell())<br />
<br />
<br />
Где брать список сохраняемых параметров и их размеры? Самый верный способ - дизассемблирование методов STATE_Write и STATE_Read всех классов вида CSE_ALife... в xrGame.dll. Более простой - смотреть методы state_read "классов" cse_alife_... в acdc.pl (это альтернативный редактор all.spawn, ссылка в ветке про bfa). Но там могут быть ошибки.<br />
<br />
Здесь пример кода, который скриптом создаёт рабочую электру и вертолёт (у ног игрока и на 50 метров выше игрока соответственно):<br />
http://ifolder.ru/2817099<br />
<br />
Лучше всего смотреть на Кордоне. Вертолёт ни на что не реагирует, но это нормально. Ему нужно либо логику через custom_data прописывать, либо ручками дёргать управляющие методы.<br />
<br />
Нюансы:<br />
1) Для некоторых типов объектов желательно дёргать UPDATE_Write/UPDATE_Read. Смотрите в том же acdc.pl методы update_read (если есть).<br />
2) Стоит попробовать поиграться с аномалиями, которые создаются при активации артефактов. Если у них таймер не внешний, то есть шанс регулировки времени жизни. Ссылку на серверный объект можно получить через биндер, например.<br />
<br />
</code></div>78.106.25.142