Повідомлень у темі: 8

[RUS_D]

Часть 1.

 

3.1. Система флагов (path_walk, path_look)

В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени waypoint-а, например, для точки с именем "wp00": wp00|flag1|flag2.
Флаги точек пути path_walk:

a=state

Выбирает состояние тела при перемещении (Только из раздела – Ходячие состояния). Список состояний можно взять в gamedata\scripts\state_lib.script.

p=percent

Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.

sig=name

Установить сигнал с именем name сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля on_signal логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути path_look.
Флаги точек пути path_look:

a=state

Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов Стоячие и Сидячие состояния) Список состояний можно взять в gamedata\scripts\state_lib.script

t=msec

Время в миллисекундах, которое персонаж должен смотреть в заданную точку. ‘*’ – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000. Для конечных (терминальных) вершин пути path_walk, у которых не более 1-й соответствующей точки path_look, значение t всегда считается бесконечным и его явно задавать не нужно.

sig=name

После поворота в точку path_look, установить сигнал с именем name.

syn

Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком syn не прибудут все персонажи с данным team-ом (team задается в виде текстовой строки в customdata). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою idle анимацию.

sigtm=signal

Устанавливает сигнал при вызове time_callback-а state manager-ом. Соответственно, если t=0, то сигнал будет установлен после отыгрывания init анимации. Это используется, например, с анимацией press, которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку.

В пути path_look можно сделать: wp00 | a=press | t=0 | sigtm=pressed
А затем переключить схему: on_signal = pressed | другая_схема

 

3.1.1. Более подробное описание путей (walker)

Настройка:

На карту для каждого walker'а нужно поставить:
Путь path_walk, по которому walker ходит.
Путь path_look, состоящий из точек, в которые walker смотрит.

Walker'ов может быть от одного или больше. Они могут действовать независимо, или взаимодействовать друг с другом.

[walker]
team = ... - имя команды, произвольная текстовая строка. Все walker'ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker'ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.
path_walk = ... - имя пути, описанного в п. 1
path_look = ... - (не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать. Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look.

Правила расстановки флажков в путях рассмотрим на нескольких примерах.

Пример 1:

Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом:

Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки. У каждого вейпоинта есть имя: wp00, wp01 и т.д. Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишется a = anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a = threat, то персонаж пойдет в состоянии danger, если a = raid - то побежит с оружием наизготовку, и т.д.

В точках пути path_walk используются анимации только из раздела «Ходячие состояния»!

Пример 2:

Разговор персонажа.

Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существует поле: s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.

Пример 3:

В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически. Остальные параметры (sp, sf, st) задавать не рекомендуется, значения по умолчанию приемлемы для большинства скриптов. Параметр sa также использовать не рекомендуется. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе. Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.

Пример 4:

Усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него. Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.

Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1. Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.

Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь. Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.

По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:
p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400). Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100. По умолчанию у всех точек p = 100.
t = ... время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)

Пример 5:

В этом примере, проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.

По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch. Если требуется другая анимация, можно ее указать с помощью флажка:
a = имя_анимации (по умолчанию idle). Пишется a = anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a = hide, то персонаж сядет в состоянии danger, если a = guard, то встанет с оружием наизготовку и т.д.

В точках пути path_look используются анимации только из раздела «Ходячие состояния»!

 

3.2. Схемы поведения сталкеров.

Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.

В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.

 

3.2.1. Схема walker

Это базовая схема, в которой персонаж перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия.

[walker]
path_walk = имя пути - основной путь, по которому ходит NPC
path_look = имя пути - путь, куда смотрит NPC
team - команда для синхронизации

В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.
def_state_moving1 - состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)
def_state_moving2 - состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)
def_state_moving3 - состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)
def_state_standing - дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.

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

 

3.2.2. Схема remark

Схема используется для синхронизации\связки других схем.

[remark]
snd_anim_synс = true/false - Указывает на то необходимо ли синхронизировать звук с анимацией либо нет
snd - звук ремарка, по умолчанию nil
anim - анимация ремарка, по умолчанию wait
target - куда смотрит сталкер. Есть следующие варианты
story_id – числовое значение
actor – без комментариев
nil – позиция вычисленная АИ автоматически
<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).

Пример:

target = logic@cit_killers_base_guard, cit_killers , - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).

Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает AI.

Стандартные сигналы для remark:
sound_end – по окончании проигрывания звуковой схемы
anim_end – по окончании проигрывания анимации
action_end – по окончании проигрывания и того и другого, если они синхронизированы

Пример синхронизации анимации и звука в схеме remark:

[remark]
anim - анимация
snd - звук
snd_anim_sync = true - синхронизация
on_signal = action_end | следующая схема

 

3.2.3. Схема sleeper

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

[sleeper]
path_main = ... - имя пути
wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)

Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).

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

 

3.2.4. Схема kamp

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

[kamp]
center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.
radius = 2 - насколько далеко сталкер будет сидеть от центра лагеря, 2 - по умолчанию.
def_state_moving = run - дефолтное состояние, в котором сталкер будет идети к точке кампа.

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

Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой равно:

_task
path_walk = _task

Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.

 

3.2.5. Схема camper

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

[camper]
path_walk = patrol_path
path_look = patrol_path
radius = ... – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.
no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.
def_state_moving = ... - (состояние из стейт менеджера), в котором мы движемся на ближайшую точку пути при враге.
def_state_moving_fire = ... - (состояние из стейт менеджера (sneak_fire)), в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.
def_state_campering = ... - (состояние из стейт менеджера (hide)), в котором мы ожидаем врага, находясь на пути.
def_state_campering_fire = ... (состояние из стейт менеджера (hide_fire)), в котором мы отстреливаемся от врага, находясь на пути.
attack_sound = имя_звуковой_темы - возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера пустой атрибут.
shoot = ... - Задаем тип стрельбы. Возможные значения:
always - значение по умолчанию, стреляет всегда, когда можно
- не стреляет вообще.
terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.

У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули. Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.

 

3.2.5.1. Схема sniper

Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек. Внимание! Ставить снайперу только 2 точки look.

В кастом дате кемпера прописать:
sniper = true

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

 

3.2.6. Схема follower

В custom_data прописан как follower. NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.

[follower]
leader = ... - story_id лидера из game.ltx (число!).
formation_line = true - постарается идти сбоку от лидера, в противном случае будет идти сзади.
distance = ... - расстояние в метрах, на котором будет идти от лидера attendant. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.
state_if_leader_in_meet - это есть строка с именем состояния из state_manager, которое будет назначено follower'ам, если командир пребывает в состоянии meet.
anim_walk = state - состояние, в котором фолловер идет за лидером.
anim_run = state - состояние, в котором фолловер бежит за лидером.
anim_sprint = state - состояние, в котором фолловер спринтует за лидером.

Файл: \gamedata\scripts\xr_ attendant.script

Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта. Пример:
t = { section = "logic@bar_arena_follower_2",
idle = 0,
prior = 7, state = {0}, squad = squad, group = groups[0],
in_rest = "", out_rest = "",
dependent = "logic@bar_arena_leader",
predicate = function(obj)
return obj:character_community() == "dolg"
end
}

 

3.2.7. Схема zoneguard

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

[zoneguard]
path_walk = ... - путь перемещения
path_look = ... - путь обзора
team = ... - имя команды синхронизированных zoneguard-ов (из всей команды только 1 будет реагировать на игрока)
zone_guard = ... - имя зоны, в пределах которой игрок будет атакован
zone_warn = ... - имя зоны, в пределах которой начинать разговор с игроком
walker_team = ... - team для схемы перемещения его в состоянии walker (если не задан, используется значение из поля team)
no_move = ... - если true, персонаж окликнет игрока с места и не будет подбегать к нему
snd_greet = ... - имя звуковой схемы, из которой будет проигран звук при обнаружении персонажа
ignore_friends = ... - true - будет игнорировать дружественных ему персонажей.
ignore_cond = {+info -info =func !func} - условия, при которых NPC игнорирует игрока
no_danger = ... - если true, то не отыгрывает угрожающую анимацию, нейтралам.
anim = ... - какую отыгрывает анимацию, если игрок ему не враждебен.
snd_anim_sync = ... - если true, то npc будет синхронизировать звук с анимацией

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

 

3.2.8. Схема wounded (раненый)
[logic]
wounded = wounded

[walker]
wounded = wounded

[wounded]
hp_state = HP|condstate@condsound|HP|condstate@condsound
hp_state_see = HP|condstate@condsound|HP|condstate@condsound
psy_state = PSY|condstate@condsound|PSY|condstate@condsound
hp_victim = HP|condvictim|HP|condvictim
hp_cover = HP|condbool|HP|condbool
hp_fight = HP|condbool|HP|condbool
syndata = state@sound|state@sound
help_dialog = story_id
help_start_dialog = story_id

Где:
condstate – кондлист, возвращающий состояние персонажа, либо true. Если он возвращает true – нпс обидится на игрока
condsound – кондлист, возвращающий саунд тему.
HP – пороговые значение здоровья персонажа
PSY – пороговые значения пси здоровья персонажа
condvictim – кондлист, возвращающий направление куда смотреть. Возможные значения: nil, actor, number. В случае числа – будет смотреть на персонажа с указанными стори айди.
condbool – кондлист, возвращаюзий true либо false.

Значения полей:
hp_state – поведение персонажа когда он не видит игрока
hp_state_see – поведение персонажа, когда он видит игрока
psy_state – поведение персонажа при псиатаках
hp_victim – куда смотреть, в зависимости от ХП
hp_cover – идти в укрытие или нет, в зависимости от ХП
hp_fight – разрешено воевать или нет, в зависимости от ХП
syndata – синхропары для красоты.
help_dialog – story_id диалога вместо дефолтного actor_help_wounded. Если вам по сюжету необходимо заменить диалог другим, то вы в этом поле прописываете id другого диалога.

Также мы вставляем стартовый диалог раненого. Если мы его прописываем, то все актёрские диалоги для раненых должны иметь такой precondition: dialogs.allow_wounded_dialog.

Пример. В качестве примера взята дефолтная настройка.
hp_state = 30|help_me@help|10|wounded_heavy@help_heavy
hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy
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
hp_victim = 30|actor|10|nil
hp_cover = 30|true|10|false
hp_fight = 30|true|10|false
syndata = wounded@help

Где:
best_pistol – проверка на то, что лучшее оружие НПС является пистолетом.

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

3.2.9. Схема rest

Чувак гуляет, хавает, спит. Пока нормально не работает.

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

 

3.2.10. Схема heli_hunter

Может стрелять, либо не стрелять по вертолету в зависимости от условий. Делается это так:
[camper@bar_freedom_attack_sniper_1]

path_walk = camper_1_walk
path_look = camper_1_look
on_info = {+bar_freedom_attack_ecolog} camper1@bar_freedom_attack_sniper_1 %=bar_freedom_angry_actor%
meet_talk_enabled = true
meet_dialog = bar_svoboda_dialog
heli_hunter = {-bar_ecolog_crush_heli_down} true, false

Если раньше оверрайд хелихантера понимал только значения true либо false, то сейчас он понимает кондлист, который если возвращает true - то стрельба по вертолету в данной схеме разрешена.

 

3.2.11. Patrol

Итак, есть предварительная система патруля. Представляет собой вариацию kamp только в состоянии ходьбы. Для ее работы прописываем в кустовой дате следующее:
[patrol]

path_walk = path_walk
path_look = path_look
formation = back
commander = true
move_type = ...
formation - описывет способ построения и не является обязательным. Возможны следующие варианты:
back - мужики идут чуть позади командира в два ряда (по умолчанию)
line - шеренга
around - вокруг командира
commander = true - типа назначат командиром, желательно, чтобы такой красивый он был один.
move_type = ... - задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib.

При остановке командора в meet мужики останавливаются.

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

ret=0...2
0 - линия
1 – вокруг старшего
2 – по бокам

При движении командор работает как обычный walker и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано a = assault, то командор помчится с орудием убийства на перевес, а остальные его откопируют.

Что еще не сделано или глючит:
нет возможности автоматически перестроить команду (нужно от Шурика то, что записано в todo листе)
все идут молча (когда будет манагер баек, то сделаем)
командор пока не отдает команд (нет озвучки)
не рекомендуется включать спринт (глючит).

 

3.3. Секции.
3.3.1. Секция combat

Показывает, что происходит, когда NPC срывается в бой.

on_combat = combat

[combat]
on_info = %+info -info =func% - эффекты, которые вызываются на каждом раунде боя.

Для задания различных типов скриптовых боёв для различных ситуаций используется параметр combat_type.

В следующем примере сталкер сражается:
по-кемперски, если враг = актёр и он дальше Х метров
по-монолитовски, если любой враг дальше Y метров
иначе - движковый бой
[logic]
active = walker
on_combat = combat

[walker]
path_walk = ...

[combat]
combat_type = {=fighting_actor =fighting_ge_X_meters} camper, {=fighting_ge_Y_meters} monolith

Пример такой функции: нам надо чтобы на расстоянии свыше 20 метров NPC переходил бы в кемперский комбат.
function fighting_dist_ge_20(actor, npc)
return db.storage[npc:id()].enemy:position():distance_to ( npc:position() ) >= 400
end

Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.

Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:
[logic]
active = nil
on_combat = combat

[combat]
combat_type = zombied

Если в разных секциях для персонажа требуются разные типы боя или разные условия, то можно воспользоваться оверрайдом combat_type. Помните: оверрайд всегда будет перекрывать настройку в секции combat. Т.е., если у вас логика на 5 секций и в четырёх нужен кемперский комбат, а в пятой монолитовский, то можно задать так:
[logic]
active = walker1
on_combat = combat

[walker1]
...
[walker2]
...
[walker3]
...
[walker4]
...
[walker5]
...
combat_type = monolith

[combat]
combat_type = camper
scheme - задает тип боя (monolith, camper, zombied), иначе - универсальный бой)
disable_combat_handler – функция отключающая секцию combat.

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

 

3.3.2 Секция death

Схема показывает, что происходит при смерти NPC.

on_death = death
[death]
on_info = %+info -info =func%

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

 

3.3.3. Cекция hit

Схема показывает, что происходит при нанесении повреждения NPC.

Причем on_hit не срабатывает на звук выстрела, только на попадание по сталкеру! Это сделано, потому что выстрел в воздух в общем случае не должен восприниматься как агрессия (игрок отстреливает, скажем, собак, а на него срывается охрана).

on_hit = hit
[hit]
on_info = %+info -info =func%

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

 

3.3.4. Секция actor_dialogs

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

actor_dialogs = actor_dialogs

[actor_dialogs]
id = ... - доступные диалоги через запятую.
disable = ... - запрещенные диалоги, тоже через запятую.

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

 

3.3.5. Секция use

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

on_use = use
[use]
on_info = %+info -info =func%

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

 

3.3.6. Секция combat_ignore

Если NPC в этой схеме то он не переходит в боевой режим. В любой другой схеме:

[walker]
combat_ignore_cond = {+info –info =func !func} – условия для игнорирования боя (если написать always, то в данной схеме игрок будет игнорировать бой всегда, пока не перейдет в схему, где бой не игнорируется).

В схеме нет дополнительных полей.
[walker]
combat_ignore = combat_ignore

[combat_ignore]

Функции, используемые для работы с кондлистом комбат игнора:
fighting_dist_ge_20 - текущий враг на расстоянии больше или равном 20 м.
fighting_dist_ge (х) – (х - расстояние в метрах)универсальная функция для combat_ignore, проверка расстояния для игрока.
fighting_actor - текущий враг - актёр?
check_fighting - проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка.

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

Авторы

Статья создана:
GSC Game World (оригинал)

[RUS_D]

Часть 2.

 

3.3.7. Секция dont_spawn_character_supplies

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

[dont_spawn_character_supplies]

 

3.3.8. Секция no_smart

Если прописана эта секция, то npc не берется под смарттеррейн даже если он походит по всем параметрам. [no_smart]

 

3.3.9. Секция treshhold

Есть возможность изменять у сталкеров параметры, по которым они атакуют монстров. Этих параметра два:
max_ignore_monster_distance (в данный момент дефолт 15 метров). Сталкер будет всегда атаковать монстров, которые находятся внутри данного радиуса.
ignore_monstre_threshold (в данный момент дефолт 0). Параметр от 0 до 1. Если функция оценки монстра ниже, чем этот параметр, и монстр находится за пределами вышеуказанного радиуса - он будет атакован. В данный момент все настроено так, что сталкеры вообще не атакуют монстров находящихся дальше чем 15 метров от них.

В секции логики либо в текущей схеме указываете:

threshold = threshold@tratata

[threshold@tratata] max_ignore_distance = ignore_monster =

Второй параметр следует менять ОЧЕНЬ осторожно.

 

3.3.10. Использование danger

Настройка может задаваться только в какой-то схеме, например:

[walker] danger = danger_condition

[danger_condition] ignore_distance = 50 (расстояние указывается в метрах) ignore_ distance_grenade = ignore_ distance_corpse = ignore_ distance_hit = ignore_ distance_sound =

Можно также указывать время ожидания для денжера в зависимости от типа:

danger_inertion_time_grenade = danger_inertion_time_corpse = danger_inertion_time_hit = danger_inertion_time_sound =

Дефолтовые настройки: danger_inertion_time_grenade = 20000 danger_inertion_time_corpse = 10000 danger_inertion_time_hit = 60000 danger_inertion_time_sound = 15000

NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.

Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.
В данный момент установлены следующие дефолты:
ignore_distance = 50
ignore_distance_grenade = 15
ignore_distance_corpse = 10
ignore_distance_hit = 50
ignore_distance_sound = 50

NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.
danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.
danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.

 

3.3.11. Байки из склепа (Истории у костра)

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

[game_info]
stories = "story_01, legend_01"

В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:

story_01 - Граница зоны и граната за 1 действие.
story_02 - Про трамплин и про камешки.
story_03 - Про то как группа Вильнова вернулась.
story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.
story_05 - Про то как духманам с контролером стражаться.
story_06 - Про дверцу, водку и избушку.
legend_01 - Про эксперимент в Зоне, который производят инопланетяне.
legend_02 - Об особо засекреченных лабораториях в зоне.
legend_03 - Легенда о проводнике.
legend_04 - Легенда о темном сталкере.
legend_05 - Легенда о том что глубоко в Зоне спать нельзя.

О, том какие истории и легенды в каком лагере на каком уровня можно и нельзя юзать, узнавать о Профа.

 

3.3.12. dont_spawn_loot

Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию [dont_spawn_loot]

 

3.4. Оверрайды

Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны):
meet_enabled = true (запускает схему встречи).
meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога).
meet_dialog = <название диалога>, который будет запущен при юзе.
meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли.
wounded_enabled = true (включает NPC возможность использовать схему раненого).
combat_ignore_cond = см. выше.
combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – только в случае стрельбы со стороны игрока!)
combat_type = {условие} scheme - тип боя, которым будет пользоваться NPC из данной схемы.
on_combat = см. выше.
companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).

 

3.5. Схемы для монстров.
3.5.1. Схема mob_walker.

Работает аналогично схеме обычного walker. Но есть некоторые отличия

Флаги пути движения s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic Флаги пути обзора: t=время_мсек - время в миллисекундах, которое нужно ждать, смотря в точку a=anim_set - анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn) В customdata персонажа задайте (* отмечены обязательные поля): [walker] path_walk = путь перемещения path_look = путь обзора
no_reset = true/false - не сбрасывать action предыдущей схемы (если нужно сохранить, например, звук). По умолчанию false.
actor_friendly = true/false - монстр никогда первым не нападает на игрока, но если игрок хоть раз атакует монстра - этот режим навсегда отключится. По умолчанию false.
npc_friendly = true/false - монстр никогда первым не нападет на другого монстра (даже враждебного).
friendly = true/false - монстр не нападает ни на игрока, ни на монстров. В случае агрессии с их стороны, не запоминает их как врагов и остается дружественным ко всем. По умолчанию false.

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

У кровосососов можно управлять невидимостью: [mob_walker]
...
state = vis
или
state = invis
Задает значение по умолчанию.
Также в флагах walk пути mob_walker-а можно использовать флажок b
(behaviour) с теми же параметрами:
wp00|b=vis
wp00|b=invis

 

3.5.2. Схема mob_eluder

Монстр перемещается по точкам патрульного пути (не учитывая связи между точками), держась на расстоянии от игрока, при этом придерживаясь своего пути, выходя из под схемы при слишком близком приближении к игроку, и возвращаясь обратно, когда расстояние увеличиться.
path = ... - работает как обычно path_walk. Набор точек патрульного пути.
Time_capture = ... (время в секундах) время, которое монстр находится под этой схемой. Default – 10.
Time_release = ... (время в секундах) время, которое монстр находится под универсальной схемой. Default – 10.
Min_dist = ... (расстояние в метрах, если расстояние до врага меньше этого, то он переходит под универсальную схему). Default – 5.
Max_dist = ... (расстояние в метрах, если расстояние до врага больше этого, то он переходит под eluder). Default - 10.

Замечание – работает нестабильно. Файл: \gamedata\scripts\mob_eluder.script .

 

3.5.3. Схема mob_remark

Ремарковая схема, только не для сталкеров, а для монстров.
state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)
dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога
anim = анимации монстра, перечисляются через запятую.
anim.head = анимации головы монстра, через запятую перечисляются
tip = какой значок подсветится, при наведении на него курсора
snd = какой звук издает
time = время проигрывания анимаций, используется только для отладки.

Файл \gamedata\scripts\mob_remark.script На этой схеме сделан торговец.

 

3.5.4. Схема mob_combat, mob_death

Работают точно также как и у сталкеров соответствующие схемы. Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script

 

3.5.6 Схема mob_jump (монстр-пружинка)

Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.

Пример:

[logic] active = mob_jump

[mob_jump] path_jump = path ph_jump_factor =2.8 offset = 0,10,0 on_signal = jumped | nil

path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset. offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде). ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8

Примечание: Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше. При выборе позиции используется первая точка патрульного пути (0-вой индекс).

 

3.5.7. Mob_camp

Механика:
1. Сидит на позиции, смотрит в точку
2. Можно задать несколько позиций и время смены позиции.
3. Перемещается между позициями бегом
4. При виде врага переходит под универсальную схему (комбат/паника и т.д)
5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции
6. Если враг уходит далеко - монстр возвращается на позицию

Использование:

[logic] active = mob_camp

[mob_camp] path_look = way_look path_home = way_home time_change_point = 30000 home_min_radius = 20 home_max_radius = 50 skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)

Описание параметров:
path_home - путь, состоящий из точек, в которых будет находиться монстр

path_look - путь, состоящий из точек, в которые будет смотреть монстр
time_change_point - время изменения текущей camp-точки (по-умолчанию10000), мс
home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м
home_max_radius - максимальный радиус от врага до camp-точки (по-умолчанию 40), м

Особенности:
Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.

Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.
Выбор текущей позиции производится случайным образом
Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)

Единственным необходимым параметром является path_look Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.

Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.

Обязательные требования: home_min_radius < home_max_radius Количество точек путей path_look и path_home должно быть равным.

P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами.

 

3.5.8. Mob_home

Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать.

Пример: [mob_home] path_home = path1 home_min_radius = 10 home_max_radius = 30 aggressive_home - в назначенную точку path_home монстры бегут а не идут.

Описание: Монстры держатся вокруг точек пути path_home. В атаке бросаются на врага, если враг внутри home_min радиуса, иначе прячутся в укрытия. Отсюда следует, что home_min -радиус желательно делать таким, чтобы внитри было достаточно каверов. В айдле тоже обычно расходятся по каверам. Home_max радиус сделан по принципу большого рестриктера в схеме «гнездо».

Добавлена возможность задания минимального и максимального радиусов для схемы mob_home в флагах первой точки пути (path_home). Для этого введены флаги minr и maxr. В случае, если радиусы заданы и в секции и во флагах, то значение радиуса берется из секции. Если не задано ни там, ни там, то берутся дефолтные значения 20 и 40 соответственно.

 

3.5.9. Mob_fake_death

Появилась схема mob_fake_death для зомби. Необходимо для сценок, когда игрок идёт, а вокруг него начинают подниматься зомби... Использование:

[logic] active = mob_fake_death

[mob_fake_death] on_actor_dist_le = 5 | nil

При входе в схему зомби падает, при выходе из схемы встает.

 

3.6. Оверрайды для монстров:
actor_friendly = если true, то монстр не атакует актера, до первой атаки на него
npc_friendly = если true, то монстр не атакует сталкеров и монстров, до первой атаки на него
friendly = если true, то монстр не атакует никого до первой атаки на него
braindead = если true, то монстр игнорирует любые атаки.

Секции для монстров [mob_death], [mob_hit]

 

3.7. Секция spawner

Эта секция, которая присутствует как у NPC, так и у монстров, спавнит их по определенному условию (выводит в онлайн). Для того, чтобы они появились в данной точке, им надо поставить в настройках в Level editor флажок no_move_in_offline и отключен can_switch_offline. Спавнер прописывается в кастом дату объекта перед секцией logic Работает spawner следующим образом:

[spawner] cond = {+info -info =func !func}

Примечание. Если условия спавна не будет выполняться, то объект не заспавниться, а если он заспавнился и условие перестает выполняться, то объект будет спавнером уведен в оффалйн. Пример: [spawner] cond = {=is_day} (объект заспавниться днем и уйдет в оффлайн ночью)

После того, как объект заспавнился, его берет под управление скрипт Logic

 

3.7.1. Спавн монстров дневных и ночных.

[spawner] cond = {=is_day} – спавнить монстра только днем (если надо ночью, то пишем {!is_day}) check_distance = true – проверка на наличие персонажа рядом. min_distance = 100 – если игрок ближе указанной дистанции, то монстр не заспавниться (по дефолту 150 метров, но на самом деле это много).

 

3.8. Скрипт logic

NB: если хотите заспавнить у npc что-то из вещей из custom data, то описание того, как это делается находится в Общей части в настройке профилей персонажей (только тег supplies писать не надо!)

Скрипт logic управляет переключением схем. В customdata любого персонажа (кроме свободных) должна присутствовать секция [logic].

Функции, на которые ссылается секция [logic] должны находится в файлах \gamedata\scripts\xr_effects.script или \gamedata\scripts\xr_conditions.script.

В секции должно присутствовать одно из полей: active = активная схема, запускающаяся первой. cfg = имя_ltx_файла_с_настройками

Если задано поле cfg, то в качестве настроек персонажа будет использовано содержимое указанного файла. Пример. Настройки простого walker-а:

[logic] active = walker

[walker] path_walk = walk1 path_look = look1

Переключение схем выполняется с помощью дополнительных условий схемы logic, которые прописываются в секции текущей активной схемы. Существуют следующие условия переключения: Список доступных схем перечислен в главе схемы. Примечание: если logic переключает между несколькими одноименными схемами (например несколькими walker), то их можно нумеровать (walker1, walker2) или через @ давать более информативные названия walker@day, walker@alarm и т.д.

on_actor_dist_le = number | scheme - дистанция до игрока <= number on_actor_dist_le_nvis = number | scheme - дистанция до игрока <= number без проверки на видимость on_actor_dist_ge = number | scheme - если дистанция до игрока > number on_actor_dist_ge_nvis = number | scheme - если дистанция до игрока > number без проверки на видимость on_signal = signal | scheme - срабатывает по приходу сигнала signal от текущей активной схемы on_info = scheme - срабатывает всегда on_timer = msec | scheme - срабатывает через msec мс после включения схемы on_game_timer = sec| scheme – срабатывает через sec секунд игрового времени, после включения схемы on_actor_in_zone = restrictor_name | scheme – если актер в зоне, (указывается имя рестриктора) on_actor_not_in_zone = restrictor_name | scheme – если актер не в зоне, (указывается имя рестриктора) on_npc_in_zone = npc_story_id | restrictor_name | scheme – если NPC в зоне, указывается story_id NPC, и имя рестриктора on_npc_not_in_zone = npc_story_id | restrictor_name | scheme - если NPC не в зоне, указывается story_id NPC, и имя рестриктора on_actor_inside = scheme - зона проверяет, находится ли игрок внутри нее on_actor_outside = scheme - зона проверяет, находится ли игрок за ее пределами

NB: с любыми из вышеперечисленных параметров можно работать следующим образом: on_info = {….} %...% on_info2 = {….} %...% on_info3 = {…} %...% и так далее до посинения

а также условия для переключения на описанные выше секции. combat_ignore_cond = on_hit = on_death = on_combat = on_use =

[RUS_D]

Часть 3.

 

3.8.1. Синтаксис скрипта Logic

Пример: для того, чтобы персонаж ходил по пути walk1, а при приближении игрока на дистанцию 5 метров, переключался на путь walk2 (но только при условии, что он видит игрока), нужно написать следующее:

[logic] active = walker1

[walker1] path_walk = walk1 path_look = look1 on_actor_dist_le = 5 | walker2

[walker2] path_walk = walk2 path_look = look2

Выше рассмотрено безусловное переключение секций. Перед именем секции в фигурных скобках {} можно задавать дополнительные условия, а после имени секции - так называемые "эффекты", которые заключить в знаки процента: %%. Эффекты будут применены только в случае активации секции. Можно не задавать имя секции, а задать только условия и/или эффекты. Тогда активной останется старая секция, но условия и эффекты будут все равно обработаны. Если все условия в фигурных скобках не выполняются, секция активирована не будет.

Пример:

on_actor_dist_le = 5 | {условие} walker2 %эффекты%

Условия могут быть следующими:

+infoportion - требуется присутствие infoportion у actor -infoportion - требуется отсутствие infoportion у actor =func - требуется, чтобы func вернула true !func - требуется, чтобы func вернулся false

Эффекты могут быть следующими:

+infoportion - в случае включения секции у actor будет установлен infoportion -infoportion - в случае включения секции у actor будет убран infoportion =func - в случае включения секции стартует функция func

Несколько условия или эффектов разделяются проблемами:

on_actor_dist_le = 5 | {+info1 -info2 +info3} walker2 %+info4 =func%

Можно задавать сразу несколько секций, разделенных запятыми. Порядок обхода при этом - слева направо. После срабатывания первого из условий, обход прекращается. В примере ниже, если установлен info1, будет включена схема walker2, иначе, если установлен info2, будет включена схема walker3, иначе будет включен walker4:

on_actor_dist_le = 5 | {+info1} walker2, {+info2} walker3, walker4

В описанном выше поле active секции logic, можно также задавать условия, например:

[logic] active = {=actor_friend} walker@friendly, walker@enemy В логических условиях теперь принимается ключевое слово never, которое означает, что условие ложно. Например: combat_ignore_cond = {=actor_enemy =actor_has_suit} always, {=actor_enemy} never %...эффекты...%

Вышеприведенная конструкция включает игнорирование боя, если у NPC враг - игрок в костюме, но отключит его, если врагом является игрок, но без костюма, при этом сработают эффекты (%%) секции never. Таким образом, выбор секции never равносилен отсутствию секции (несрабатыванию условия), но эффекты в знаках процента при этом срабатывают.

Пример работы с секцией nil. Секция nil выводит из-под скриптовых схем персонажа, монстра или объект и отпускает его под управление движка. Это надо если какое-либо условие выполнившись 1 раз больше не нуждается в проверке, при этом экономятся ресурсы машины, которые на каждом апдейте проверяют это условие.

[logic] active = sr_idle

[sr_idle] on_actor_inside = nil %+esc_actor_inside% То есть, при входе актера в рестриктор выдается инфопоршн и рестриктор уходит в секцию nil, больше не проверяя наличие игрока. NB: Обратно из секции nil под скрипты объект вернуть уже невозможно! Учитывайте это, используя ее.

3.8.2. Вот пример достаточно сложной логики:

[logic] active = walker combat_ignore = combat_ignore on_hit = hit on_death = death

[hit] on_info = %+alert%

[death] on_info = %+alert +trup3%

[walker] path_walk = walk_svoboda3 path_look = look_svoboda3 combat_ignore_cond = {-alert} on_timer = 25000 | remark

[remark] anim = idle snd = stalker_talk_kampfire no_move = true no_rotate = true on_hit = hit on_death = death combat_ignore_cond = {-alert}

[combat_ignore]

Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.

А вот логика его противника: [logic] active = walker combat_ignore = combat_ignore

[walker] path_walk = soldier_walk1 path_look = soldier_look1 combat_ignore_cond = always team = assault_group on_signal = assault | camper

[camper] path_walk = soldier_walk1_2 path_look = soldier_look1_2 radius = 5 on_info = {+trup1 +trup2 +trup3} walker2

[walker2] path_walk = soldier_walk1_3 path_look = soldier_look1_3

[combat_ignore]

Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).

3.9. Схемы логики space_restrictor

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

3.9.1. Схема [sr_idle]

Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы. Сама по себе схема ничего не делает. Пример настроек рестриктора:

[logic] active = sr_idle

[sr_idle] on_actor_inside = nil %+esc_actor_inside%

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

файл \gamedata\scripts\sr_idle.script

3.9.2. Секция [sr_no_weapon]

Данная схема убирает оружие у игрока при входе в зону. Пример настроек рестриктора:

[logic] active = sr_no_weapon

[sr_no_weapon]

файл \gamedata\scripts\sr_no_weapon.script

 

3.9.3. Секция [sr_sound]

snd = Перечень имён звуков разделенных запятыми.

type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.
delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.
idle = Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.
rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.
position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.
slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3
slide_sound_once = true\false

true - проиграть звук один раз, даже если он не дошел до последней точки пути. false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.
play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет
равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.

Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.

Поддерживается sound_end.

Обязательно нужно задать либо snd, либо type. Можно их задать вместе. На базе этих параметров составляется список звуков. При входе актёра в рестриктор отыгрывается случайный звук из этого списка.

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

Пример настроек рестриктора:

[logic] active = sr_sound

[sr_sound] type = floor_wooden snd = ambient\wind1, ambient\sparks1 rnd = 50 position = random idle = 120 delay = 3

Есть возможность сделать «скользящий звук». Необходим патрульный путь. Звук начинает отыгрываться с начала пути и перемещается от одной точки пути к другой (по мере их установки на патрульном пути) со скоростью slide_velocity.

[logic] active = sr_sound

[sr_sound] type = random position = way slide_velocity = 8 slide_sound_once = true

Файл \gamedata\scripts\sr_sound.script

 

3.9.4. Секция [sr_tip]

Предназначение данной схемы – давать игроку сообщение (подсказку) при входе в рестриктор

name = Название новости. type = по умолчанию «news» Тип новостей: «news» – отсылается как глобальная новость, «tips» - отсылается то имени sender-a
sender = если тип = «tips», то от sender задаёт условный строковый идентификатор иконки персонажа, от которого якобы пришло сообщение. По умолчанию это иконка торговца.
cond = Необходимые логические условия, при которых подсказка сработает. По дефолту, сработает при входе в зону.
single = true/false (по умолчанию false). Если параметр в true, то типс будет выдан только один раз,

Пример настроек рестриктора:

[logic] active = sr_tip

[sr_tip] name = tips_esc_trader_about_pda type = tips cond = {+infoportion1 –infoportion2 }
showtime = msec – время в миллисекундах, в течение которого сообщение будет находится на экране. – ПОКА НЕ РАБОТАЕТ НОРМАЛЬНО!

Если необходимо проиграть только 1 раз, а это случается часто, то можно добавить следующую строку: on_actor_inside = nil

файл \gamedata\scripts\sr_tip.script

3.9.5. Sr_light

Зона, в которой фонарики у неписей будут включены независимо от времени суток.

Работает следующим образом:
[logic]
active = sr_light
[sr_light]
light_on = true/false (свет включен/выключен)

Также работает вместе с кондлистом:
[logic]
active = sr_light
[sr_light]
light_on = true/false (свет включен/выключен)
on_info = {+info1} section %+info2%

3.9.6. Sr_territory

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

[logic] active = sr_territory@outside

[sr_territory@outside] on_actor_inside = sr_territory@inside

[sr_territory@inside] on_actor_outside = sr_territory@outside territory_hit = {-bar_dolg_territory_1_hit} %+bar_dolg_territory_1_hit%, {-bar_dolg_territory_2_hit} %+bar_dolg_territory_2_hit%, {-bar_dolg_territory_3_hit} %+bar_dolg_territory_3_hit% territory_death = {-bar_dolg_territory_kill} %+bar_dolg_territory_kill%

То есть здесь видно, что когда игрок находится внутри рестриктора, то считается количество нанесенных хитов, а также учитывается был ли кто-то убит или нет. Поскольку схема работает только с игроком – то хиты и смерть засчитываются только от игрока.

 

3.9.7. Sr_mapspot

При входе в рестриктор он сам себя подсвечивает на карте.

Параметры:
hint - id подсказки в string table (обязательный параметр)
location - название типа подсветки (не обязательный параметр, по умолчанию "crlc_small")

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

[sr_mapspot] hint = “gar_swamp” location = crcl_big

 

