Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
В точках look пути, в которые смотрит прожекторщик, нужно прописать sl=имя_прожектора
Например wp00|sl=esc_sl1
Тогда при повороте в эту точку персонаж повернет в нее и прожектор.
При введении указанного кода выдает инфопоршн
[logic] active = ph_code@lock
[ph_code@lock] code = 1243 on_code = %+infoportion%
Файл: \gamedata\scripts\ph_code.script
То же самое, что и ph_door, но для ворот, состоящих из двух дверей: Вместо параметров closed и locked сейчас используются параметры: state: состояние, в котором дверь находится при инициализации (по умолчанию none)
open - в открытом
closed - в закрытом
none - в текущем (дефолтном или оставшемся от предыдущей схемы)
locking: блокировка дверей (по умолчанию none) stick - прилипание дверей к крайним состояниям (пока в процессе настройки)
soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной Состояния в этом положении:
open - блокировать в открытом состоянии
closed - в закрытом
none - не используется (мягкая блокировка возможна только в крайних положениях)
hard - блокировка двери с помощью границ. Ворота можно только сломать Состояния в этом положении:
open - блокировать в открытом состоянии
closed - в закрытом
none - в текущем
none - дверь не заблокирована
Общие параметры: left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов. breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.
Звуковые параметры аналогичны ph_door
Примеры: [ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые. state = opened locking = soft left_limit = 130 rigt_limit = 60 breakable = false
[ph_gate@opened] state = opened locking = stick
[ph_gate@closed] state = closeded
Файл: \gamedata\scripts\ph_gate.script
Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).
[ph_sound] snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes
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
Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.
force = сила, которая прикладывается к объекту. Измеряется в убитых енотах time = время прикладывания силы к предмету (в секундах) *delay = задержка (в секундах) перед применением силы point = имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет) point_index = индекс точки патрульного пути, в стону которого полетит предмет.
Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов
Пример:
[logic]
active = ph_on_death
[ph_on_death]
on_info = %эффекты%
Юзать исключительно с разрушаемыми физ. Объектами
Настройка возможности игроку управлять машиной.
секция: [ph_car]
поле: usable = <condlist>
usable - кондлист возвращающий true (по умолчанию) или false.
Пример:
[logic]
active = ph_car
[ph_car]
usable = {+val_actor_has_car_key}
На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее.
Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать. В кастом дате пишем:
[ph_heavy]
Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)
Пример логики
[ph_oscillate]
joint = provod - имя кости к которой будет применена сила
force = 5 - собственно сила (в ньютонах)
period = 1000 - время прикладывания силы.
Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.
Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.
Как поставить smart terrain? Для всех smart terrain нужно: 1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность). 2) В его custom data прописать настройки. 3) Расставить пути для соответствующих схем поведения.
Параметры custom data:
[gulag1]
type = тип гулага capacity = макс. вместимость в людях
Указывать тип гулага нужно без кавычек. Если не задан 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 будет случайно выбран один из доступных на данный момент гулагов.
Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку: [smart_terrains] none = true
Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.
campers Кемперы. custom data: [gulag1] type = campers capacity = от 1 до 3
Пути: camper_walk1, camper_look1 camper_walk2, camper_look2 camper_walk3, camper_look3
walkers Ходячие. На базе этого можна сделать поиск, обыск и куча всего. custom data: [gulag1] type = walkers capacity = от 1 до 3
Пути: walker_walk1, walker_look1 walker_walk2, walker_look2 walker_walk3, walker_look3
search Ходячие. На базе этого можна сделать поиск, обыск и куча всего. custom data: [gulag1] type = search capacity = 1
Пути: search_walk, search_look
Схема следующая: 1. Персонаж ходит по точкам, смотрит по сторонам 2. В определенных точках останавливается и что-то высматривает (caution, search, hide) 3. При этом говорит определенные реплики (…)
rest Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку). custom data: [gulag1] type = rest capacity = 1
Пути: rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит. sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит. rest_walk, rest_look
3.11.2. Гулаги. Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности: А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения); Б) Работы имеют приоритеты; В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом; Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.
Гулаг создается следующим образом:
1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.
2. Определяем максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.
3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.
4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага. [gulag1] type = тип гулага capacity = макс. вместимость в людях
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 часов, то гулаг находится в дневном состоянии, иначе в ночном.
8. В файле \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.
9. В \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). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.
Возможности нового смарттеррейна (СТ):
1) Не держит сталкеров постоянно в онлайне. Работает стандартный онлайн-радиус. 2) Сталкеры идут на ближайшие работы. 3) На места работ сталкеры идут независимо от того, в онлайне они или в оффлайне. 4) СТ в офлайне работает так же, как и в онлайне: выполняет переключение своих состояний, перераспределение работ. 5) Сталкерам можно прописать, при каких условиях в какие СТ они могут идти. (см. ниже) Если сталкер попал в СТ, то онбудет находится в нём, пока не истечёт время и выполняется условие. 6) Работы могут находиться на разных уровнях. 7) Скриптовая зона СТ теперь не используется для захвата персонажей. 8) Симуляция заключается в миграции персонажей между разными СТ.
Что нужно переделать:
1) Персонажи могут быть двух типов: либо для СТ, либо для самостоятельной работы под логикой из custom data. У первых логики в custom data не должно быть. У вторых должно быть прописано, что они не хотят ни в один СТ. (см ниже) 2) Нельзя под СТ отправлять сталкеров в nil. Вместо nil дайте им пути. Например, walker-ы в рестрикторе вместо nil в рестрикторе. (есть abort на такой случай) 3) Всех участников созданных сцен поставьте рядом с местами работ, а не в кучу. Так им не придётся полчаса разбредаться по местам работ: они сразу позанимают ближайшие. В custom data им пропишите, что до окончания сцены они могут быть только в этом СТ. (см. ниже) 4) Незначительно переделать функции predicate() и функции переключения состояния СТ. (см. ниже) 5) Проследите, чтоб под СТ в логиках в поле active было прописано только имя секции и ничего больше (никаких там процентов и фигурных скобок). Для персонажей не предназначенных под СТ это не играет роли. 6) Переименуйте в custom data СТ секцию [gulag1] в секцию [smart_terrain].
Настройки: -------------
Разрешения персонажам идти в определённые СТ ----
Разрешения персонажам идти в определённые СТ задаются в custom data секцией [smart_terrains]. В ней можно задавать пары "имя_СТ = condlist". Пример:
[smart_terrains] strn_1 = условие1 strn_2 = условие2
Если для какого-то smart_terrain условие выполнилось, он называется эксклюзивным. Если у объекта появился хоть один эксклюзивный smart terrain, то он будет согласен идти только в него. Если не появилось ни одного эксклюзивного, то он согласен идти в любой.
Есть зарезервированное сочетание "none=true". Если оно указано, то персонаж никогда не пойдёт ни в один СТ. Такой персонаж будет работать только под своей логикой.
Также можно задать, кого принимает СТ. В дополнение к старому механизму (функции checkNpc() в файлах gulag_*.script) можно в custom data СТ написать:
communities = группирвка1, группировка2, ...
Если это поле не задано, то проверяется старым механизмом. Если задано, то под СТ возьмутся только персонажи указанных группировок (учтите, старый механизм тоже вызовется).
Изменение функций predicate() ----
В эти функции вместо game_object будет передаваться табличка с информацией о персонаже. Там есть поля: name community class_id story_id profile_name
Если нужно, чтобы работа занималась только снайперами, то в предикате нужно писать:
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. Логика вертолёта Общие сведения:
Вертолёт работает на «логике». На вертолёт реагируют аномалии. Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит. Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.
У вертолёта есть универсальная боевая схема на манер сталкеров.
Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.
Общие сведения: Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.
Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.
Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.
Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.
По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень).
Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.
Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.
Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look
Настройки:
Вкл/выкл звук двигателя вертолёта.
Неуязвимость. Если true, вертолёт игнорирует все хиты.
Бессмертие. Если true, вертолёт получает повреждения, но не умирает.
Отключает универсальные реплики пилотов вертолета.
Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)
Параметры, задаваемые в именах вершин пути 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) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.
Общие сведения:
В универсальной боевой схеме вертолёт не привязан к путям.
Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в 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
Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:
[camper] show_spot = false (будучи в этой секции сталкер не показывается на карте)
[walker] show_spot = {+info1} false
Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.
Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.
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) – играть звук от указанного объекта
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
Статья создана: