STALKER-End - портал грандиозных модов по игре Сталкер

Бл0кнот

4o_kavo — Fri, 11 Nov 2011 18:04:30 GMT

Я научу как пользовоться блокнотом в Сталкере начнём 1-ое откройте папку gamedata потом config(здесь находяться конфигурации практически всего)

2-ой урок
редактируем Меченого
1-я часть бесмертие
Открываем конфигурации а потом открываем папку creatures и открываем конфигурацию actor и находим такие строки

Code

;коэффициенты иммунитета
strike_immunity    = 0.0
shock_immunity     = 0.0
wound_immunity    = 0.0
radiation_immunity    = 0.0
telepatic_immunity    = 0.0
chemical_burn_immunity   = 0.0
explosion_immunity    = 0.0
fire_wound_immunity    = 0.0

[actor_immunities_gd_stalker]
burn_immunity     = 0.0    ;коэффициенты иммунитета
strike_immunity    = 0.0
shock_immunity     = 0.0
wound_immunity    = 0.0
radiation_immunity    = 0.0
telepatic_immunity    = 0.0
chemical_burn_immunity   = 0.0
explosion_immunity    = 0.0
fire_wound_immunity    = 0.0

[actor_immunities_gd_veteran]
burn_immunity     = 0.0    ;коэффициенты иммунитета
strike_immunity    = 0.0
shock_immunity     = 0.0
wound_immunity    = 0.0
radiation_immunity    = 0.0
telepatic_immunity    = 0.0
chemical_burn_immunity   = 0.0
explosion_immunity    = 0.0
fire_wound_immunity    = 0.0

[actor_immunities_gd_master]
burn_immunity     = 0.0    ;коэффициенты иммунитета
strike_immunity    = 0.0
shock_immunity     = 0.0
wound_immunity    = 0.0
radiation_immunity    = 0.0
telepatic_immunity    = 0.0
chemical_burn_immunity   = 0.0
explosion_immunity    = 0.0
fire_wound_immunity    = 0.0

ставим все нули как тут и всё а что бы сделать бессмертие от радиации находим такую строчку

Code

;скорость уменьшения радиации
radiation_v = 99990.0001

Обучение модостроению!

СеРЬIй — Fri, 28 Oct 2011 17:47:56 GMT

Форум: Статьи (уроки) по моддингу
Автор темы: СеРЬIй
Автор последнего сообщения: leiytinant
Количество ответов: 0

FAQ по моддингу сталкер

4o_kavo — Tue, 27 Sep 2011 09:46:41 GMT

Создание проводников в ЗП

4o_kavo — Tue, 27 Sep 2011 09:44:04 GMT

Акт первый, основной ;-)
Строго следуя рекомендациям БАТИ-STALKER`a создаем переход на нашу локацию(http://stalkerin.gameru.net/wiki/index.php/Подключение_локаций_к_ЧН_и_ЗП_с_помощью_программы_от_AMK_Team). Дальше идут цитаты (немного подправленные) из многим известного туториала вышеуказанного модмейкера ;-)

Цитата: Соединение с остальными уровнями.

Предлагаю вам не терять зря времени, просто бегая по подключенной локации, а замерить координаты для создания перехода. Координаты будем снимать на 2-х локациях: на той с которой будем переходить и на той на которую вы хотите сделать переход соответственно. На каждой локации нам нужно снять по одной координате(координата местоположения самого перехода на первой локации и координата места в которое будет бросать при переходе на подключенную локацию). Как снять координаты, я думаю все знают, поэтому объяснять здесь не буду. (в комплект с данным уроком я поместил архив koord.rar со скриптом для снятия координат, это для тех кому лень искать).

Мы отмерили все необходимые нам координаты.

Затем распаковываем сделанный нами ранее all.spawn. Теперь в нужных нам локациях, в alife_ файлах (для данного примера файл alife_zaton.ltx) добавляем следующую секцию спавна: (примечание от Freezer: в приведенном ниже коде имена и стартовые координаты указаны для уровня Затон, сам переход расположен левой верхней области карты уровня справа от дорожки, а конечные координаты для подключенного уровня Янтарь, ГГ появляется в бункере у Сахарова)

[1]
; cse_abstract properties
section_name = level_changer
name = yan_actor_arrive_walk- уникальное имя
position = -278.19274902344,12.461790084839,621.68505859375 - координаты перехода
direction = 0,0,0
cse_abstract__unk1_h16 = 0x1
; cse_alife_object properties
game_vertex_id = 33 – геймвертексы перехода
distance = 0
level_vertex_id = 389502 – левелвертексы перехода
object_flags = 0xffffff3e
; cse_shape properties
shapes = shape0
shape0:type = box
shape0:axis_x = 1.25219917297363,0,0
shape0:axis_y = 0,3.09340000152588,0
shape0:axis_z = 0,0,1.25219917297363
shape0:offset = 0,0,0
; cse_alife_space_restrictor properties
restrictor_type = 3
; cse_alife_level_changer properties
dest_game_vertex_id = 934 – геймвертексы локи на которую ведет переход
dest_level_vertex_id = 73102 - левелвертексы локи на которую ведет переход
dest_position = 28.876106262207,-11.706871032715,-277.9711303710 - позиция куда кидает
dest_direction = 0,0,0 - поворот гг
dest_level_name = l07_yantar - на какую локу кидает
dest_graph_point = start_actor_01
silent_mode = 1
; se_level_changer properties

Изменяем только те места, которые я прокомментировал, комментарии соответственно, удаляем. Конец цитаты: Итак сам переход мы создали можно собрать all.spawn и проверить работоспособность перехода. Перейдем к следующему этапу.

[править]
Акт второй, Гламурный ;-)

Переход то мы собрали, вот только он невидимый, поэтому добавим гламура и поставим на место перехода всем известную аномалию «Пространственный Пузырь» aka шарик-телепортатор. Снова открываем alife_zaton.ltx (ибо переход мы разместили на нем), и добавляем следующую секцию:

[2]
; cse_abstract properties
section_name = space_restrictor
name = zat_teleport_sphere_to_yan – уникальное имя секции
position = -278.19274902344,12.461790084839,621.68505859375 – координаты шарика (они точно соответствуют координатам созданного нами ранее перехода)
direction = 0,0,0

; cse_alife_object properties
game_vertex_id = 33 –геймвертекс шарика (соответствует геймвертексу перехода)
distance = 0
level_vertex_id = 389502 –левелвертекс шарика (соответствует левелвертексу перехода)
object_flags = 0xffffff3e
custom_data = <
[logic]
cfg = scripts\zaton\zat_teleport_sphere.ltx – уникальное имя используемого скрипта
END

; cse_shape properties
shapes = shape0
shape0:type = sphere
shape0:offset = 0,0,0
shape0:radius = 1.40499997138977

; cse_alife_space_restrictor properties
restrictor_type = 3

Сохраняем файл (если юзали контрол+цэ контрол+вэ незабываем удалить комменты).

Открываем way_zaton.ltx в него добавляем следующую секцию:

[zat_teleport_sphere_to_yan]
points = p0
p0:name = wp00
p0:flags = 0x1
p0:position = -278.19274902344,12.461790084839,621.68505859375
p0:game_vertex_id = 33
p0:level_vertex_id = 389502

Думаю, что комменты по координатам не нужны. Обратите внимание на имя секции, оно соответствует уникальному имени в alife файле. Все, пока с alife и way мы закончили, можно собрать all.spawn

Далее необходимо создать скрипт для шарика, имя скрипта мы указали в alife файле. Итак, в папке с игрой в gamedata\configs\scripts\zaton создаем файл zat_teleport_sphere.ltx. В файле пишем:

[logic]
active = sr_particle@ zat_teleport_sphere_to_yan – имя активного партикла

[sr_particle@ zat_teleport_sphere_to_yan] – собственно начало самого партикла
name = anomaly2\anomaly_spatial_bubble_idle
path = zat_teleport_sphere_to_yan – имя секции в way файле в которой описан шарик
mode = 2
looped = true

Сохраняем файл по указанному пути, вспоминаем что юзали cntrl+c, cntr+v, снова открываем файл и удаляем мои комменты ;-)

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

[править]
Акт третий, Ленивый

Итак, переход создан, визуализирован и радует нас своей красотой и функциональностью, но думаю, что за время всех проверок вы уже изрядно стерли кнопки на клаве, бегая по зоне пешком туда-сюда, поэтому, как говорил один известный пендосовский миллионер: «Я так хорошо выгляжу потому, что я никогда на стоял если можно сидеть и никогда не сидел если можно лежать». Ну вот, запустили мы новую игру, давайте пробежим немного прямо. Кто это? Опа, нам на встречу идут пара неписей. Из беседы мы узнаем, что за энную сумму бабла они могут нас отвести хоть на край света, да вот досада эти два осла с автоматами ничерта не знают о нашей прекрасной аномалии «Пространственный Пузырь». За чем же встало дело? Давайте просветим невежд, и в будущем будем на законных основаниях пользоваться их услугами. Преступим. Для начала снова замерим координаты на местности куда нас приведут npc (я снял координаты на пару метров левее самой аномалии). Далее в файле alife_zaton.ltx добавим следующую секцию:

[3]
; cse_abstract properties
section_name = smart_terrain
name = zat_b1000 – уникальное имя смарт террана на который нас приведут неписи
position = -317.98794555664,19.28000831604,608.48858642578 –координаты конечной точки на которую нас приведут неписи
direction = 0,0,0

; cse_alife_object properties
game_vertex_id = 212
distance = 0
level_vertex_id = 314120
object_flags = 0xffffff3e
custom_data = <
[smart_terrain]
cfg = scripts\zaton\smart\zat_b1000.ltx – уникальное имя используемого скрипта
END

; cse_shape properties
shapes = shape0
shape0:type = sphere
shape0:offset = 0,0,0
shape0:radius = 2

; cse_alife_space_restrictor properties
restrictor_type = 3

; se_smart_terrain properties

Сохраняем файл

Открываем way_zaton.ltx
Добавляем следующие секции:

В данной секции пишем координаты куда нас должны привести
[zat_b1000_traveller_actor]
points = p0
p0:name = wp00
p0:position = -317.98794555664,19.28000831604,608.48858642578
p0:game_vertex_id = 212
p0:level_vertex_id = 314120

Все секции, приведенные ниже это - вейпойнты для сопровождающих неписей, они нужны иначе никто никуда не идет, а все стоят и тупо гонят друг на друга, примерно так:

ГГ: Я ж тебе сволочь денег дал, пошли!!!

Непись: Да чет лениво мне как-то… ГГ: Тогда бабло верни!!!! Непись: Какое такое бабло? В это время движок уже отключил аи и управление, и как результат, ГГ кипит от злости за то, что его банально кинули на бабки, но даже в рожу неписю дать не может, а тот, скотина, стоит и ухмыляется. Вот такую картину я лицезрел пока не добавил нижеприведенные секции. Координаты в них я не менял, а секции банально скопировал из другого места, поэтому я иду к аномалии «Пространственный Пузырь», а сопровождающие неписи "идут лесом", то есть к аномалии коготь (для желающих лицезреть проводников рядом с собой в конечной точке прибытия, небольшое домашнее задание по доработке координат в нижеприведенных секциях)

[zat_b1000_traveller_squad]
points = p0,p1
p0:name = wp00
p0:position = -24.9449501037598,1.29261004924774,-196.022598266602
p0:game_vertex_id = 56
p0:level_vertex_id = 895313
p0:links = p1(1)

p1:name = wp01
p1:position = -26.4207763671875,1.04062795639038,-194.030059814453
p1:game_vertex_id = 56
p1:level_vertex_id = 892596

[zat_b1000_walker_1_look]
points = p0
p0:name = wp00|a=sit_ass
p0:flags = 0x1
p0:position = -35.1018524169922,0.350845992565155,-193.619186401367
p0:game_vertex_id = 56
p0:level_vertex_id = 876236

[zat_b1000_walker_1_walk]
points = p0
p0:name = wp00
p0:flags = 0x1
p0:position = -33.450439453125,0.419611006975174,-192.414947509766
p0:game_vertex_id = 56
p0:level_vertex_id = 879043

[zat_b1000_walker_2_look]
points = p0
p0:name = wp00|a=sit
p0:flags = 0x1
p0:position = -35.8835983276367,0.317862987518311,-193.98469543457
p0:game_vertex_id = 56
p0:level_vertex_id = 874818

[zat_b1000_walker_2_walk]
points = p0
p0:name = wp00
p0:flags = 0x1
p0:position = -35.9317092895508,0.310889005661011,-191.664642333984
p0:game_vertex_id = 56
p0:level_vertex_id = 874821

[zat_b1000_walker_3_look]
points = p0
p0:name = wp00
p0:flags = 0x1
p0:position = -35.1221542358398,0.349720001220703,-193.500946044922
p0:game_vertex_id = 56
p0:level_vertex_id = 876237

[zat_b1000_walker_3_walk]
points = p0
p0:name = wp00
p0:flags = 0x1
p0:position = -33.0930519104004,0.432388007640839,-191.15592956543
p0:game_vertex_id = 56
p0:level_vertex_id = 880435

Сохраняем файл. Можно собирать all.spawn.

Теперь вспомним о том что мы упоминали некий уникальный скрипт, итак создадим его. В папке с игрой gamedata\configs\scripts\zaton\smart создадим файл zat_b1000.ltx В нем пишем:

[smart_terrain]
squad_id = 32
max_population = 1

[exclusive]
;please leave this for sim - stalkers only
zat_b29_stalker_rival_leader = zaton\zat_b29_stalkers_rivals.ltx
zat_b29_stalker_rival_2 = zaton\zat_b29_stalkers_rivals.ltx
zat_b29_stalker_rival_3 = zaton\zat_b29_stalkers_rivals.ltx

С содержимым файла разбираться времени не было, работает и ладно, оно тупо скопировано из другого подобного файла, так что вот вам еще одно домашнее задание: разберитесь для чего нужны последние 3 строки в этом файле. (да я лентяй ну и что ;-) прим. автора)

Далее в папке с распакованной геймдатой gamedata\configs\text\rus находим файл st_land_names.xml и кладем его в папку с игрой путь gamedata\configs\text\rus. Открываем скопированный файл и добавляем в него следующую секцию:

Пространственный Пузырь

Сохраняем файл.

Далее чешем в папку с распакованной геймдатой, там в gamedata\configs\misc\ находим travel_manager.ltx и по аналогии с предыдущим файлом копируем его в папку с игрой. Открываем travel_manager.ltx Находим секции: «идентификатор st_<комьюнити>_zaton_smart_name_1» Пишем туда:

zat_b1000 = st_stalker_zat_b1000

Далее ниже находим:

[traveler] ; Перечень точек, куда проводники могут отвести за бабосы.
zat_stalker_base_smart ; name смарта

и пишем туда:

zat_b1000

Ну и в конце:

[zat_b1000]
level = zaton
name = st_zat_b1000_name
condlist = true

Все, сохраняем и запускаем игру!!!!

[править]
Авторы

Ну вот, мы снова начали новую игру, давайте снова подойдем к известным нам ранее неписям и узнаем куда же они смогут нас отвести. О ЧУДО!!!! НЕПИСИ ЗНАЮТ О АНОМАЛИИ «Пространственный Пузырь»!!!!

Прогуляемся? ;-)

Конец третьего акта. Занавес. Бурные аплодисменты. Благодарности и цветы для: Freezer и БАТЯ-STALKER …

Успехов вам в написании собственных «сказок»!!!!

Авторы и ©: Александр Левашов aka Freezer при огромной поддержке БАТЯ-STALKER.

Создание достижения в ЗП

4o_kavo — Tue, 27 Sep 2011 09:43:17 GMT

«Создание нового достижения в ЗП»-Автор: WillsherT
Специально для сайта www.gsc-mod.ucoz.ru
Для начала нужно распаковать игру анпакером.
После распаковки идём в следующие директории и ищем следующие файлы:
info_x.xml ---> configs\gameplay\ (где "x" название локации на которой хотим получить достижение например jupiter) этот файл нужен для просмотра списка квестов на локации, зачем нам это узнаете позже.
achievements.ltx ---> configs\misc\
st_achievement.xml ---> configs\text\rus\
ui_actor_achivments.xml ---> configs\ui\textures_descr\
xr_statistic.script ---> scripts\
ui_actor_achivments.dds ---> textures\ui\
xr_conditions.script ---> scripts\
И так, приступаем к работе.

Откроем файл achievements.ltx и ищем такую вот запись:

[achievements]
pioneer
mutant_hunter
detective
one_of_the_lads
kingpin
herald_of_justice
seeker
battle_systems_master
high_tech_master
skilled_s talker
leader
diplomat
research_man
friend_of_duty
friend_of_freedom
balance_advocate
wealthy
keeper_of_secrets
marked_by_zone
inf ormation_dealer
friend_of_stalkers

Добавим в конце название_достижения_на_английском. Пример:

[achievements]
pioneer
mutant_hunter
detective
one_of_the_lads
kingpin
herald_of_justice
seeker
battle_systems_master
high_tech_master
skilled_s talker
leader
diplomat
research_man
friend_of_duty
friend_of_freedom
balance_advocate
wealthy
keeper_of_secrets
marked_by_zone
inf ormation_dealer
friend_of_stalkers
all_stalkers_your_friend

Идём в конец файла и добавляем следующее:

["Название_достижения_на_английском_без_кавычек"]
icon = ui_inGame2_имя_иконки_на_английском
hint = st_sp_achievement_22_hint <--- То, что будет выводиться в КПК при наведении на иконку достижения (надо оставлять так же меняя только числа, чтоб они шли по порядку)
name = st_sp_achievement_22_name <--- Имя достижения
desc = st_sp_achievement_22_descr <--- Описание достижения
functor = xr_statistic.название_достижения_на_английском_functor <--- функция для получения нашего достижения

закрываем сохраняя изменения в файле

Далее откроем файл st_achievement.xml и добавим между:

Друг сталкеров

и

Совокупность новых данных позволила профессорам Герману и Озёрскому синтезировать в условиях Зоны экспериментальный анабиотик.

Следующее:

Ваш текст который будет высвечиваться в КПК при наведении мышки на иконку достижения.

Полное описание достижения.

Имя достижения

Закрываем с подтверждением на сохранение изменений

Открываем xr_statistic.script идём в самый конец и добавляем следующее:
function название_вашей_функции()
if not has_alife_info("пишем_что_хотим_на_английсокм") then <--- проверка на раннее получение этого достижения
if has_alife_info("название_квеста_или_действия") <--- квест или действие после которого будет получено достижение
and has_alife_info("название_квеста_или_действия") <--- эта функция если квестов несколько
db.actor:give_info_portion("пишем_что_писали_в_проверке_на_получение_ранее_достижения")
news_manager.send_tip(db.actor, "st_ach_название_вашего_достижения_на_английском", nil, "название_вашего_достижения_на_английском", nil, nil)
xr_effects.inc_faction_goodwill_to_actor(db.actor, nil, {"stalker", 100}) <--- прибавление репутации сталкеров при получении данного достижения (если - то убавление), можно вписать любую другую группировку (использовать несколько команд если хотите прибавить или убавить репутацию у нескольких группировок)
end
end
return has_alife_info("пишем_что_писали_в_проверке_на_получение_ранее_достижения")
end

Закрываем с подтверждением на сохранение изменений.

Откроем xr_conditions.script найдём:

friend_of_stalkers_functor = xr_statistic.friend_of_stalkers_functor

и после пишем:

название_вашей_функции = xr_statistic.название_вашей_функции

Закрываем с подтверждением на сохранение изменений.

Рисуем в ui_actor_achivments.dds иконку для нашего достижения (можно взять и старую).

Открываем файл ui_actor_achivments.xml и добавляем там:

Если рисовали собственную иконку то вписываем её координаты (по x и y осям), если решили взять уже имеющуюся то вписывайте её координаты (координаты определяются по левому верхнему углу иконки достижения) координаты можно посмотреть через WTV (Windows Texture Viewer) Удачной игры

Автор: WillsherT
Вопросы и ответы:
Вопрос:
координаты можно посмотреть через WTV
Как это?
Ответ:
Очень просто:
открываешь им текстуру и когда водишь по ней мышкой в верху окошка (там где кнопки: закрыть,свернуть ну и т.д.) будет такой параметр pos: это и есть координаты по x и y (соответственно первая цифра x, вторая y)
Вопрос:
Не знаешь где можно найти список этих команд и что они означают?
(В файле xr_statistic.script)
Ответ:
Собственно списка команд у нас нет(
Достаточно написать, что-нибудь логическое например: достижение не выдавалось.

Добавление Режима Freeplay в игру (Тень Чернобыля)

4o_kavo — Tue, 27 Sep 2011 09:42:54 GMT

Делается это так: в файле gamedata/script/xr_effects.script ищем строку :function after_credits(actor, npc) и ниже находим вот что c:execute("disconnect") Меняем "disconnect" например на hud_crosshair 1 и все вместо того чтобы после концовок (похоже даже фальшивых) будет возможно продолжить игру... Теперь добавляйте точки перехода (например на Припять) и все freeplay работает.

Настройка логики (Часть 3)

4o_kavo — Tue, 27 Sep 2011 09:42:23 GMT

НАСТРОЙКА ЛОГИКИ
Часть 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%

Авторы статьи: GSC Game World

Настройка логики (Часть 2)

4o_kavo — Tue, 27 Sep 2011 09:41:57 GMT

НАСТРОЙКА ЛОГИКИ
Часть 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 (запускает схему встречи).
o meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога).
o meet_dialog = <название диалога>, который будет запущен при юзе.
o meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если открылось диалоговое окно общения и торговли.
o wounded_enabled = true (включает NPC возможность использовать схему раненого).
o combat_ignore_cond = см. выше.
o combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – только в случае стрельбы со стороны игрока!)
o combat_type = {условие} scheme - тип боя, которым будет пользоваться NPC из данной схемы.
o 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 =

Авторы статьи: GSC Game World

Настройка логики (часть 1)

4o_kavo — Tue, 27 Sep 2011 09:41:32 GMT

НАСТРОЙКА ЛОГИКИ ДЛЯ СТАЛКЕРОВ
Часть 1

3. Настройки логики
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 - куда смотрит сталкер. Есть следующие варианты
o story_id – числовое значение
o actor – без комментариев
o nil – позиция вычисленная АИ автоматически
o <имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).
Пример:
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 = ... - Задаем тип стрельбы. Возможные значения:
o always - значение по умолчанию, стреляет всегда, когда можно
o none - не стреляет вообще.
o 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 - описывет способ построения и не является обязательным. Возможны следующие варианты:
o back - мужики идут чуть позади командира в два ряда (по умолчанию)
o line - шеренга
o 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

Создание спального мешка в ЗП

4o_kavo — Tue, 27 Sep 2011 09:40:46 GMT

В этой статье я расскажу вам как создать спальный мешок в ЗП
Для начала заходим в файл gamedata\configs\misc\items.ltx
И в самый конец добавляем вот это:
; Спальник
[spalnik]:identity_immunities
discovery_dependency =
$spawn = "food and drugs\antirad"
$prefetch = 32
class = S_FOOD
cform = skeleton
; eatable item
eat_health = 0
eat_satiety = 0
eat_power = 0
eat_radiation = 0
eat_alcohol = 0
wounds_heal_perc = 0
eat_portions_num = 1
; food item
animation_slot = 4
;hud item
hud = wpn_vodka_hud
visual = dynamics\workshop_room\banka_kraski_1.ogf
description = enc_spalnik
inv_name = spalnik
inv_name_short = spalnik_s
inv_weight = 1
inv_grid_width = 2
inv_grid_height = 2
inv_grid_x = 14
inv_grid_y = 23
cost = 2200
Сохраняем…
Теперь идём в файл bind_stalker.script и после строчек
get_console():execute("snd_volume_eff 0")
else
пишем вот это:
if (spalnik) then spalnik.use_inventory_item(s_obj) end --Idler используем спальник?
end
сохраняем…
Теперь в папке gamedata\scripts создадим файл spalnik.script и в него впишем:
--[[
File: spalnik.script
rev: 12/10/09.01
Обработчик для спальника
]]

-- функции АМК
function spawn_item_in_inv(spawn_item, npc)
if npc==nil then
npc=db.actor
end
return alife():create(spawn_item,
npc:position(),
npc:level_vertex_id(),
npc:game_vertex_id(),
npc:id())
end

-- функции спальника
function use(s_obj)
if not s_obj then return end
if (surge_manager.actor_in_cover()) then
ui_sleep_dialog.sleep()
give_info("sleep_active")
else
news_manager.send_tip(db.actor, game.translate_string("st_spalnik_nosleep"))
end

spawn_item_in_inv("spalnik")
end

function use_inventory_item(s_obj)
if s_obj and s_obj.section_name and s_obj:section_name()=="spalnik" then
use(s_obj)
end
end
все можно сохранять...
Теперь идем в файл gamadata\configs\text\rus\st_items_equipment.xml
И в конце перед строчкой вписываем вот это:

Спальный мешок

Спальный мешок

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

Сохраняем…
Теперь идем в туже папку в файл ui_st_screen.xml и в конце перед строчкой пишем вот это:

В этом месте не заснуть. Нужно найти укрытие в котором можно переждать выброс.

Теперь идем в файл:
Gamedata\configs\gamepley\character_desc_general.xml и там после строчки:
stalker_outfit \n
пишем:
spalnik \n
Сохраняем…
Все можно заходить в игру и проверять…Спальный мешок появится у вас в начале новой игры!!!
НО ЕСТЬ ДВА НЕДОСТАТКА!!!У СПАЛЬНОГО МЕШКА НЕТ ИКОНКИ ИНВЕНТАРЯ И У МОДЕЛЬ У НЕГО НЕ СПАЛЬНОГО МЕШКА, А БАНКИ КРАСКИ…ИКОНКУ СДЕЛАЙТЕ САМИ, ДУМАЮ ЗНАЕТЕ КАК, НУ А ЕСЛИ У ВАС И МОДЕЛЬ СПАЛЬНОГО МЕШКА ЕСТЬ ТО ЭТО ВООБЩЕ ОТЛИЧНО…ДУМАЮ КАК ЕЁ ВСТАВИТЬ ВЫ ТОЖЕ ЗНАТЕ…
Так по моему не чего не забыл…
(Статья от ак101)
НА ЧИСТОЙ ВЕРСИИ 1.6.00 ВСЕ РАБОТАЛО ОТЛИЧНО

спать можно только в тех местах где можно укрыться от выброса!