3.9.8. Sr_particle

Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:
Для партикловой системы с путем камеры:
[sr_particle]
name = explosions\campfire_03 -имя партикловой системы
path = particle_test.anm -имя пути камеры
mode = 1 (обязательно !!!)
looped = true/false -флаг зацикленности партиклов
(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.

Для партикловой системы с обычным патрульным путем:
[sr_particle]
name = explosions\campfire_03 -имя партикловой системы
path = part_points -имя патрульного пути
mode = 2 (обязательно !!!)
looped = true/false -флаг зацикленности партиклов

В вейпоинтах можно задавать флаг s=имя_звуковой_темы и d=число время задержки перед проигрыванием (задается в миллисекундах, если не задано, то 0). Далее, s - имя звуковой темы в sound_themes.ph_snd_themes из которой будет случайно выбран звук для проигрывания во время проигрывания партикла. Звук не зацикливается и играет только один раз... результат - партиклы отыгрываются во всех вейпоинтах одновременно (или с задержкой см. выше).

При looped=true по окончании проигрывания партиклов, они будут запускаться сначала, но уже без задержек. Сигнал particle_end выдаваться не будет. При looped=false сигнал будет выдан, когда все источники партиклов отыграют. Поддерживается кондлист. Если рестриктор переходит в другую секцию, то автоматически перестают отыгрываться партиклы и замолкают звуки при них. Этот рестриктор является объектом, отслеживающим партиклы и нет никакой необходимости чтобы игрок в него заходил.

3.9.9. Sr_sound_act

Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по PDA и прочие фейки.

[sr_sound_act]
snd = ambient\random\new_drone1 --имя звукового файла
delay = 2000 --задержка перед проигрыванием
delay_max = 4000 -- между проигрыванием звука будет взят случайный промежуток между delay и delay_max.
on_signal = sound_end | nil --по сигналу можно перейти в другую секцию.
theme = <имя темы из ph_sound_themes>
stereo = true/false (по умолчанию false). При установке этого параметра к файлу, который задан параметром snd или в звуковой теме будут добавляться (автоматически) суффиксы _r и _l для загрузки левого и правого каналов и, соответственно, вся эта фигня будет играться.

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

3.9.10 Sr_timer

Пример использования:

[logic] active = sr_timer@1

[sr_timer@1] type = dec start_value = 10000 on_value = 0 | sr_timer@2

[sr_timer@2] type = inc on_value = 15000 | nil %+info1%

Описания полей: type - тип счетчика, инкриментирующий(inc) или декриментирующий(dec). Если поле не задано - счетчик будет инкриментирующий start_value - начальное значение счетчика в РЕАЛЬНЫХ милисекундах. Для декриментирующих счетчиков задавать обязательно. Для инкриментирующих, если не задано, то считается с 0.

Переходы из секции sr_timer могут быть как по обычным условиям (on_timer, on_info) так и по специфическому условию on_value. В общем случае on_value Можно использовать для производства каких либо действий в зависимости от состояния счетчика. Например:

on_value = 5000| %+info1% | 1000| %+info2%

3.9.11. Sr_psy_antenna

Зоны с такой секцией позволяют управлять эффектами от пси-воздействия (на Янтаре и Радаре). Сейчас можно управлять интенсивностью излучения и интенсивностью получения повреждений.

Способ применения: Расставить зоны, в каждой зоне написать, сколько процентов к интенсивности излучения и повреждения она добавляет/отнимает. Зоны могут быть вложены друг в друга, пересекать друг друга.

eff_intensity = - увеличение/уменьшение в % от базового значения интенсивности излучения. hit_ intensity = - увеличение/уменьшение в % от базового значения наносимого повреждения.

Пример зоны, которая добавляет 70% излучения:

[logic] active = sr_psy_antenna

[sr_psy_antenna] eff_intensity = 70 hit_ intensity = 70

Пример зоны, которая убирает 30% излучения:

[logic] active = sr_psy_antenna

[sr_psy_antenna] intensity = -30

 

3.9.12. Sr_teleport

Собственно, телепорт. Настраиваются следующим образом:

[logic] active = sr_teleport

[sr_teleport] timeout = 0

point1 = point1 look1 = look1 prob1 = 10

point2 = point2 look2 = look2 prob2 = 20

где: timeout - задержка в срабатывании телепорта в миллисекундах. point - одноточечный патрульный путь куда переместить look - одноточечный патрульный путь куда повернуть.

Далее идут настройки точек назначения с удельными весами. То есть в перечисленном выше примере вероятность телепортнутся во вторую точку в два раза выше, чем в первую. Максимальное количество точек назначения - 10. Телепорты необходимо ставить совместно с особой аномальной зоной, которую сейчас делает Проф. Зона добавит визуализацию и создаст эффект втягивания.

 

3.9.13. Sr_sleep и настройка снов.

Появилась возможность задавать зоны сна.

[sr_sleep]
cond =
type = nightmare/normal/happy/all - Задает тип сна разрешенный в данной зоне (по умолчанию all). Влияет (группирует) только на несценарные сны.
dream_prob = <число от 0 до 100> - вероятность просмотра несценарных сновидений в данной зоне (по умолчанию 80). В противном случае будет только черный экран.

Необязательное поле cond задает условие(я), при котором в этой зоне можно спать. Сейчас производится индикация зон, где разрешен сон. В левом нижнем углу отображается маленькая иконка легких при входе в такую зону. Вероятно, позже будет изменена на другую. Сновидения теперь делятся на сценарные и обычные. Сценарные сновидения отыгрываются один раз при выполнении необходимых условий. Обычные сновидения проигрываются, если нет сценарных или ни одно условие выполнения сценарных не сработало. Можно задавать вероятность отыгрывания обычных сновидений в целом, а также задавать вероятность срабатывания каждого конкретного сновидения в отдельности. Обычным сновидениям можно задавать тип и потом ограничивать по нему сны воспроизводимые в sr_sleep.

В файле misc\dream.ltx задаются настройки снов.

Секция videos. Полями задаются пути к видеофайлам со снами.

Секция dreams. Поля: regular_probability = <число от 0 до 100> - вероятность проигрывания обычных сновидений в целом regular - список секций с настройками для обычных сновидений scene - список секций с настройками для сценарных сновидений

Настройки обычных сновидений: dream - имя поля из секции videos probability = <число больше 0> - чем больше, тем больше вероятность проигрывания сна. type = nightmare/normal/happy - тип сна.

Настройки сценарных сновидений: dream - имя поля из секции videos cond = - условия срабатывания to_regular = <вероятность,тип> - необязательное поле. Дает возможность переводить сценарный сон после первого отыгрыша в разряд обычных. <вероятность, тип> аналогичны probability и type из настроек обычных сновидений соответственно.

3.9.14. Sr_cutscene

Эта схема предназначена для проведения анимации камеры c некоторым эффектом (pp_effector). Последовательность действий, осуществляемых схемой, состоит из мгновенного перемещения игрока в начало пути point и ориентации его взгляда на начало пути look, потери управления игроком и начала анимации камеры cam_effector по завершении которой игрок вновь получает управление.

[sr_cutscene] point = <имя пути> - путь в первую точку которого переносится игрок look = <имя пути> - путь в первую точку которого смотрит игрок
pp_effector = <имя файла с эффектом> - файл, расположенный в папке

gamedata\anims\ и содержащий эффект (имя файла пишется без расширения) cam_effector = <имя файла с анимацией камеры> - файл, расположенный в папке gamedata\anims\camera_effects\ и содержащий анимацию камеры (имя файла пишется без расширения).

 

3.10. Набор дополнительных настроек логики у разных объектов.

Для всех физических объектов есть секция ph_idle, поддерживающая кондлист в которую можно при необходимости переводить объекты.

3.10.1. Схема работы двери, секция [ph_door]

NB! Для двухстворчатых ворот задается все аналогично.

locked = false\true Заперта ли дверь. По дефолту – false.

Closed = false\true Закрыта ли дверь. По дефолту - true

tip_open = (если locked == false, то tip_door_open, иначе tip_door_locked) Подсказка, которая появляется около прицела при наведении на дверь, если дверь закрыта.

tip_close = (если locked == false, то tip_door_close, иначе пустое значение) Подсказка, которая появляется около прицела при наведении на дверь, если дверь открыта.

snd_init = Звук, который будет отыгран сразу при включении схемы.

snd_open_start = Звук, который будет отыгран при попытке открыть дверь.

snd_close_start = Звук, который будет отыгран при попытке закрыть дверь.

snd_close_stop = Звук, который будет отыгран, когда дверь захлопнется до конца.

Примеры: Если нужно сделать дверь, которая при каком-то событии открывается со щелчком, то можно воспользоваться полем snd_init и переключением схем. В примере ниже при включении схемы ph_door@unlocked проиграется snd_init, т.е. trader_door_unlock:

[logic] active = ph_door@locked

[ph_door@locked] locked = true snd_open_start = trader_door_locked on_info = {+esc_trader_can_leave} ph_door@unlocked

[ph_door@unlocked] locked = false snd_init = trader_door_unlock snd_open_start = trader_door_open_start snd_close_start = trader_door_close_start snd_close_stop = trader_door_close_stop файл \gamedata\scripts\ph_door.script .

3.10.2. Схема работы кнопки, секция [ph_button]

При нажатии на кнопку переключает секции и выдает инфопоршн.

[logic] active = ph_button@locked

[ph_button@locked] anim_blend = false anim = button_false on_press = ph_button@unlocked %+cit_jail_door_opened%

on_press – что происходит при нажатии anim – анимация, которая отигрывается при нажатии на кнопку anim_blend – плаваня, сглаженная анимация. Может принимать знаечения true\false

Файл \Gamedata\scripts\ph_button.script
tooltip - gредназначено для того, чтобы задавать текстовую подсказку при наведении на кнопку. Текстовая подсказка нужна для того, чтобы как минимум было понятно, что этот девайс можно нажимать.

Пример настройки кнопки:

[logic] active = ph_button@active

[ph_button@active] anim = lab_switcher_idle tooltip = tips_labx16switcher_press on_press = ph_button@deactivated %+terrain_test%

[ph_button@deactivated] anim = lab_switcher_off

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

Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)

Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:

[logic] active = ph_button@locked

[ph_button@locked] anim = button_false – анимация несрабатывания кнопки. on_info = {+val_prisoner_door_unlocked} ph_button@unlocked on_press = ph_button@unlocked %+val_prisoner_door_unlocked%

[ph_button@unlocked] anim = button_true on_info = {-val_prisoner_door_unlocked} ph_button@locked on_press = ph_button@locked %-val_prisoner_door_unlocked%

 

[RUS_D]

Часть 4.

 

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

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

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

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

 

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

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

[logic] active = ph_code@lock

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

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

 

3.10.5. Ph_gate:

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

closed - в закрытом
- в текущем (дефолтном или оставшемся от предыдущей схемы)

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

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

- не используется (мягкая блокировка возможна только в крайних положениях)

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

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

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

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

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

[ph_gate@opened] state = opened locking = stick

[ph_gate@closed] state = closeded

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

 

3.10.6. Ph_sound

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

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

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

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

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

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

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

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

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

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

 

3.10.7. Ph_force

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

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

 

3.10.8. Ph_on_death

Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов
Пример:
[logic]
active = ph_on_death
[ph_on_death]
on_info = %эффекты%
Юзать исключительно с разрушаемыми физ.объектами.

 

3.10.9. Ph_car

Настройка возможности игроку управлять машиной.
секция: [ph_car]
поле: usable =
usable - кондлист возвращающий true (по умолчанию) или false.
Пример:
[logic]
active = ph_car
[ph_car]
usable = {+val_actor_has_car_key}

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

 

3.10.10. Ph_heavy

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

[ph_heavy]

 

3.10.11. Ph_oscillate

Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)
Пример логики
[ph_oscillate]
joint = provod - имя кости к которой будет применена сила
force = 5 - собственно сила (в ньютонах)
period = 1000 - время прикладывания силы.
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.

 

3.11. Смарттерейны и гулаги.
3.11.1. Смарттеррейн.

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

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

