Набір додаткових налаштувань логіки у різних об'єктів

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

Схема ph_idle

Схема насправді нічого не робить, представляє деяке проміжне стан об'єкта. Аналог схеми sr_idle тільки для фізичного об'єкта.

[ph_idle]
hit_on_bone = <number>|{+info -info =func !func ~number} %+info -info =func% <назва_схеми> - визначає, що станеться,

якщо об'єкт отримає хіт по кістці .

on_use = {+info -info =func !func ~number} %+info -info =func% <назва_схеми> - визначає, що станеться, якщо актор взаємодіє з об'єктом.
tips = <ім'я_тексу> - рядок з id тексту зареєстрованого в папці gamedata\config\text . Підказка під час наведення.
nonscript_usable = true/false – можливість стандартних (нескриптових) дій над об'єктом: взяти об'єкт в інтерфейс, відкрити інвентар.

У грі використовується в одному випадку - для об'єктів з ім'ям секції inventory_box , то біж схованок.

' Приклад використання схеми :

[ logic ]
 active = ph_idle
 
[ ph_idle ]
 hit_on_bone = 1 |%+agroprom_u_light_4%| 2 |%+agroprom_u_light_4%| 3 |%+agroprom_u_light_4%| 4 |%+agroprom_u_light_4% on_info = { +agroprom_u_light_4 } nil %=turn_off_object% 
 

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

Схема ph_door

Схема роботи дверей.
Примітка : для двостулкових воріт задається все аналогічно.

[ph_door]
locked = true/false - чи замкнені двері. За промовчанням false .
closed = true/false - чи закриті двері. Типово true .
show_tips = true/false - потрібно показувати підказку при наведенні на двері. Типово true .
tip_open = <ім'я_тексу> - рядок з id тексту зареєстрованого в папці gamedata\config\text .

Підказка, яка з'являється біля прицілу при наведенні на двері, якщо двері зачинені. Якщо locked дорівнює false , то за умовчанням tip_door_open , інакше tip_door_locked .

tip_close = <ім'я_тексу> - рядок з id тексту зареєстрованого в папці gamedata\config\text .

Підказка, яка з'являється біля прицілу при наведенні на двері, якщо двері відчинені. Якщо locked дорівнює false , то за умовчанням tip_door_close , інакше порожнє значення.

snd_open_start = <назва_звукової теми> - ім'я теми з файлу sound_theme.script . Звук, який буде відіграний під час спроби відчинити двері.
snd_close_start = <назва_звукової теми> - ім'я теми з файлу sound_theme.script . Звук, який буде відіграний під час спроби зачинити двері.
snd_close_stop = <назва_звукової теми> - ім'я теми з файлу sound_theme.script . Звук, який буде відіграний, коли двері зачиняться до кінця.
on_use = {+info -info =func !func ~number} %+info -info =func% <назва_схеми> - визначає, що станеться, якщо актор взаємодіє з дверима.

Зазвичай використовується для перемикання схеми.

hit_on_bone = <number>|{+info -info =func !func ~number} %+info -info =func% <назва_схеми> - визначає, що станеться,

якщо двері отримає хіт по кістці number .

no_force = true/false - за промовчанням false .

Приклад використання схеми :

[ logic ]
 active = ph_door@locked
 
[ ph_door@locked ]
 locked = true 
snd_open_start = trader_door_unlock 
on_info = { + esc_trader_can_leave } ph_door@closed %=play_snd ( device\door_servomotor ) % 
 
[ ph_door@closed ]
 closed = true 
locked = false 
on_use = ph_door@open %-esc_close_door% 
snd_open_start = trader_door_open_start 
snd_close_start = trader_door_close_start 
snd_close_stop = trader_door
 
[
 ph_door @open ] closed = false 
locked = false 
on_use = ph_door@closed 
on_info = { + esc_close_door } ph_door@ closed snd_open_start = trader_door_open_start snd_close_start = trader_door_close_start 

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

Схема ph_button

Схема роботи кнопки.
При натисканні на кнопку перемикає секції та видає інфопоршн.

[ph_button]
anim_blend = true/false – плавання, згладжена анімація.
anim = <назва_анімації> - анімація, яка відіграється при натисканні на кнопку.
on_press = {+info -info =func !func ~number} %+info -info =func% <назва_схеми> - що станеться при натисканні на кнопку.
tooltip = <ім'я_тексу> - рядок з id тексту зареєстрованого в папці gamedata\config\text . Підказка під час наведення.

Приклад використання схеми:

[ logic ]
 active = ph_button@rad_on
 
[ ph_button@rad_on ]
 anim_blend   = true 
anim         = lab_primary_switcher_idle 
tooltip      = tips_rad_switcher_press 
on_press     = ph_button@rad_off % +bar_deactivate_radar_done%

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

Схема ph_code

Схема здійснення введення цифрового пароля. При введенні вказаного коду видає інфопоршн.

[ph_code] code = <код> – встановлення коду.
on_code = {+info -info =func !func ~number}%+info -info =func% - що станеться під час введення правильного пароля.
on_check_code = <код> | {+info -info =func !func ~number}%+info -info =func% - що відбудеться при введенні встановленого пароля.
tips = <ім'я_тексу> - рядок з id тексту зареєстрованого в папці gamedata\config\text . Підказка під час наведення.

Приклад використання схеми :

[ logic ]
 active = ph_code
 
[ ph_code ]
 code = 1287975 on_code = nil %+rad_code_door_unlocked% 

[ logic ]
 active = ph_code@lock
 
[ ph_code@lock ]
 on_check_code1 = 2011533 | %+bun_codelock_open% on_check_code2 = 342089 | %+bun_codelock_open% 
 

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

Схема ph_gate

Те ж саме, що і ph_door , але для воріт, що складаються з двох дверей:

[ph_gate]
state - <параметр> - стан, у якому двері перебувають під час ініціалізації (за замовчуванням none ). Можливі такі значення:

• open - у відкритому стані;
• closed - у закритому стані;
• none - у поточному (дефолтному або решті попередньої схеми).

locking - <параметр> - блокування дверей (за замовчуванням none ). Можливі такі значення:

• stick – прилипання дверей до крайніх станів.
• soft – двері заблоковані за допомогою сили, тобто. можна її відкрити/пробити машиною. Стану в цьому положенні:

• open - блокувати у відкритому стані;
• closed - у закритому;
• none - не використовується (м'яке блокування можливе лише в крайніх положеннях);

• hard – блокування дверей за допомогою кордонів. Ворота можна лише зламати. Стану в цьому положенні:

• open - блокувати у відкритому стані;
• closed - у закритому;
• none - у поточному.

• none - двері не заблоковані

left_limit/right_limit = <number> - задають кут [0-180] відкриття кожної зі стулок воріт. За замовчуванням – 100 градусів.
breakable = true/false - визначає, чи можна зламати ворота. Типово true .
Звукові параметри аналогічні ph_door .

Приклад використання схеми :

[ logic ]
 active = ph_gate@locked
 
[ ph_gate@locked ]
 state = closed 
locking = hard 
on_info = { +val_chase_start } ph_gate@unlocked 
 
[ ph_gate@unlocked ]
 state = closed 
locking = stick

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

Схема ph_sound

Прописується у фізичного об'єкта, які звуки він видає (спочатку планувався як матюгальник).

[ph_sound]
snd = <назва_звукової_теми> - ім'я теми з файлу sound_theme.script з таблиці ph_snd_themes .
looped = true/false – зациклене відтворення звуку. За замовчуванням - false .
min_idle=<number> - мінімальний час простою перед включенням звуку (мс). За замовчуванням – 0.
max_idle = <number> – максимальний час простою перед включенням звуку (мс). За замовчуванням - 0.
random = true/false - якщо true , то з теми буде обрано рандомний звук і таким чином звуки будуть грати до посиніння. За замовчуванням - false .
no_hit = true/false - чи буде реагувати схема на нанесений хіт. За замовчуванням - true .

Примітка : якщо встановити random = true і looped = true , то схема сипеться.

Підтримується сигнал sound_end .

Ця схема працює, м'яко кажучи, через дупу, тому зациклений звук продовжуватиме відіграватися, навіть якщо об'єкт йде в nil . У зв'язку з цим треба створювати нову секцію, яка б відігравала одиночний короткий звук, після якого (оскільки він точно гратиме щоразу) ставимо on_signal = sound_end| nil .

Специфічно створюється звукова схема.
У sound_theme.script на початку файлу є секція ph_themes , у якій описуються теми для фіз об'єктів.

Наприклад:

ph_snd_themes [ "gar_seryi_shooting" ] = { [ [ characters_voice\human_01\scenario\garbage\distance_shooting ] ] }

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

Приклад використання схеми :

[ logic ]
 active = ph_sound
 
[ ph_sound ]
 snd = gar_bandits_seryi 
min_idle = 1000 max_idle = 5000 
 

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

Схема ph_force

Схема дозволяє штовхнути предмет у вказану сторону.

[ph_force]
force=<number> - сила, яка прикладається до об'єкта. Вимірюється у вбитих єнотах.
time = <number> - час докладання сили до предмета (у мілісекундах).
delay = <number> – затримка (у секундах) перед застосуванням сили.
point = <ім'я_шляху> - ім'я патрульного шляху, точки якого будуть використані як цілі (куди спрямовувати предмет).
point_index = <number> - індекс точки патрульного шляху, у стогін якого полетить предмет.

Приклад використання схеми :

[ logic ]
 active = ph_idle
 
[ ph_idle ]
 on_info = { +rad_here_i_come } ph_force 
 
[ ph_force ]
 force = 1500 time = 500 delay = 0 point = rad_barrel_drop point_index = 0 
 
 

 

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

Схема ph_on_death

Схема для відстеження руйнування фізичного об'єкта та видання з такої нагоди різних ефектів.

[ph_on_death]
on_info = {+info -info =func !func ~number} %+info -info =func% - ефекти при руйнуванні.

Примітка : використовувати виключно з фізичними об'єктами, що руйнуються ( physic_destroyable_object ).

Приклад використання схеми :

[ logic ]
 active = ph_on_death
 
[ ph_on_death ]
 on_info =  %=inc_counter ( mon_destroy_generator ) =x18_gluk%

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

Схема ph_car

Налаштування керування наземним транспортом.

[ph_car]
usable = {+info -info =func !func ~number} - умови для юзабіленості об'єкта.
show_tips = true/false - відображати підказку. За замовчуванням - true .
tip_use = <ім'я_тексу> - рядок з id тексту зареєстрованого в папці gamedata\config\text . Підказка, якщо умови для usable виконалися.

Типово - tip_car_use .

tip_locked = <ім'я_тексу> - рядок з id тексту зареєстрованого в папці gamedata\config\text . Підказка, якщо умови для usable не виконалися. Типово - tip_car_locked .

Якщо параметр usable не встановлений, то можливе налаштування самостійної поведінки транспорту, а саме БТР.

path_walk = <ім'я_шляху> - шлях руху транспорту.
path_fire = <ім'я_шляху> - ймовірно, точки шляху якими можлива стрілянина.
auto_fire = true/false – дозволити стріляти на ходу. За замовчуванням - false .
fire_time = <number> - час безперервної стрілянини в мілісекундах. За замовчуванням - 0.
fire_repeat = inf/<number> - ймовірно, час через який можлива повторна стрілянина. inf = -1 .
fire_range=<number> - дальність стрілянини. За замовчуванням – 50 метрів.
target = <параметр> - ціль для стрілянини. Можливі такі параметри:

• points – стріляти в першу точку патрульного шляху. Якщо шлях не вказано – виліт. Стоїть за замовчуванням;
• actor - без коментарів;
• story_id - персонаж із зазначеним story_id .

track_target = true/false - Якась подібність попереджувальної стрільби, не за метою, а трохи вище. За замовчуванням - false .
on_target_vis = <параметр>|{+info -info =func !func ~number} %+info -info =func% <назва_схеми> - що станеться, якщо ціль буде в прямій видимості.

Як параметр можливі два значення: actor , story_id персонажа.

on_target_nvis = <параметр>|{+info -info =func !func ~number} %+info -info =func% <назва_схеми> - що станеться, якщо мета пропаде з

області прямої видимості. Як параметр можливі два значення: actor , story_id персонажа.

invulnerable = true/false – невразливість. Якщо true , транспорт ігнорує всі хіти. За промовчанням false .
headlights = on/off - увімк./вимк. світло від фар.
on_death_info = info – видача інфопоршня при знищенні транспорту.

Підтримується сигнал arrived .

Приклад використання схеми :

[ logic ]
 active = ph_car@fire
 
[ ph_car@fire ]
 path_walk = pri_wave3_btr_walk 
path_fire = pri_wave3_btr_look 
fire_repeat = inf 
auto_fire = true 
on_target_vis = actor | ph_car@fight_actor2 
on_death_info = pri_wave3_btr_dead 
on_signal = arrived | ph_car@hunt_actor %+pri_wave3_btr_arrived%

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

Схема ph_oscillate

Схема призначена для плавного розгойдування фізики (лампи, висять зомбі і т.д.)

[ph_oscillate]
joint = <ім'я_кості> - ім'я кістки об'єкта до якої буде застосована сила.
period = <number> - час застосування сили в мілісекундах.
force=<number> - власне сила прикладання в ньютонах.
correct_angle = <number> – кут щодо осі Y.

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

Приклад використання схеми :

[ logic ]
 active = ph_oscillate
 
[ ph_oscillate ]
 joint = bone05 
period = 3000 force = 500 correct_angle = 5 
 
 

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

Секція ph_heavy

Прописується у фіз об'єктах, які заборонені для шпурлення бюрерам та полтергейстам. Наприклад, якщо вони повинні лежати на конкретному місці (типу сюжетних сюжетів) або занадто громіздкі за габаритами, щоб їх можна було гарно кидати. У кастій даті пишемо: [ph_heavy] .

Принцип роботи прожектора:

У точках look шляху, які дивиться прожекторник, потрібно прописати: sl=<ім'я_прожектора>

Наприклад:

wp00 | sl = esc_sl1

Тоді при повороті в цю точку персонаж поверне до неї прожектор.

Логіка вертольота

Загальні відомості:

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

Схема heli_move

Дозволяє літати гелікоптеру патрульним шляхом, регулювати швидкість, зависати, стріляти з різних цілей.
Для схеми має бути заданий path_move – шлях, яким літатиме вертоліт. Він може містити одну вершину, якщо необхідно, щоб вертоліт висів дома.
Можна (але не обов'язково) задати path_look – шлях, до вершин якого вертоліт може дивитися.
Вершини цих шляхів можуть бути поставлені будь-де в межах обмежуючого боксу рівня. Вони не залежать від ai-nodes .
По дорозі вертоліт літає без урахування зв'язків між вершинами. Він літає від вершини до вершини у порядку зростання їхнього номера (тобто в порядку, в якому їх поставили на рівень).

Вертоліт намагається літати точно вершинами шляху. За бажанням можна зробити ювелірний проліт під мостом.

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

Якщо вершині шляху path_move заданий набір прапорців, то вертоліт буде дивитися будь-яку з вершин path_look , у яких заданий такий самий набір прапорців. Повертатися до цієї точки вертоліт почне з попередньої вершини колії. На даному етапі гелікоптер не може, зависнувши в одному місці, дивитися по черзі в кілька точок path_look .

[heli_move]
path_move = <ім'я_шляху> - шлях польоту.
path_look = <ім'я_шляху> - точки в які дивитися вертоліт.
engine_sound = true/false - увімк/викл звук двигуна вертольота. Типово true .
invulnerable = true/false – невразливість. Якщо true , вертоліт ігнорує всі хіти. За промовчанням false .
immortal = true/false – безсмертя. Якщо true , гелікоптер отримує пошкодження, але не вмирає. За промовчанням false .
mute = true/false – відключає універсальні репліки пілотів вертольота. За промовчанням false .
rocket_delay = <number> - затримка, в мілісекундах, між пусками ракет. За замовчуванням береться з ltx (зараз 1250 мсек).
default_velocity = <number> - швидкість, в метрах за секунду, з якою літає вертоліт, якщо не задані інші параметри.

Параметри, що задаються в іменах вершин шляху 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 ) тривалість часу (мс реального часу), протягом якого вертоліт буде дивитися в дану точку. Якщо цей параметр не заданий, то гелікоптер пронесеться без зупинки, але постарається на ходу розвернутися до цієї вершини.

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

Універсальна бойова схема: heli_combat

Загальні відомості:
В універсальній бойовій схемі гелікоптер не прив'язаний до шляхів.
Гелікоптер не бачить нікого. Дізнатися про ворога вертоліт може тільки при отриманні хіта або параметра в custom data .
Гелікоптер стріляє по ворогові, якщо бачить його. Якщо не бачить – шукає, облітаючи довкола точки, де востаннє бачив. Якщо довго не бачить ворога – забуває його. Якщо ворога задали примусово з поточної секції схеми поведінки, він не забуде його, поки перебуває у цій секції.

Примітка : окремої секції цієї схеми поведінки немає. Тому налаштування виконуються в секції поточної схеми поведінки:

combat_ignore = true/false – true означає ігнорування отримання хіта. Тобто. гелікоптер не намагатиметься "помститися" тому, від кого він отримав хіт.
combat_enemy = <параметр> - ворог. Можливі такі значення:

• nil – ворог відсутній;
• actor - без коментарів;
• story_id - персонаж із зазначеним story_id .

combat_use_rocket = true/false - чи можна гелікоптеру користуватися ракетами.
combat_use_mgun = true/false - чи можна гелікоптеру користуватися кулеметом.
combat_velocity = <number> - швидкість, з якою вертоліт робитиме бойові заходи.
combat_safe_altitude = <number> - висота, щодо найвищої точки геометрії на рівні нижче якої вертоліт не опускатиметься в бойовій схемі (може бути негативним).

До гелікоптера підключена схема xr_hit . Працює як у сталкерів. У xr_effects.script є група функцій для роботи з гелікоптером з його custom data :
heli_set_enemy_actor - зробити актора ворогом гелікоптеру;
heli_start_flame – підпалити вертоліт;
heli_die - вбити гелікоптер.

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

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

Smart Terrain

Під смарттеррейном розуміється шейп або зона, яка забезпечує "захоплення" НПС під гулаг, після чого вони починають виконувати роботи передбачені цим гулагом. Не потрібно ставити великий радіус шейпа для смарту, максимум один метр.

Як поставити smart terrain ?
Для всіх smart terrain потрібно:

1. Поставити smart_terrain з необхідним shape ;
2. У його custom_data прописати налаштування;
3. Розставити шляхи для відповідних схем поведінки.

Параметри custom_data :
[smart_terrain]
type = <ім'я_гулага> - назва гулага . Чи не смарта - а саме гулага!

Ім'я смарт дивимось у параметрі name спавн секції.

cond = {+info -info =func !func ~number} - умови, під час яких, гулаг може існувати.

Якщо умови перестали виконуватися, то "підлеглі" розпускаються і потрапляють під управління їх custom_data .

capacity = <number> - чисельність "жителів" гулага. Повинно бути менше або дорівнює кількості робіт, але не більше!
respawn = <ім'я_респовна> - респавн для гулага. Вказувати лише один! Викликає щоразу, коли хтось із НПС заступає на роботу.
preset = <назва_предустановки> - вказується ім'я однієї з секцій у файлі config\misc\smart_terrain_presets.ltx .

Служить умови того, який угруповання і якого ранго НПС можуть заповнювати гулаг.

Якщо не вказувати, то буде взято ім'я секції з цього файлу виходячи з назви рівня, на якому знаходиться гулаг.

idle = <min_time>, <max_time> - мінімальний та максимальний час (в ігровому годиннику) бездіяльності гулага,

після того, як гулаг залишив (з різних причин) останній НПС. Буде взято випадкове число із цього проміжку.

Якщо вказати одне число, буде взято в проміжку від нуля, до цього числа.(?)

stay = <min_time>, <max_time> stay = quick/medium/long/default - мінімальний та максимальний час (в ігровому годиннику) перебування всіх НПС під гулагом.

Конкретні значення можна переглянути у файлі config\misc\smart_terrain.ltx у секції smart_terrain_stay_time .(?)

squad = <number> - сквад, який прописуватиметься всім сталкерам під гулагом. Якщо не вказано, буде взято squad з профілю НПС.
group = <number>, <number>, ... - набір group через коми. Якщо не вказано, буде взято gruop з профілю НПС.

Гулаги

Гулаг - засіб поєднання кількох сталкерів під централізованим управлінням.
Основні особливості:

• Є список робіт гулага. Робота – налаштована схема поведінки (або ланцюжок схем поведінки);
• Роботи мають пріоритети;
• Гулаг призначає роботи сталкерів які входять у гулаг, починаючи з робіт із найвищим пріоритетом;
• Гулаг має стан. Кожен стан характеризується своїм набором робіт, відмінним від набору робіт у будь-якому іншому стані гулага.

Рекомендації щодо планування гулага:

1. Необхідно чітко визначити набір станів гулага: день, ніч, спокійне, при тривозі тощо. Для простих гулагів достатньо одного стану, для крутих та складних – бажано різні. Це надає різноманітності і виглядає краще.
2. Визначаємо максимальну кількість людей, яким гулаг може керувати. Тобто визначаємо місткість гулага. Вона має бути такою, щоб у будь-якому стані гулага гарантовано знайшлося заняття для кожної людини.
3. До кожного стану гулага визначається набір робіт. Ці роботи можуть бути як активного плану (годинний, патруль тощо), так і пасивного плану (сидять навколо багаття, сплять). Кожна робота має власний пріоритет. Відповідно, пасивні роботи повинні мати менший пріоритет.
4. У редакторі ставиться об'єкт smart_terrain (джерело помилок – іноді ставлять space_restictor ). Гулагу смарта треба давати осмислену назву. Ця ж назва буде префіксом до назви всіх патрульних шляхів, що належать до цього ж гулагу . Наприклад, якщо ви назвали гулаг esc_blockpost , то всі патрульні шляхи повинні починатися з цього префікса, наприклад esc_blockpost _guard_walk .

Створення гулага:
1. Створити smart_terrain та налаштувати його custom_data згідно з описом вище.

2. У скрипті scripts\gulag_назва_уровня.script необхідно прописати умови, за яких сталкери беруться під конкретний гулаг. У функцію checkNPC необхідно прописати умову:

if gulag_type == "ім'я_гулага"  then 
	return npc_community == "ім'я_угруповання" 
end

У цю функцію поки що передається два параметри, тип гулага і комьюніті персонажа. Прийматиметься під гулаг лише НПС із зазначеним угрупованням.

3. У файлі scripts\gulag_назва_уровня.script необхідно описати перемикання станів гулага у функції function loadStates(gname, type) . До неї передається ім'я смарта та ім'я гулага. Стан гулагу описується як функції, повертає номер стану гулагу. Наприклад:

if  type == "ім'я_гулага"  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 годин, то гулаг перебуває у денному стані (0), інакше у нічному(1).

4. У файлі scripts\gulag_назва_уровня.script необхідно описати роботи гулага. У функції load_job(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

Опис можливих полів для опису роботи:
section – секція в config\misc\gulag_назва_уровня.ltx , де вказуються реальні налаштування схеми поведінки, що відповідає поточній роботі.
idle – пауза між повторним виконанням того самого завдання. У разі паузи немає. Зазвичай пауза ставиться патруль.
prior – пріоритет завдання. Спочатку НПС займають пріоритетніші завдання. Чим більше число, тим вищий пріоритет.
in_rest, out_rest – рестриктори, які встановлюються персонажу на дане завдання. З in_rest НПС заборонено виходити, в out_rest - заборонено входити.
state - стан гулага. Необхідно функції load_states , де визначається цей стан, тобто. у яких станах ця робота буде доступна.
squad – таблички сквадів, якщо нам потрібно перевизначати рідні групи сталкерів на якісь інші.
group - буде обрано з масиву groups , який заданий в custom_data .
info_rest – якщо на поточній роботі щось дратує НПС, то будучи в зоні встановленого інфо-рестриктора – подразник буде проігнорований.
predicate - умова прийому працювати. Вказувати потрібно функцію, яка повертає true або false .
position_threshold - відстань до місця роботи при якому персонаж в онлайні вважається таким, що досяг місця роботи.
timeout - це час, яким задається тривалість роботи. Якщо її поставити, то НПС виконуватиме роботу саме заданий час,

після чого буде звільнений з роботи (якщо раніше не був від неї звільнений). Після звільнення робота може бути доступною для повторної видачі.

online – якщо true – НПС на даній роботі завжди в онлайні.
idle_after_death - протягом цього часу після смерті попереднього "працівника" ця робота буде недоступна.

5. У config\misc\gulag_назва_уровня.ltx необхідно вказати, які схеми поведінки відповідають тій чи іншій роботі.
Налаштування тут відповідає налаштуванню у звичайній custom_data сталкера, з різницею:

1. Шляхи слід вказувати без префіксу . Тобто якщо гулаг носить ім'я, наприклад, gar_maniac , то шляхи слід на рівні ставити з назвою gar_maniac _walk1 , проте в config\misc\gulag_назва_уровня.ltx слід вказувати тільки walk1 .
2. У іменах секцій logic кожної роботи додавати після @ ім'я гулага, додаткові відомості та ім'я секції активної схеми поведінки. Наприклад: logic@gar_maniac_walker_gate .

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

Можливості нового смарттеррейну (СТ):

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

Що потрібно переробити:

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

Налаштування: -------------

Дозволи персонажам йти у певні СТ ----

Дозволи персонажам йти в певні СТ задаються в custom data секцією [smart_terrains]. У ній можна задавати пари "ім'я_СТ=condlist". Приклад:

[smart_terrains]
strn_1 = умова1
strn_2 = умова2

Якщо для якогось smart_terrain умова виконалася, вона називається ексклюзивною.
Якщо в об'єкта з'явився хоч один ексклюзивний smart terrain, то він згоден йти тільки в нього. Якщо не з'явилося жодного ексклюзивного, то він згоден йти до будь-якої.

Існує зарезервоване поєднання "none=true". Якщо воно зазначено, то персонаж ніколи не піде в жодний СТ. Такий персонаж працюватиме лише під своєю логікою.

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

communities = угруповання1, угруповання2, ...

Якщо це поле не задано, перевіряється старим механізмом. Якщо поставлено, то під СТ візьмуться лише персонажі зазначених угруповань (врахуйте, старий механізм теж викличеться).

Зміна функцій predicate() ----

У ці функції замість game_object передаватиметься табличка з інформацією про персонажа. Там є поля:
name
community
class_id
story_id
profile_name

Якщо потрібно, щоб робота займалася лише снайперами, то у предикаті потрібно писати:

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(назва гулага) = {кондлист} - якщо тільки один смарттеррейн сталкер зможе прийти, то пишемо true.
Якщо цей товариш не повинен працювати під смарттеррейнами, пишемо йому в кастому дату.
[smart_terrains]
none = true

Передача параметрів у функції

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

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

Опис функцій з параметрами присутніх у xr_conditions та xr_effects .

  [hit]
  on_info = {=hitted_by(407:408)} %+val_escort_combat%.

  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)%

  sid - story_id об'єкта, яким наноситься хіт.
  bone – рядок. Ім'я кістки, по якій завдається удару.
  power – сила удару.
  impulse – імпульс.
  hit_src (необов'язковий параметр) - точка (waypoint), з якої об'єктом наноситься хіт. 
Якщо не встановлено, то береться позиція об'єкта, з якого була викликана ця функція.

  weapon - сховати/показати руки зі зброєю.
  input - вимкнути/ввімкнути клавіатуру.
  hud – сховати/показати індикатори на екрані.
  all - вимкнути/включити усі елементи.

  on_info = %=disable_ui_elements(weapon:input)%

  on_info = %=enable_ui%

  on_info = %=run_cam_effector(prison_0)%

  file_name - ім'я файлу постпроцесу (без розширення) з папки gamedata\anims. Вказується без розширення.
  id – номер постпроцесу. Задається опціонально. Використовується в stop_postprocess.
  loop - (true/false) визначає зацикленість постпроцесу. Опціональний параметр. За промовчанням false.

  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