Параметры custom data:
[gulag1]

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

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

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

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

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

 

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

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

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

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

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

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

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

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

Пути: search_walk, search_look

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

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

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

 

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

[RUS_D]

Продолжение 4 части.

 

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

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

 

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

 

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

 

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

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

 

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

В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.

 

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

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

 

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

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

 

--' Garbage maniac if type == "gar_maniac" then t = { section = "logic@gar_maniac_camper", idle = 0, prior = 5, state = {0}, squad = squad, groups = groups[1], in_rest = "", out_rest = "", info_rest = “” } table.insert(sj, t) t = { section = "logic@gar_maniac_sleeper", idle = 0, prior = 5, state = {1}, squad = squad, groups = groups[1], in_rest = "", out_rest = "", info_rest = “” } table.insert(sj, t) end

 

Описание полей: Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль. Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет. In_rest, out_rest - рестрикторы, которые устанавливаются персонажу на данное задание. Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx, где указываются реальные настройки схемы поведения, которая соответствует текущей работе. Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1. Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например:

predicate = function(obj)
return obj:profile_name() == "soldier_commander”
end

то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.

 

8. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:

----------------------------
-- GARBAGE MANIAC
----------------------------
[logic@gar_maniac_camper] active = camper@gar_maniac_camper
[camper@gar_maniac_camper] path_walk = walk1 path_look = look1
[logic@gar_maniac_sleeper] active = sleeper@gar_maniac_sleeper
[sleeper@gar_maniac_sleeper] path_main = sleep wakeable = true

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

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

 

3.11.3. Новые особенности смарттеррейнов

Возможности нового смарттеррейна (СТ):

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

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

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

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

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

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

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

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

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

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

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

Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:

predicate = function(npc_info)
return npc_info.is_sniper == true
end

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

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

t = { section = "logic@ЧЧЧЧЧЧЧЧ",
idle = 0,
prior = 5, state = {0}, squad = squad, group = groups[1],
online = true,
in_rest = "", out_rest = ""
} table.insert(sj, t)

Варианты задания этого поля online = true - на этой работе персонаж всегда в онлайне, online = false - на этой работе персонаж всегда в офлайне, online не задано - на этой работе персонаж может прыгать онлайн<->офлайн по своему усмотрению. 3.11.3.1. Более доступное описание новых смарттеррейнов Теперь о смарттерейнов для дизанеров, то есть не на LUA, а по-русски. Для того, чтобы пренести смарттеррейн на новую схему, делаем следующее: 1. Пишем в кастом дате где [gulag1] -> [smart_terrain] 2. В кастом дате товарищей по смарттеррейну пишем [smart_terrains] sar_monolith_sklad(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true. Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату:

[smart_terrains]
none = true

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

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

Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.

 

3.12.1. Схема heli_move:

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

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

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

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

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

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

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

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

Настройки:
engine_sound = true/false (по умолчанию true)

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

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

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

Отключает универсальные реплики пилотов вертолета.
rocket_delay = msec (время в миллисекундах реального времени)

Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)
default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

Настройки:

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

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

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

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

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

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

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

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

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

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

 

3.13. Meet_manager

Синтаксис:

[logic] meet = meet

[walker] meet = meet

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

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

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

Для облегчения настройки встречи сделана возможность упрощенного задания дефолта:
[walker]
meet = default_meet
Саму секцию [default_meet] задавать не надо. Все настройки и так возьмутся из дефолта.

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

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

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

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

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

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

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

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

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

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

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

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

meet = no_meet

[RUS_D]

4 часть. Окончание.

 

3.14. Отметки на минимапе

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

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

[walker] show_spot = {+info1} false

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

3.15. Передача параметров в функции.

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

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

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

xr_conditions:

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

distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного
story_id.

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

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

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

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

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

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

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

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

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

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

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

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

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

xr_effects:

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

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

hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:
direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число, то оно рассматривается как story_id персонажа от которого должен поступить хит.
bone - строка. Имя кости, по которой наносится удар.
power - сила удара
impulse - импульс
reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.

Пример: [death] on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%

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

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

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

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

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

Функции для работы с HUD'ом.
disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.

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

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

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

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

Функция запуска camera_effector'а.
run_cam_effector(имя_файла)

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

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

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

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

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

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

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

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

 

[RUS_D]

                                             НАРОДНАЯ СОЛЯНКА

                                 ==========Обьекты в игре =========

 

 

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

Онлайновый и офлайновый объект - это экземпляры разных классов.
Онлайновый - это экземпляр класса game_object, открываем lua_help и
смотрим какие методы и свойства определены для этого класса:

class game_object {
...
function section () const;
function name () const;
function id () const;
...
}

Офлайновый (для сталкера) - это экземпляр скриптового класса se_stalker (se_stalker.script),
порождённого от портированного в LUA класса cse_alife_human_stalker, открываем lua_help и
смотрим какие методы и свойства определены для этого класса:

class cse_alife_human_stalker : cse_alife_human_abstract,cse_ph_skeleton {
...
property id;
...
function section_name (const cse_abstract*);
function name (const cse_abstract*);
...
}

Доступ к функциям класса: <объект> : <имя_функции> ( <параметры> )
Доступ к свойствам класса: <объект> . <имя_свойства>

=========== "глупые вопросы" ===========

 

 

1. Что такое спэйсрестрикторы ?
1. Рестрикторы это зоны, в логике которых можно например прописывать определенное действие
или выполнение функции при попадания ГГ внутрь. Также повсеместно (в игре) применяется для
огрничения перемещения НПС. Т.е. либо не позволяет проникать в эту зонку, либо наоборот
выходить из нее. Размер рестриктора задается определенным шейпом.
2. Что такое смарттеррэйны ?
2. Смарттерейны это другие зонки, похожие на рестрикторы, но обладают лишь одной функцией.
А именно попадая в данную зонку любой НПС (при условии что подходит по параметрам) отправляется
на работу. Работа и условия прописываются в файлах вида gulag_escape.script, а сама логика в
файлах вида gulag_escape.ltx (вместо escape может быть имя любой локации)
3. Для чего нужны триггеры ? и что это такое ?
3. Триггер насколько я знаю это переключатель, в основном реализуется на рестрикторах
4. Что такое Нетпакеты ?
4. Это один из классов портированных в LUA. При его помощи можно скриптом прочитать и изменить множество
параметров игровых объектов. Параметров, просмотр и редактирование которых не были предусмотренны разработчиками.
5. Апдейт ГГ (актора), что это такое ?
5. Апдейт актора - это обновление функций происходящее в определенный момент времени. Любая функция
повешенная на апдейт будет выполнятся каждый раз, когда он происходит.
6. Что такое Серверный и Клиентские объекты ?
6. Серверный и клиентский - это оффлайновый и онлайновый состояния объекта.
Для любого игрового объекта предусмотрены два класса, экземляр серверного класса существует всегда,
экземляр клиентского класса создаётся при переходе объекта в онлайн, а при выходе из онлайна удаляется.
7. Что такое CLSID ? понимаю, что это ID какойто, но какой ?)))
7. clsid - это id определенного класса объекта, у каждого объекта есть определенный класс, они описаны в lua_help.script
Разные типы игровых объектов имеют разные серверные и клиентские классы. CLSID - это 'тип' объекта, некая константа определённая для набора классов привязааных к строке class в секции спавна.
9. lua_help.script - для чего нужен ? как им пользоваться ? как запускать ?
9. lua_help.script написан разработчиками скорее всего для облегчения своей задачи, насколько я знаю в игре он не используется.
10. Допустим существует такая конструкция:
local obj,sim
sim = alife()
obj = sim:create(....)
alife() - Это класс ? sim - его экземпляр ? И что обозначает ":" (двоеточие) ?
10. alife() - это функция (есть в lua_help),
возвращает она 'указатель' на существующий экземпляр класса alife_simulator (есть в lua_help), по-простому :
Далее движок будет при нахождении в функции слова sim интерпретировать его как alife()
":" (двоеточие) ставится при вызове функции класса.
11. Допустим есть условие:
if obj then .......... end
Что обозначает "if obj" ? всмысле после переменной obj не стоит никаких операторов "=,<,>", Как это работает ?
11. if obj then это условие, буквально означает "если условие принимает такое знасение, то...", дальше обычно следует true либо false, обратное условие - это else. Так можно сделать проверку obj ~= nil или obj ~= false.
Возможно, я в чем то и ошибся, хотя и изучал lua более двух лет, но в Сталкере функции немного различаются.
Сам в течении последней недели, как начал заниматся функциями Сталкера еще не разобрался.
12. Что такое Self ? указатель ? и когда его используют ?
self означает обращение к собственным функциям и переменным класса.
Если мне не изменяет память, то паскалевский аналог - this.
13. А не подскажите что такое Callback ? Вот например у АМК:
--Callback на старт игры
function start_game()
end
--Callback на смерть монстров
function monster_death(victim, who)
end
13. В игре есть возможность обвязать скриптами онлайновый объект, делается это с помощью binder-а. Для разных типов объектов
используются разные обвязки, какая именно будет использоваться, определяется строкой script_binding в секции спавна объекта.
После создания и привязки binder-а различные его функции начинают вызываться движком. Изначально движок вызывает только
несколько основных функций binder-а: net_spawn, net_destroy, update и т.д. Но можно 'попросить' движок вызывать и другие
функции, делается это с помощью функции set_callback:
: set_callback( <условие>, <функция> )
<условие> - условие при котором должна вызваться функция
<функция> - имя вызываемой функции
Условия - это константы, которые можно посмотреть в файле lua_help (class callback)
Обычно установка всех колбеков производится единым блоком при инициализации binder-а.
При деинициализации binder-а делается обратная операция, сброс колбеков.
Если коротко, то с помощью колбэка можно сделать определенные действия для некоторого обьекта при выполнении заданного условия.
Это заготовки из amk_utils.script. Они вызываются соответствующими колбэками. Пока они пустые, то есть, не делают ничего
при вызове, так как в данной версии мода не нужно производить никаких действий при выполнении соответствующих условий.
Если авторам мода нужно будет сделать что-нибудь после смерти монстра, достаточно будет написать это в функцию monster_death,
эта функция уже вызывается колбэком на смерть монстра. victim - это жертва, то есть, обьект дохлого монстра, а who - это обьект,
который этого монстра замучал, к примеру ГГ, эти параметры передаются в вызываемую функцию при срабатывании колбэка.
start_game() - функция, которая вызывается при начале игры.
14. какая функция вызывается при смерти квестовокго персонажа, т.е. дает инфопоршн в задании типа "убить сталкера" ?
14. Периодически вызывается функция task_complete из файла task_manager.script, которая для таких заданий проверяет жив ли ещё npc.
15. А имя гулага, куда дожен входить смарт, нужно прописыват в кастом дату самого смарта ?
15. Давайте по порядку.
Есть игровой объект - smart_terrain.
Когда он создаётся запускается определённый скрипт, который создаёт для смарта некий програмный объект - gulag.
Все объекты gulag работают по одним и тем же алгоритмам, т.к. это один програмный класс. Отличаются гулаги друг от друга своими
данными: работы, состояния и пр. Конкретные данные для конкретного гулага/смарта получаются по неким 'шаблонам'.
Шаблоны - это то, что лежит в файлах gulag_xxx.script. Для большего удобства они разбиты по уровням, но местоположение
(файл) не играет особой роли. Некоторые шаблоны используются только для одного гулага/смарта, тогда как другие могут
использоваться для множества гулагов/смартов ( например "general_lager" ).
Привязка шаблона к гулагу смарта осуществляется через custom_data смарта, там прописываются такие строки:

[smart_terrain]
type = <имя шаблона>

Что конкретно вы хотите сделать?
- хочу к имеющемуся смарту приписать гулаг. Гулаг состоящий из одного сталкера. Днем что бы он был walker, а ночью сидел у костра.
Т.е. смарт вы новый добавили через all.spawn? Пусть он называется esc_new_lager.
1) Пропишите в all.spawn своему смарту такую custom_data:

custom_data = < [smart_terrain]
type = esc_new_lager
capacity = 1
END

2) Пропишите в all.spawn два пути: один из нескольких точек для схемы walker (esc_new_lager_npc1_walk),
другой из одной точки (центр кампа) для kamp (esc_new_lager_npc1_kamp)

3) Откройте файл config\misc\gulag_escape.ltx и добавьте в самый конец работу для своего сталкера:

[logic@esc_new_lager_npc1]
active = walker@esc_new_lager_npc1

[walker@esc_new_lager_npc1]
path_walk = npc1_walk
on_info = {!is_day} kamp@esc_new_lager_npc1

[kamp@esc_new_lager_npc1]
center_point = npc1_kamp
on_info = {=is_day} walker@esc_new_lager_npc1

4) Откройте файл gulag_escape.script и добавьте в него:

4.1) в функцию load_job

if type == "esc_new_lager" then
t = { section = "logic@esc_new_lager_npc1",
idle = 0,
prior = 5, state = {0},
online = true,
in_rest = "", out_rest = ""
}
table.insert(sj, t)
end

4.2) в функцию load_states

if type == "esc_new_lager" then
return function (gulag)
return 0
end
end

4.3) в функцию checkStalker

if gulag_type == "esc_new_lager" then
return npc_community == "stalker"
end

Вроде, всё.

16. Создаю смарттеррейн на Кордоне.
Если делать его под сталкеров, то созданные мной сталкеры идут туда и выполняют работы, далее меняю этот смартеррейн
для своей вновь созданной группировки (снайперы), прописываю вновь созданным снайперам этот лагерь, но они туда не идут.
Так вот всвязи с этим вопрос: Есть ли ограничения на создания смарта на Кордоне? Напрмер, могу ли я создать смарт для монолитовцов?
16.При поиске/выборе смарта для сталкера проверяются некие пресеты. Если проверка пресета смарта не прошла, то сталкер не принимается в этот смарт (правда там вроде бы исключение стоит для эксклюзивных персонажей). Пресеты лежат в файле:
"misc\smart_terrain_presets.ltx", загружаются и проверяются в "smart_terrain_presets.script". Если в custom_data смарта отсутствует явное указание пресета ( preset = <имя пресета> ), то <имя пресета> считается равным названию уровня, это видно из кода smart_terrain.script:

function se_smart_terrain:register_if_needed()

Попробуйте добавить свой пресет в ltx и прописать его смарту.
Спасибо большое, добавил свой пресет и помогло.
Если можно один маленький вопрос: Рядом со смартом сделал респавн этих снайперов. Так вот вопрос они после спавна идут
в этот лагерь, а что будет если например для них не будет хватать работы в этом лагере(в лагере прописано 7 работ),
может быть такое, что их будет например 8 человек и тогда куда пойдет лишний?
Если вы не прописывали такие строки в custom_data спавнимых сталкеров:
[smart_terrains]
none = true 

или
respawn_check = false
то ваш респавнер не должен спавнить сталкеров больше, чем есть рабочих мест в гулагах.
17. вопрос - как сделать аномалии невидимыми ?
17. В папке \gamedata\config\misc\ ищи файлы отвечающие за интересующую тебя аномалию (например грави - zone_gravi.ltx)
в файле найди строку idle_particles = anomaly2\gravity_idle и закомментируй ее. Что бы отключить еще и звуковое
оповещение, надо visible_by_detector установить в off

 

============ сетевой пакет ============

 

ret = amk.read_stalker_params(npc)
ret.money
ret.profile
ret.infammo
ret.class
ret.communityid
ret.rank
ret.reputation
ret.charname
ret.g vid
ret.lvid
ret.oflags
ret.custom
ret.sid
ret.baseoutr
ret.baseinr
ret.smtrid
ret.smtrtaskactive
ret.team
ret.squad
ret.group
r et.health
ret.killerid
ret.game_death_time
ret.visual

оружие (как и всё остальное) может иметь два объекта: серверный и клиентский.
Переопределяя нет-пакеты STATE-ми и UPDATE-ми мы изменяем только серверный объект.
Клиентскиё же создаётся на базе серверного в момент перехода оружия в онлайн.
Если клиентский объект уже создан, то он содержит в себе дупликаты всех необходимых
ему данных из серверного. Т.е. переопределяя нет-пакеты серверного объекта мы не
можем повлиять на уже созданный клиентский.

А как узнать, какие пакеты (packet:w_u16,packet:w_s32) есть у сталкеров ?
Лучше всего по исходникам acdc. w_u16, w_u8 - это функции записи в нет-пакет.
w_u16 - записывает 16-и битное беззнаковое (от 0 до 65535)целое,
w_s16 - знаковое (от -32768 до 32767)
w_u8 - записывает 8-и битное беззнаковое целое,
u32 - лучше не использовать, глюк какой-то вроде есть, используйте s32.
w_stringZ исп. для записи текста, w_vec3 для работы с векторами...
l32u16v - это массив переменной длинны, первым лежит число элементов 32 бита (r_s32),
далее лежат сами элементы по 16 бит (r_u16).
Что бы прочесть всё это нужно вызвыть несколько функций, готовой функции у
net_packet-а для чтения такого массива нет.
u8v8 - это массив фиксированной длины, 8 элементов, каждый элемент 8 бит (r_u8).
Готовой функции у net_packet-а для чтения нет.
f32v3 - это массив фиксированной длины, 3 элемента, числа с плавающей точкой.
Можно прочесть вызвав три раза r_float или один раз вызвать r_vec3.
w_tell() - возвращает текущую позицию записи (сколько записано)
r_tell() - возвращает текущую позицию чтения (сколько прочитано)
packet:w_tell() - packet:r_tell() - разница между записанным и прочитанным

полный список функций смотрите в lua_help.script для класса net_packet.

Данные в нет-пакет последовательно складываются в некий буфер и точно так же достаются от туда.
Чтобы правильно прочесть данные упакованные в нет-пакет нужно точно знать последовательность упаковки
(какая переменная за какой) и точно знать тип каждой переменной. Данные, которые лежат в net_packet-е,
предназначены в первую очередь движку, а не скриптам. Движок имеет жёстко зашитую функцию разбора net_packet-а.
Это значит, что он выбирает данные теми функциями, которые у него прописаны. Если мы положим в net_packet некое
u16 (вместо u8), то движок всё равно прочтёт u8 и это приведёт к сдвигу оставшихся данных на один байт, т.е. все
последующие данные считанные движком будут не верны. Какой функцией писать данные 8, 16 или 32 зависит от функций
чтения движка. Писать нужно только то (и так), что потом правильно прочтётся.

Всё это можно узнать дезассемблированием движка (и не только), врядли вы захотите этим заниматься, поэтому лучше
воспользоваться трудами человека,который это уже сделал. bardak разобрал все исходные параметры для всех объектов
и сделал их чтение/упаковку в утилите acdc. Если посмотреть исходник утилиты, то там можно увидеть какие данные
и как упаковываются.
bardak : не используйте результат декомпиляции для задания параметров, смотрите код последней версии acdc (декабрьской 2007).

Если это кажется сложным, то есть код в АМК (про который я говорил раннее), сделанный на основе acdc. Но помимо
исходных данных из acdc, объекты уже созданные в игре могут содержать дополнительные данные, которые так же
желательно сохранить при перепаковке (реализовано в АМК). Еще неписям в онлайне бесполезно перезаписывать net_packet,
требуется их перевод в офлайн (реализовано в АМК).

И вопрос в догонку, изменяя параметры с помощью нет пакета, обязательно писать все параметры, или можно обойтись только нужным?
Читать/писать нужно все параметры, но можно сначало прочесть всё, изменить только то, что нужно и записать всё это обратно.
Общий алгоритм должен быть таким:
1) чтение нет-пакета (STATE_Write или UPDATE_Write)
2) разбор нет-пакета (p1=r_xxx() p2=r_xxx() ...)
3) переопределение нужных параметров (pN=x pM=y ...)
4) упаковка всех данных в нет-пакет (w_xxx(p1) w_xxx(p2) ...)
5) запись нет-пакета (STATE_Read или UPDATE_Read)

 

 

[RUS_D]

                                                ========== Логика NPC ==============

 

SpeCtrelok : Как работают gulag? Есть нормальная статья на тему поведение NPC

IG-2007 : Есть вот такая статья: "Настройка логики".
http://www.stalkerin.gameru.net/wiki/index.php/Настройка_логики
Часть 1.
3.2. Схемы поведения сталкеров.

Часть 2.
3.8. Скрипт logic

Часть 4.
3.11. Смарттерейны и гулаги.

 

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

Если в общих чертах, то...

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

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

Логика для персонажа.
Логика задаётся жестко, на этапе разработки персонажа. Чтобы задать логику персонажу нужно в
файле с секцией его спавна добавить строчку "custom_data = <ссылка на файл с логикой>".
Например, в файле "spawn_sections.ltx" есть вот такая секция:
[pri_respawn_dolg]:stalker
...
custom_data = scripts/pri/pri_respawn_custom_data_dolg.ltx

Как видно, логика данного сталкера лежит в файле "pri_respawn_custom_data_dolg.ltx". Вот его содержимое:

[logic]
active = patrol1
[patrol1]
path_walk = pri_dolg_respawn_walk1
path_look = pri_dolg_respawn_look1
formation = line
[smart_terrains]
none = true

Не густо, но для начала нам хватит. Рассмотрим только то, что нам важно.
Секция [logic] - эта секция используется как отправная точка для задания логики.
"active = patrol1" - active отправляет нас в самую первую схему поведения.

Одна схема поведения описывается одной секцией в файле.
Итак, что же это за схема поведения? Схема поведения зашифрована в названии секции.
Допускаются следующие названия: "SCHEME .. num" или "SCHEME .. @user_name".
Таким образом в данном случае задана схема патрулирования. В секции [patrol1] есть ещё
некоторые параметры, они нужны для работы схемы, для каждой схемы возможен свой набор
параметров. Помимо этого в секции могут быть прописаны универсальные вещи, приемлимые для всех схем.

Условия перехода от одной схемы к другой.
Для каждой схемы (секции файла) прописываются возможные переходы на новые схемы.
Обычно переключение схем привязывается к определённым событиям. Эти события могут быть
событиями схемы (например, завершение анимации) или могут быть глобальными событиями
(например, появление определённого инфопоршена). Пример переключения по глобальным событиям,
фрагмент из файла "agr_krot.ltx":

[walker@hold]
...
on_info = {!actor_enemy agr_krot_skirmish_start} walker@combat
on_info2 = {!actor_enemy agr_help_stalkers_done} walker@hold2

Допустим, сталкер сейчас находится в секции [walker@hold]. Если условие {!actor_enemy agr_krot_skirmish_start}
выполнится, то произайдёт переключение на новую секцию [walker@combat].
А если выполнится условие {!actor_enemy agr_help_stalkers_done}, то произайдёт переключение на секцию
[walker@hold2].
Для проверки глобальных условий используется "on_info .. num". Это универсальная проверка, она может
использоваться для любых схем. Сама проверка выполняется периодически, до тех пор пока схема будет активна.
Используя условия и переходы от одной секции к другой можно создавать весьма гибкую логику: можно её ветвить,
можно зациклить и т.д.

Логика для гулага.
Логика задаётся в одном файле для всех потенциальных членов гулага. Формат файла логики практически совпадает
с форматом для сталкера, те же секции с описанием схем. Последовательность схем предназначенная для одного
персонажа гулага называется работой. Когда в гулаг приходит новый сталкер ему назначается определённая работа.
Вся логика лежит в файлах "misc/gulag_<имя гулага>.ltx". Для формирования работ и многих других вещей используется
файл "gulag_<имя гулага>.script". Помимо методов перехода логики от секции к секции, описанных выше, для гулагов
предусмотрен ещё один механизм. Гугал может иметь несколько состояний и каждая работа может иметь несколько состояний.
При переключении гулага из одного состояния в другое (например смена дня и ночи) можно произвести принудительное
переключение работ на новые секции.

PS: Есть глобальные схемы, которые включаются при наступлении определённых игровых событий (бой, встреча с ГГ, ...).

PPS: Есть ещё схемы, предназначенные для монстров, для не живых объектов...

SpeCtrelok : С этого момента поподробнее

 

IG-2007 : Монстры.
Им тоже можно задовать последовательности схем. Только схемы у них свои.
Неживые объекты.
Тоже можно задовать последовательности. Схемы опять же свои.
Например, можно добавлять озвучку для предметов или зоны, где запрещено пользоваться оружеем.

patch_walk = (название) - где задать куда эта точка ведёт???
Это не точка, это имя последовательности точек. Сама последовательность лежит в all.spawn в секции [имя пути].
Для задания своего пути нужно добавить в all.spawn свою последовательность точек. Где взять координаты необходимых
точек? Без специального редактора, в котором можно было бы их просто натыкать на карте, это будет не просто.
Проще попытаться найти наиболее подходящий путь, уже сделанный разработчиками и указать его, хотя это тоже не просто.

А как с помощью дилога заставить сталкера сидеть у костра, пойти куда-то
То есть с помощью диалога активировать схему поведения
Не знаю на сколько корректно просто задовать сталкеру схему и не задовать при этом логику, наверно так не очень
правильно. Поэтому напишу, как это можно сделать при помощи логики.
Например, есть сталкер с некой custom_data. В ней прописаны секция со схемой сидения у костра и две секции со
схемами перемещения в разные места.
[kamp1]
on_info = {(plus)goto_first_place} walker1, {(plus)goto_second_place} walker2
...
[walker1]
...
[walker2]
...

В диалоге с персонажем пропишем:

Шёл бы ты...
goto_first_place
goto_second_place
1001


Куда?
10011
10012


На Кудыкину гору.
goto_first_place
dialogs.break_dialog


К Сидоровичу, у него дело к тебе есть.
goto_second_place
dialogs.break_dialog

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

SpeCtrelok :всё сделал
Заработало, сталкеры у костра пошли спать
Потом немного изменил так, чтоб они пошли к лагерю бандитов или к блокпосту и при разговоре игра вылетела (когда я дал команду)

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

-А может это из-за рестриктов, есть такие штуки - 'space_restrictor'-ы, которые могут использоваться для ограничения
доступной области перемещения.
Скорее всего.. Эти рестрикторы случайно не в all.spawn?
А если там, то как их редактировать, чтоб например они на весь кордон были?

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

1) Во многих схемах при определении точки назначения используется функция ,
проверяющая доступность точки.
2) Вот картина таких точек для сталкера из лагеря новичков на Кордоне.
http://i012.radikal.ru/0712/8a/9ff5136b96e6.jpg
3) Если посмотреть скрипт гулага "gulag_escape.script", то можно там увидеть такие строчки:

--' Лагерь новичков на Escape
-- у костра днём
t = { section = "logic@esc_lager_kamp1",
idle = 0,
prior = 6, state = {0},
in_rest = "", out_rest = "esc_lager_guard_kill_zone"
}

(vertex_id)>(vertex_id)> Для данной работы (и не только для этой) сталкеру накладывается ограничение на возможное перемещение в виде рестрикта.
Возможно, что при попытке вывести сталкера за пределы данного рестрикта и происходит вылет.
Можно для начала попробывать убрать ограничение из работы: out_rest = "". (vertex_id)>

Ещё возможно, что дело не в рестрикте, а в ошибочном задании пути.

Есть ещё какие-то терейны. Как используются они - не знаю.
Пример из "m_stalker.ltx":

[stalker_terrain]
255,000,255,255
008,001,255,255 ;Разрешено ходить по опасным местам на баре
012,001,255,255 ;Разрешено ходить по опасным местам на Милитари

1. NPC всегда действует под управлением какой нибудь схемы?
- Да.
2. Как взаимодействуют разные схемы, могут ли быть активными сразу несколько схем для одного NPC?
- Сразу несколько не могут быть активны, всегда только какая-то одна.
3. Как обеспечивается отсутствие накладок и конфликтов между схемами (если они возможны)?
- Выбор нужной схем задаётся при помощи приписывания схемам различных предусловий их включения.
4. Есть универсальные, общие схемы, которые включены для NPC всегда?
- Я бы разделил схемы на три категории:
1) схемы логики, те которые задаются через custom_data или гулаги, последовательность и условия их включения
определена прописанной логикой
2) общие скриптовые, те которые могут включиться в любой момент и прервать на время последовательность схем
логики и для которых есть скрипты на LUA (встреча с ГГ, раненый, ...)
3) движковые, эти лежат в движке и тоже могут прерывать последовательность схем логики (бой, паника?)

[Panzer]

Подскажите, как сделать мегафон в Зове Припяти? В all.spawn сделал ссылку в конфиг. В файле это:

 

 

[logic]
active = ph_sound@epic
on_hit = hit
[hit]
on_info = %+esc_matugalnik_off%

[ph_sound@epic]
snd = epic
on_signal = sound_end|ph_sound@wait_1
on_info = {+esc_matugalnik_off} nil

[ph_sound@wait_1]
on_timer = 10000| ph_sound@music
on_info2 = {+esc_matugalnik_off} nil

[ph_sound@music]
snd = music
on_signal = sound_end|ph_sound@wait_2
on_info = {+esc_matugalnik_off} nil

[ph_sound@wait_2]
on_timer = 10000| ph_sound@epic
on_info2 = {+esc_matugalnik_off} nil

 

Инфопоршни прописаны в геймплей info_escape, тема прописана в скрипте sound_theme.script .
Но не работает... Ругается на какой-то индекс...


Зайди сюда. Там более развёрнуто опиши, как "Ругается на какойто индекс.", т.е. - лог предоставь (если он есть)...

Fagot.