Версия 20:23, 14 августа 2007 (просмотреть исходный код) 78.106.25.142 (обсуждение) ← Предыдущая правка		Текущая версия на 15:36, 16 сентября 2014 (просмотреть исходный код) 109.251.47.24 (обсуждение) (→‎Схема sniper)
(не показаны 144 промежуточных версий 21 участника)
Строка 1:		Строка 1:
−	'''Made by GSC GameWorld'''	+	{{Шаблон:Настройка логики}}
−	=Настройки логики=
−	==3.1. Система флагов (path_walk, path_look)==	+	<center><font size=6>Настройки логики</font></center>
−	В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени 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 | другая_схема	+
		+	=Система флагов (path_walk, path_look)=
		+	В точках путей можно задавать флаги, изменяющие поведение персонажа. Флаги задаются прямо в имени '''''waypoint'''''-а, например, для точки с именем "'''''wp00'''''":<br>
		+	'''''wp00|flag1|flag2'''''<br>
−	==3.1.1. Более подробное описание путей. ==	+	Флаги точек пути '''''path_walk''''':<br>
		+	*'''a=state'''<br>
		+	:Выбирает состояние тела при перемещении (Только из раздела "Ходячие состояния")<br>
		+	:Список состояний можно взять в ''gamedata\scripts\state_lib.script''<br>
		+	*'''p=percent'''<br>
		+	:Вероятность остановиться в точке в процентах (0 – 100). По умолчанию 100, т.е. сталкер никогда не проходит мимо точек остановки.<br>
		+	*'''sig=name'''<br>
		+	:Установить сигнал с именем '''''name''''' сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля '''''on_signal''''' логической схемы. Если нужно установить сигнал после поворота – используйте соответствующий флажок пути *'''''path_look'''''.<br>
−	Walker.
−	Настройка:	+	Флаги точек пути '''''path_look''''':<br>
−		+	*'''a =state'''<br>
		+	:Выбирает состояние тела при стоянии (или сидении) на месте. (Из разделов "Стоячие" и "Сидячие" состояния)<br>
		+	:Список состояний можно взять в ''gamedata\scripts\state_lib.script''<br>
		+	*'''t=msec''' - время в миллисекундах, которое персонаж должен смотреть в заданную точку.<br>
		+	:'''*''' – бесконечное время. Допустимы значения в диапазоне [1000, 30000], по умолчанию – 5000.<br>
		+	:Для конечных (терминальных) вершин пути '''''path_walk''''', у которых не более 1-й соответствующей точки '''path_look''', значение '''''t''''' всегда считается бесконечным и его явно задавать не нужно.<br>
		+	*'''sig=name'''<br>
		+	:После поворота в точку '''''path_look''''', установить сигнал с именем '''''name'''''.<br>
		+	*'''syn'''<br>
		+	:Наличие флажка задержит установку сигнала до тех пор, пока в точку с флажком '''''syn''''' не прибудут все персонажи с данным '''''team'''''-ом ('''''team''''' задается в виде текстовой строки в '''''customdata'''''). До тех пор, пока остальные персонажи не прибудут, ожидающей персонаж будет отыгрывать свою '''''idle''''' анимацию.<br>
		+	*'''sigtm=signal'''<br>
		+	:Устанавливает сигнал при вызове '''''time_callback'''''-а '''''state manager'''''-ом. Соответственно, если '''''t=0''''', то сигнал будет установлен после отыгрывания '''''init''''' анимации. Это используется, например, с анимацией '''''press''''', которая состоит из двух частей: 1 - нажимаем на кнопку, 2 - опускаем руку.<br>
		+	:В пути '''''path_look''''' можно сделать:<br>
		+	:<ini>wp00|a=press|t=0|sigtm=pressed</ini>
		+	:А затем переключить схему:<br>
		+	:<ini>on_signal = pressed | другая_схема</ini>
−	На карту для каждого walker-а нужно поставить:	+	==Более подробное описание путей.==
−	1) Путь path_walk, по которому walker ходит.	+
−	2) Путь path_look, состоящий из точек, в которые walker смотрит.	+
−	Walker-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.	+	Настройка:<br>
		+	[[Изображение:Logic_1.JPG]]
−	[walker]	+	На карту для каждого walker-а нужно поставить:<br>
−	team = …	+	#Путь '''''path_walk''''', по которому '''''walker''''' ходит.<br>
−	имя команды, произвольная текстовая строка. Все walker-ы в одной команде должны иметь один и тот же team. Желательно в team задавать имя уровня и имя места, где стоят walker-ы, например: escape_bridge, escape_factory, это уменьшит шанс ошибиться и дать разным командам общее имя.	+	#Путь '''''path_look''''', состоящий из точек, в которые '''''walker''''' смотрит.<br>
−	path_walk = …	+
−	имя пути, описанного в п. 1	+
−	path_look = …	+
−	(не обязательно) имя пути, описанного в п. 2. Если персонаж должен только ходить по маршруту, path_look можно не задавать.	+
−	Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look	+
−	Правила расстановки флажков в путях рассмотрим на нескольких примерах:	+	'''''Walker'''''-ов может быть 1 или больше. Они могут действовать независимо, или взаимодействовать друг с другом.<br>
−	Пример 1:	+	Если персонаж должен стоять на месте, то ему задается одна точка пути '''''path_walk''''' и как минимум одна точка пути '''''path_look''''', хотя и можно не задавать точку взгляда вовсе (игра автоматически определит точку по умолчанию ту, в которую НПС смотрел изначально), делать этого не следует.<br>
−	Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом:	+	Правила расстановки флажков в путях рассмотрим на нескольких примерах:<br>
−		+
−	Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.	+	===Пример 1:===
−	У каждого вейпоинта есть имя: wp00, wp01 и т.д.	+
−	Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если a=raid то побежит с оружием наизготовку и т.д.	+
−	NB: В точках пути path_walk используются анимации ТОЛЬКО из раздела «Ходячие состояния»!	+	Персонаж патрулирует территорию вокруг двух домиков. Маршрут строится следующим образом: <br>
		+	[[Изображение:Logic_2.JPG]]
−	Пример 2:	+	Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути '''''path_walk''''' существуют флажки.<br>
		+	У каждого вейпоинта есть имя: '''''wp00''''', '''''wp01''''' и т.д.<br>
		+	Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘'''|'''’. Пишеться '''''a=anim''''', где '''''anim''''' – название анимации. Если мы напишем '''''a=threat''''' то персонаж пойдет в состоянии данжер, если '''''a=raid''''' то побежит с оружием наизготовку и т.д. <br>
−		+	'''''Примечание''''': В точках пути '''''path_walk''''' используются анимации '''ТОЛЬКО''' из раздела «Ходячие состояния»!
−	Разговор персонажа.	+	===Пример 2:===
		+	[[Изображение:Logic_3.JPG]]
−	Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:	+	Разговор персонажа.
−	s = имя_звуковой_схемы (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.	+
−		+
−	Пример 3:	+	Чтобы персонаж говорил, перемещаясь по маршруту, нужно определить в каждой точке список тем, на которые он может говорить. Для этого существуют следующие поля:<br>
		+	'''''s = имя_звуковой_схемы''''' - (по умолчанию звук отключен). Несколько тем можно перечислять через запятую.
−		+	===Пример 3:===
−	В примере 3 используется только поле s, чтобы задать тему разговора, и флажок sc, чтобы показать, что звук проигрывается не разово, а периодически.	+	[[Изображение:Logic_4.JPG]]
−	Остальные параметры (sp, sf, st) задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлимы для большинства скриптов.	+
−	Параметр sa также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути path_look, о котором будет написано ниже в этом документе.	+
−	Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь path_look.	+
−	Пример 4: усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:	+	В примере 3 используется только поле '''''s''''', чтобы задать тему разговора, и флажок '''''sc''''', чтобы показать, что звук проигрывается не разово, а периодически.<br>
		+	Остальные параметры ('''''sp''''', '''''sf''''', '''''st''''') задавать НЕ РЕКОМЕНДУЕТСЯ, значения по умолчанию приемлемы для большинства скриптов.<br>
		+	Параметр '''''sa''''' также использовать НЕ РЕКОМЕНДУЕТСЯ. Если нужно стартовать звук одновременно с анимацией, лучше воспользоваться полями пути '''''path_look''''', о котором будет написано ниже.<br>
		+	Если персонаж не только ходит по маршруту, но должен также останавливаться и играть анимации, нужно задать ему путь '''''path_look'''''.<br>
		+	===Пример 4:===
		+	усовершенствуем пример 1, чтобы персонаж, проходя мимо проема между домами, останавливался и заглядывал в него:
−	Что добавилось в этом примере? Путь path_look с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.	+	[[Изображение:Logic_5.JPG]]
−	Далее, в точках путей path_walk и path_look, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки. Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.	+	Что добавилось в этом примере? Путь '''''path_look''''' с двумя точками. Связь между точками этого пути рекомендуется сразу же удалить в редакторе, поскольку она все равно не используется.<br>
−	Теперь персонаж будет останавливаться в точках path_walk, помеченных флажком, и смотреть в точку path_look, помеченную тем же самым флажком.	+	Далее, в точках путей '''''path_walk''''' и '''''path_look''''', которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки (в ''ACDC'' поле '''''flags'''''). Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.<br>
−	Если точка path_walk не помечена флажком, персонаж проходит ее не останавливаясь.	+	Теперь персонаж будет останавливаться в точках '''''path_walk''''', помеченных флажком, и смотреть в точку '''''path_look''''', помеченную тем же самым флажком.<br>
−	Одной точке path_walk может соответствовать несколько точек path_look. Тогда персонаж выберем случайно одну из подходящих точек.	+	Если точка '''''path_walk'''''  не помечена флажком, персонаж проходит ее не останавливаясь.<br>
−	По аналогии с path_walk, в точках пути path_look можно использовать различные флажки, меняющие поведение:	+	Одной точке '''''path_walk''''' может соответствовать несколько точек '''''path_look'''''. Тогда персонаж выберем случайно одну из подходящих точек.<br>
−	p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех подходящих точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).	+	По аналогии с '''''path_walk''''', в точках пути '''''path_look''''' можно использовать различные флажки, меняющие поведение:<br>
−	Во избежание путаницы, рекомендуется задавать p так, чтобы их сумма составляла 100.	+
−	По умолчанию у всех точек p = 100.	+
−	t = время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)	+	'''''p = 100''''' – вероятность, с которой персонаж посмотрит именно в эту точку. Значения '''''p''''' всех подходящих точек суммируются, т.е. если у одной точки '''''p = 100''''', а у другой '''''p = 300''''', то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).
		+	Во избежание путаницы, рекомендуется задавать '''''p''''' так, чтобы их сумма составляла '''100'''.
		+	По умолчанию у всех точек '''''p = 100'''''.<br>
−	Пример 5:	+	'''''t = 5000''''' - время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)<br>
−	В этом примере проходя через точку wp00, персонаж с вероятностью 30% посмотрит в точку wp00 в течение 5 секунд, но с вероятностью 70% посмотрит в точку wp01 в течении 10 секунд.	+	===Пример 5:===
−	По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.	+	[[Изображение:Logic_6.JPG]]
−	Если требуется другая анимация, можно ее указать с помощью флажка:	+	В этом примере проходя через точку '''''wp00''''', персонаж с вероятностью 30% посмотрит в точку '''''wp00''''' в течение 5 секунд, но с вероятностью 70% посмотрит в точку '''''wp01''''' в течении 10 секунд.<br>
−	a = имя_анимации (по умолчанию idle).	+	По умолчанию при остановках персонаж играет анимацию '''''idle''''', если он не в состоянии '''''crouch''''', либо анимацию '''''hide''''', если он в состоянии '''''crouch'''''.<br>
−	Пишеться a=anim, где anim – название анимации из пункта 2.4.4. настоящей документации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет  с оружием наизготовку и т.д.	+
−	NB: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!	+	Если требуется другая анимация, можно ее указать с помощью флажка:<br>
		+	'''''a = имя_анимации''''' - (по умолчанию '''''idle'''''). <br>
		+	Пишеться '''''a=anim''''', где '''''anim''''' – название анимации. Если мы напишем '''''a=hide''''', то персонаж сядет в состоянии данжер, если '''''a=guard''''', то встанет  с оружием наизготовку и т.д. <br>
−	==3.2. Схемы поведения сталкеров.==	+	'''''Примечание''''': В точках пути '''''path_look''''' используются анимации '''ТОЛЬКО''' из раздела «Стоячие и сидячие состояния»!
−	Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.	+
−	В файле \gamedata\scripts\modules.script указаны все загружаемые схемы.	+
−	3.2.1. Схема walker	+
−	Это базовая схема, по которой персонаж, перемещается по патрульному пути (path_walk) и останавливается в определенных точках и выполняет соответствующие действия.	+
−	[walker]	+	==Система флагов для монстров==
−	path_walk = <имя пути>- основной путь, по которому ходит NPC	+	Флаги пути движения:<br>
−	*path_look  = <имя пути>- путь, куда смотрит NPC	+	'''''s=имя_звуковой_темы'''''<br>
−	*team - команда для синхронизации	+	:Устанавливает звуковую тему на пути в данную точку ('''''idle''''', '''''eat''''', '''''attack''''', '''''attack_hit''''', '''''take_damage''''', '''''die''''', '''''threaten''''', '''''steal''''', '''''panic''''', '''''growling''''').<br>
		+	'''''с'''''<br>
		+	:Устанавливает положение ходьбы вприсядку.<br>
		+	'''''r'''''<br>
		+	:Устанавливает положение ходьбы бег.<br>
		+	'''''sig=name'''''<br>
		+	:Установить сигнал с именем '''''name''''' сразу по прибытию в точку (до поворота) для последующей его проверки с помощью поля '''''on_signal''''' логической схемы.<br>
		+	'''''b=vis/invis'''''<br>
		+	:Флаг, исключительно для кровососа. Управляет невидимостью ('''''vis''''' - отключена, '''''invis''''' - включена).
−	В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.	+	Флаги пути обзора:<br>
−	* def_state_moving1 = состояние, в котором сталкер движется к первой точке пути, если она близко (patrol по умолчанию)	+	'''''t=msec'''''<br>
−	* def_state_moving2 = состояние, в котором сталкер движется к первой точке пути, если она не слишком далеко (rush по умолчанию)	+	:Время в миллисекундах, которое нужно ждать, смотря в точку.<br>
−	* def_state_moving3 = состояние, в котором сталкер движется к первой точке пути, если она далеко (sprint по умолчанию)	+	'''''a=state'''''<br>
−	* def_state_standing = дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.	+	:Анимация ('''''stand_idle''''', '''''sit_idle''''', '''''lie_idle''''', '''''eat''''', '''''sleep''''', '''''rest''''', '''''attack''''', '''''look_around''''', '''''turn''''').<br>
		+	==Случайный выбор пути==
		+	По поводу точек пути '''''path_walk'''''.<br>
		+	Есть ещё один интересный факт: следующую точку пути '''''path_walk''''' можно задавать рандомно.<br>
		+	Например:[[Файл:Random_path.jpg]]
−	Файл: \gamedata\scripts\xr_walker.script	+	Нам требуется, чтобы НПС стоящий в точке '''''p0''''' патрулировал территорию по двум цикличным маршрутам:<br>
−	==3.2.2. Схема remark==	+	'''''p0 -> p1 -> p2 -> p0'''''<br>
−	Схема используется для синхронизации\связки других схем.	+	'''''p0 -> p3 -> p4 -> p0'''''<br>
		+	Чтобы задать вариацию выбора маршрута относительно точки '''''p0''''', нужно в ссылке на следующую точку пути указать не одну, а две точки:<br><ini>p0:links = p1(1), p3(1)</ini>Таким не хитрым образом, НПС для продолжения пути рандомно выберет одну из предложенных точек '''''p1''''' или '''''p3'''''. После возврата в точку '''''p0''''' выбор проследует вновь. Варьировать выбор можно в любой точки, например, можно сделать так:<br><ini>p0:links = p1(1), p3(1)</ini>а в точке '''''p1''''', также задать выбор:<br><ini>p1:links = p2(1), p3(1)</ini>
		+	'''НО!'''
		+	Не следует делать выбор между двумя путями, если в пути одна точка! Вот такая схема '''НЕ ПРИЕМЛЕМА''' и, лично у меня, вызывает вылет:[[Файл:Error_random_path.jpg]]
		+	Цифры в скобках, означают ту самую вероятность с которой НПС пойдёт в точку. Если цифры задать одинаковые, то и вероятность выбора для каждой точки будет равная, если же, например, в одной из точек указать значение 0.75, а в другой 0.25:<br><ini>p1:links = p2(0.75), p3(0.25)</ini>то соответственно в точку '''''p2''''' НПС будет ходить в три раза чаще.
−	[remark]	+	=Схемы поведения сталкеров.=
−	*snd_anim_synс = true либо false. По умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией либо нет	+	Есть определенный набор схем, которые описывают поведение персонажа. Они прописываются у него в custom_data или, в случае гулага, в соответствующих файлах, описывающих работы данного гулага. Ниже приведен перечень этих схем.<br>
−	*snd  = звук ремарка, по умолчанию nil	+	В файле ''gamedata\scripts\modules.script'' указаны все загружаемые схемы.<br>
−	*anim = анимация ремарка, по умолчанию wait	+
−	*target = Куда смотрит сталкер. Есть следующие варианты	+
−	story_id – числовое значение	+
−	actor – без комментариев	+
−	nil – позиция вычисленная АИ автоматически	+
−	<имя работы>,<имя гулага> смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг сталкера, для которого задана данная секция ремарка).	+
−	Пример:	+
−	target              = logic@cit_killers_base_guard, cit_killers	+
−	<path_name>, <point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>, <имя точки>).	+
−	Внимание, теперь если значение не задано, то оно равно nil а не actor, как было раньше. То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение nil, то персонаж развернется в позицию, которую посчитает АИ.	+	==Схема walker==
		+	Это базовая схема, по которой персонаж, перемещается по патрульному пути ('''''path_walk''''') и останавливается в определенных точках и выполняет соответствующие действия. <br>
−	Стандартные сигналы для remark:	+	'''[walker]'''<br>
−	sound_end – по окончании проигрывания звуковой схемы	+	'''''path_walk = <имя_пути>'''''    - основной путь, по которому ходит NPC<br>
−	anim_end – по окончании проигрывания анимации	+	'''''path_look = <имя_пути>'''''    - путь, куда смотрит NPC<br>
−	action_end – по окончании проигрывания и того и другого, если они синхронизированы	+	'''''team      = <имя_команды>''''' - команда для синхронизации<br>
		+	'''''def_state_moving1 = <название_анимации>'''''  - состояние, в котором NPC движется к первой точке пути, если она близко ('''''patrol''''' по умолчанию)<br>
		+	'''''def_state_moving2 = <название_анимации>'''''  - состояние, в котором NPC движется к первой точке пути, если она не слишком далеко ('''''rush''''' по умолчанию)<br>
		+	'''''def_state_moving3 = <название_анимации>'''''  - состояние, в котором NPC движется к первой точке пути, если она далеко ('''''sprint''''' по умолчанию)<br>
		+	'''''def_state_standing = <название_анимации>''''' - дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.<br>
−	Пример синхронизации анимации и звука в схеме Remark:	+	В точках '''''path_walk''''', которым соответствуют точки пути '''''path_look''''' (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.<br>
−	[remark]	+
−	anim = анимация	+
−	snd = звук	+
−	snd_anim_sync = true	+
−	on_signal = action_end | следующая схема	+
−	3.2.3. Схема sleeper	+
−	Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1 поинта. Спящий будет садиться спать в нулевой точке пути, и разворачиваться при этом в сторону первой точки.	+
−	[sleeper]	+	'''''Пример использования схемы''''':<br><ini>[walker@pri_followers_leader_wave1_wait]
−	path_main = <имя пути>	+	path_walk = wave1_leader_walk2
−	*wakeable = true – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет)	+	path_look = wave1_leader_look2
		+	def_state_moving1 = assault
		+	def_state_moving2 = assault
		+	team = followers</ini>
−	NB: Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).	+	Файл: ''gamedata\scripts\xr_walker.script''
−	Файл: \gamedata\scripts\xr_sleeper.script	+	==Схема remark==
		+	Схема используется для синхронизации\связки других схем.<br>
−	==3.2.4. Схема kamp==	+	'''Примечание''': не используйте эту схему в качестве активной - это вызовет неправильное поведение NPC.
−	Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.	+
−		+
−	[kamp]	+
−	center_point = kamp_center – имя точки вокруг которой NPC будет устраиваться.	+
−	*radius = 2 (насколько далеко сталкер будет сидеть от центра лагеря, 2- по умолчанию)	+
−	*def_state_moving = run (дефолтное состояние, в котором сталкер будет идети к точке кампа)	+
−	Файл: \gamedata\scripts\xr_kamp.script	+	'''[remark]'''<br>
		+	'''''snd_anim_synс = true/false''''' - по умолчанию '''''false'''''. Указывает на то необходимо ли синхронизировать звук с анимацией.<br>
		+	'''''snd = <название_звуковой_темы>''''' - звук ремарка, берётся из файла ''sound_theme.script''. По умолчанию  '''''nil'''''.<br>
		+	'''''anim = <название_анимации>''''' - анимация ремарка, по умолчанию '''''wait'''''.<br>
		+	'''''target = <параметр>''''' - куда смотрит сталкер. Есть следующие варианты:<br>
		+	:*'''''story_id''''' – числовое значение в ТЧ и ЧН или строковое, с указанием дополнительного параметра и самого SID, в ЗП, в примере ниже указана часть логики монолитовца-проповедника в Припяти, когда тот стреляет в Айса<nowiki>;</nowiki><br>
		+	:Пример (ЗП):<br>
		+	:<ini>target =  story | pri_a17_military_sergeant_morozov</ini>
		+	:*'''''actor''''' – без комментариев<nowiki>;</nowiki><br>
		+	:*'''''nil''''' – позиция вычисленная АИ автоматически<nowiki>;</nowiki><br>
		+	:*'''''<имя работы>,<имя гулага>''''' - смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг NPC, для которого задана данная секция ремарка).<br>
		+	:Пример:<br>
		+	:<ini>target = logic@cit_killers_base_guard, cit_killers</ini>
		+	:*'''''<path_name>,<point_number>''''' - можно указывать смотреть в вершину патрульного пути (<имя пути>,<имя точки>).<br>
		+	:Пример:<br>
		+	:<ini>target = cit_killers_kamp5,0</ini>
−	NB! Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажуться внутри костра, где и получат хит. Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой = <path_kamp_name>_task
−	*path_walk = <path_kamp_name>_task	+	'''''Примечание''''': теперь если значение не задано, то оно равно '''''nil''''' а не '''''actor''''', как было раньше.<br>
		+	:То есть если вы хотите чтобы персонаж в ремарке смотрел на актера - необходимо явно прописывать это. Если задано значение '''''nil''''', то персонаж развернется в позицию, которую посчитает АИ.<br>
−	Если точка кемпа расположена в чистом поле то, path_walk прописывать не надо.
−	==3.2.5. Схема camper==	+	Стандартные сигналы '''''remark'''''а для параметра переключения схемы '''''on_signal''''': <br>
−	Свойства кемперов:	+	:*'''''sound_end''''' – по окончании проигрывания звуковой схемы<br>
−	- кемпер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передигается по патрульным путям	+	:*'''''anim_end''''' – по окончании проигрывания анимации<br>
−	- кемперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возращается в состояние кемпера.	+	:*'''''action_end''''' – по окончании проигрывания и того и другого, если они синхронизированы<br>
−	- В любых других случаях действуют по собственной скриптовой схеме. Если видим врага -стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага.	+
−	- кемперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.	+
−	[camper]	+	'''''Пример использования схемы''''':<br><ini>[remark@esc_lager_volk2]
−	path_walk = patrol_path	+	anim = guard_rac
−	path_look = patrol_path	+	snd = esc_wolf_radio
−	*radius = number – расстояние в метрах, если расстояние между кэмпером и противником меньше указанного, кэмпер уходит в универсальный комбат. По умолчанию этот радиус равен 20 метрам.	+	target = actor
−	*no_retreat = true - персонаж при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания. Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите кемперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.	+	on_signal = sound_end| remark@esc_lager_volk3</ini>
−	*def_state_moving = состояние из стейт менеджера	+
−	Состояние, в котором мы движемся на ближайшую точку пути при враге	+
−	*def_state_moving_fire = состояние из стейт менеджера (sneak_fire)	+
−	Состояние, в котором мы отстреливаемся от врага, во время движения на ближайшую точку пути.	+
−	*def_state_campering = состояние из стейт менеджера (hide)	+
−	Состояние, в котором мы ожидаем врага, находясь на пути	+
−	*def_state_campering_fire = состояние из стейт менеджера (hide_fire)	+
−	Состояние, в котором мы отстреливаемся от врага, находясь на пути	+
−	*attack_sound = имя_звуковой_темы	+
−	Возможность переопределять снайперам/кемперам звук атаки. По дефолту он равен звуковой теме "fight_attack". Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав в секции кемпера: attack_sound =	+
−	*shoot = тип.	+
−	Задаем тип стрельбы. Возможные значения - always|none|terminal	+
−	always - значение по умолчанию, стреляет всегда, когда можно	+
−	none - не стреляет вообще.	+
−	terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.	+
−		+
−	NB! У кемпера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела), то он тупо продолжает стоять на старом месте и ждать следующей пули.	+
−	Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или стелкеры смогут атаковать поставленного кемпера. Используйте walkerов в таких случаях, а кемперов стоить ставить для атак по путям и как снайперов.	+
−	==3.2.5.1. Схема sniper==	+	Файл: ''gamedata\scripts\xr_remark.script''
−	Разновидность кемпера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20сек.	+
−	NB! Ставить снайперу только 2 точки look	+
−	В кастом дате кемпера прописать:	+	==Схема sleeper==
−	sniper = true	+	Схема сидящего и спящего NPC. Необходимо поставить патрульный путь, минимум из 1-го поинта. Спящий будет садиться спать в первой точке пути, и разворачиваться при этом в сторону нулевой точки.<br>
		+	'''[sleeper]'''<br>
		+	'''''path_main = <имя_пути>''''' - точка в которой NPC будет спать - второй поинт, развернувшись в нулевой поинт.<br>
		+	'''''wakeable = true/false''''' – может ли проснуться быстро (если '''''true''''', то спит на корточках и во сне бормочет).<br>
−	Файл: \gamedata\scripts\xr_camper.script
−	==3.2.6. Схема follower==	+	'''''Примечание''''': Если путь состоит из двух точек, то связь нужно делать от первой точки к нулевой (либо двунаправленную).<br>
−	В custom_data прописан как follower	+
−	NPC идет за NPC лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме run, если свыше 20 – догоняет в режиме sprint. Пути не задаются.	+
−	[follower]	+	'''''Пример использования схемы''''':<br><ini>[sleeper@esc_blockpost_sleep1]
−	leader = story id лидера из game.ltx (число!)	+	path_main = sleep1
−	*formation_line = true (постарается идти сбоку от лидера, в противном случае будет идти сзади	+	wakeable = false</ini>
−	*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 лидера, мы прописываем его секцию  логики в файле скрипта. Пример:	+	Файл: ''gamedata\scripts\xr_sleeper.script''
−		+
−	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 = задает изначальный режим перемещения, по умолчанию patrol. Вообще, значение этого поля есть название ходячей анимации из state_mgr_lib	+
−		+
−	formation  - описывет способ построения и не является обязательным. Возможны следующие варианты:	+
−	back    - мужики идут чуть позади командира в два ряда (по умолчанию)	+
−	line    - шеренга	+
−	around  - вокруг командира	+
−		+
−	При остановке командора в 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	+
−	400 – это 202  . Примечание – мы пишем квадрат нужного нам расстояния, для экономии системных ресурсов.	+
−		+
−		+
−	Ещё один пример. Сталкер ходит под симуляцией, но у него бой не движковый, а всегда зомбированый:	+
−		+
−	[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(pасстояние в метрах) – универсальная функция для combat_ignore, проверка расстояния для игрока	+
−		+
−		+
−	fighting_actor -- текущий враг актёр?	+
−	check_fighting -- проверка (по story_id) того, что нашим врагом есть хотя бы кото-то один из списка	+
−		+
−	Файл: \gamedata\scripts\xr_combat_ignore.script	+
−		+
−	==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 = <number>	+
−	ignore_monster = <number>	+
−		+
−	Второй параметр следует менять ОЧЕНЬ осторожно.	+
−		+
−	==3.3.10. Danger==	+
−		+
−	Настройка может задаваться только в какой-то схеме, например:	+
−		+
−	[walker]	+
−	danger = danger_condition	+
−		+
−	[danger_condition]	+
−	ignore_distance = 50 (расстояние указывается в метрах)	+
−	ignore_ distance_grenade =	+
−	ignore_ distance_corpse =	+
−	ignore_ distance_hit =	+
−	ignore_ distance_sound =	+
−		+
−	Можно также указывать время ожидания для денжера в зависимости от типа:	+
−		+
−	danger_inertion_time_grenade =	+
−	danger_inertion_time_corpse =	+
−	danger_inertion_time_hit =	+
−	danger_inertion_time_sound =	+
−		+
−	Дефолтовые настройки:	+
−	danger_inertion_time_grenade  = 20000	+
−	danger_inertion_time_corpse  = 10000	+
−	danger_inertion_time_hit      = 60000	+
−	danger_inertion_time_sound    = 15000	+
−		+
−	NB!!Также эти настройки теперь распространяются и на схему кемпера. То есть в настройках кемпера перестало работать поле danger_radius. Теперь данные берутся из секции денжера согласно общих правил.	+
−		+
−	Алгоритм работы такой: Сперва проверяется, что расстояние до опасности не отсекается по ignore_danger. Если опасность ближе, то тогда анализируется ее тип, и проверяется по соотвествующему данному типу расстоянию. Если опасность ближе - тогда разрешается реакция на нее.	+
−		+
−	В данный момент установлены следующие дефолты:	+
−		+
−	ignore_distance = 50	+
−	ignore_distance_grenade = 15	+
−	ignore_distance_corpse = 10	+
−	ignore_distance_hit = 50	+
−	ignore_distance_sound = 50	+
−		+
−	NB: если надо, чтобы в разных случаях сталкер игнорировал разные типы данжеров, создается несколько секций данжера danger_condition@1, danger_condition@2 и так далее.	+
−		+
−	* danger_expiration_time = Через сколько времени денжер перестанет быть акутальным. Дефолт 5000 мс.	+
−	* danger_inertion_time = Через сколько времени персонаж забудет про денжер, на который он отреагировал. Дефолт 10000 мс.	+
−		+
−	==3.3.11. Байки из склепа (Истории у костра)==	+
−	Из нового: теперь лагеря автоматически рассказывать истории не будут. Для этого вы должны того или иного сталкера "научить" истории.	+
−	Делается это так: в кастом дате пишется секция:	+
−		+
−	[game_info]	+
−	stories = "story_01, legend_01"	+
−		+
−	В кавычках список историй и легенд через запятую. Пока что существуют следующие истории и легенды:	+
−		+
−	story_01 - Граница зоны и граната за 1 действие.	+
−	story_02 - Про трамплин и про камешки	+
−	story_03 - Про то как группа Вильнова вернулась	+
−	story_04 - Про то как Костя Федорин наткнулся на артефакт и пропал на радаре.	+
−	story_05 - Про то как духманам с контролером стражаться.	+
−	story_06 - Про дверцу, водку и избушку.	+
−	legend_01 - Про эксперимент в Зоне, который производят инопланетяне.	+
−	legend_02 - Об особо засекреченных лабораториях в зоне.	+
−	legend_03 - Легенда о проводнике	+
−	legend_04 - Легенда о темном сталкере	+
−	legend_05 - Легенда о том что глубоко в Зоне спать нельзя.	+
−		+
−	О том какие истории и легеды в каком лагере на каком уровня можно и нельзя юзать узнавать о Профа.	+
−		+
−	==3.3.12. dont_spawn_loot==	+
−	Всякого рода сюжетные персонажи которые должны быть пустыми после смерти (например раненные или пленные) оказываются не пустыми. Чтобы это исправить необходимо в кастом дате персонажа прописать секцию	+
−	[dont_spawn_loot]	+
−		+
−	==3.4. Оверрайды:==	+
−	Настройки, которые меняют поведение общих схем, в зависимости от активной в данный момент обычной схемы (все они необязательны)	+
−	*meet_enabled = true (запускает схему встречи)	+
−	*meet_talk_enabled = true (в действующую схему поведения добавляет возможность диалога)	+
−	*meet_dialog  = <название диалога>, который будет запущен при юзе.	+
−	*meet_state = <название состояния> он определяет, в каком состоянии будет находиться персонаж, если  открылось диалоговое окно общения и торговли	+
−	*wounded_enabled = true (включает NPC возможность использовать схему раненого)	+
−	*combat_ignore_cond  = см. выше	+
−	*combat_ignore_keep_when_attacked = true (игрок продолжает игнорировать бой, даже если в него стреляют – ТОЛЬКО В СЛУЧАЕ СТРЕЛЬБЫ ИГРОКА!!!!)	+
−	*combat_type = {условие} scheme - тип боя которым будет пользоваться npc из данной схемы	+
−	*on_combat = см. выше	+
−	*companion_enabled = true (cвободноходящие сталкеры могут наниматься как компаньоны (в будущем они будут брать за это деньги)).	+
		+	==Схема kamp==
		+	Схема сталкера, сидящего в определенном радиусе вокруг указанной точки (у костра), и располагающегося лицом к этой точке.<br>
−	==3.5. Схемы для монстров==	+	'''[kamp]'''<br>
		+	'''''center_point = <имя_пути>''''' – имя точки вокруг которой NPC будет устраиваться.<br>
		+	'''''radius = <number>''''' - насколько далеко сталкер будет сидеть от центра лагеря. По умолчанию - 2 метра.<br>
		+	'''''def_state_moving = <название_анимации>''''' - дефолтное состояние, в котором NPC будет идти к точке кампа. По умолчанию - '''''walk'''''<br>
−	==3.5.1. Схема mob_walker.==
−	Работает аналогично схеме обычного walker. Но есть некоторые отличия
−	Флаги пути движения	+	'''''Примечание''''': Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажутся внутри костра, где и получат хит.<br>
−	s=звуковая_схема (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling) с - идти дальше в присяде r - дальше бежать sig=signal_name - установить заданный сигнал для xr_logic	+	:Чтобы этого не случалось в секции кемпа указывать '''''path_walk''''' из одной точке, название которой '''''<path_kamp_name>_task''''':<ini>path_walk = <имя_пути>_task</ini>Если точка кемпа расположена в чистом поле то, '''''path_walk''''' прописывать необязательно.<br>
−	Флаги пути обзора:	+
−	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	+
−	У кровосососов можно управлять невидимостью:	+	'''''Пример использования схемы''''':<br><ini>[kamp@esc_blockpost_kamp1]
−	[mob_walker]	+	center_point = kamp_center
−	...	+	path_walk = kamp_center_task
−	state = vis	+	def_state_moving = raid</ini>
−	или	+
−	state = invis	+
−	Задает значение по умолчанию.	+
−	Также в флагах walk пути mob_walker-а можно использовать флажок b	+	Файл: ''gamedata\scripts\xr_kamp.script''
−	(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	+
		+	==Схема camper==
		+	Свойства камперов:
		+	* кампер стоит на точке и смотрит в направлении, куда Вы его поставили в редакторе или передвигается по патрульным путям;<br>
		+	* камперы переключаются на универсальный комбат, только если видят врага ближе чем в 30 метрах. Если он выжил, он возвращается в состояние кампера;<br>
		+	* В любых других случаях действуют по собственной скриптовой схеме. Если видим врага - стреляем. Если слышим дэнжер - то смотрим в направление в данжере. Если видим гранату - убегаем от гранаты. Если видели врага, а враг исчез, то смотрим в точку, где видели последний раз врага;<br>
		+	* камперы не сражаются в движении. Если они видят врага - они останавливаются, стреляют, а потом продолжают движение.<br>
−	==3.5.3. Схема mob_remark==	+	'''[camper]'''<br>
−	Ремарковая схема, только не для сталкеров, а для монстров.	+	'''''path_walk = <имя_пути>''''' - путь по которому ходит NPC.<br>
		+	'''''path_look = <имя_пути>''''' - точки в которые смотрит NPC.<br>
		+	'''''radius = <number>''''' – если расстояние между NPC и противником меньше указанного, то он уходит в универсальный комбат. По умолчанию - 20 метров.<br>
		+	'''''no_retreat = true/false''''' - NPC при виде врага не будет ломиться на ближайшую точку '''''path_walk''''', а сразу перейдет в режим убивания.
		+	:Нужно это в том случае, если вы хотите сделать сценку, когда одни ребята наезжают на других. Ставите камперов с вышеуказанным флажком. Они идут по своим патрульным путям и выносят врагов.<br>
		+	'''''def_state_moving = <название_анимации>''''' - состояние, в котором NPC движется на ближайшую точку пути при враге. По умолчанию - '''''assault'''''.<br>
		+	'''''def_state_moving_fire = <название_анимации>''''' - состояние, в котором NPC отстреливается от врага, во время движения на ближайшую точку пути.
		+	:По умолчанию - '''''sneak_fire'''''.<br>
		+	'''''def_state_campering = <название_анимации>''''' - состояние, в котором NPC ожидает врага, находясь на пути. По умолчанию - '''''hide'''''.<br>
		+	'''''def_state_campering_fire = <название_анимации>''''' - состояние, в котором NPC отстреливается от врага, находясь на пути. По умолчанию '''''hide_fire'''''.<br>
		+	'''''attack_sound = <имя_звуковой_темы>''''' - возможность переопределять снайперам/камперам звук атаки. По дефолту он равен звуковой теме '''''fight_attack'''''.
		+	:Можно изменить на любое другое (для сценических потребностей) либо вообще отключить, прописав значение '''''false'''''.<br>
		+	'''''shoot = <тип_стрельбы>''''' - возможны следующие значения:
		+	:*'''''always''''' - значение по умолчанию, стреляет всегда, когда можно;<br>
		+	:*'''''none''''' - не стреляет вообще;<br>
		+	:*'''''terminal''''' - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.<br>
−	*state = специфическое состояние данного конкретного монстра (для кровососов - невидимость)
−	*dialog_cond = {+info, =func, -info, !func} условия для открытия окна диалога
−	*anim = анимации монстра, перечисляются через запятую.
−	*anim.head = анимации головы монстра, через запятую перечисляются
−	*tip = какой значок подсветится, при наведении на него курсора
−	*snd = какой звук издает
−	*time = время проигрывания анимаций, используется только для отладки.
−	Файл \gamedata\scripts\mob_remark.script
−	На этой схеме сделан торговец.
		+	'''''Примечание''''': У кампера есть один большой минус – когда ему наносится хит и он не знает откуда хит наносится (не видит противника, не слышит выстрела),<br>
		+	:то он тупо продолжает стоять на старом месте и ждать следующей пули.<br>
		+	:Ввиду этого не стоит расставлять кемперов в случае, когда сталкеры должны защищаться и держать позицию в том случае, если есть несколько направлений, откуда игрок или сталкеры смогут атаковать поставленного кампера. Используйте '''''walker''''' в таких случаях, а камперов стоить ставить для атак по путям и как снайперов.<br>
−	==3.5.4. Схема mob_combat, mob_death==	+	'''''Пример использования схемы''''':<br><ini>[camper@dar_military_scout_hide]
−	Работают точно также как и у сталкеров соответствующие схемы.	+	path_walk = walk_hide
−	Файлы: \gamedata\scripts\mob_combat.script, \gamedata\scripts\mob_death.script	+	path_look = look_hide
		+	radius = 10
		+	no_retreat = true
		+	def_state_moving = assault
		+	def_state_campering = hide_na
		+	shoot = always</ini>
−	==3.5.6 Схема mob_jump (монстр-пружинка)==	+	Файл: ''gamedata\scripts\xr_camper.script''
−	Схема mob_jump. Теперь mob_jump служит для задания прыжков монстров без каких либо проверок и ограничений (расстояние, углы и т.д.). Указывается позиция с помощью патрульного пути, смещение относительно этой позиции и физический фактор прыжка.	+
−	Пример:	+	==Схема sniper==
		+	Разновидность кампера. Отличаются тем, что стреляют только одиночными выстрелами и не смотрят по точкам патрульного пути, а сканируют пространство между ними. Скорость сканирования от точки к точке фиксирована и равна 20 секунд.
−	[logic]
−	active = mob_jump
−	[mob_jump]	+	В кастом дате кемпера прописать:<br><ini>sniper = true</ini>
−	path_jump = path	+	Пример:<br><ini>[camper@esc_blockpost_camper_day]
−	ph_jump_factor =2.8	+	path_walk = camper_day_walk
−	offset = 0,10,0	+	path_look = camper_day_look
−	on_signal = jumped | nil	+	sniper = true
		+	def_state_campering = threat</ini>
−	path_jump – путь, с помощью которого мы задаем 1 целевую точку прыжка (с нулевым индексом). Реальная точка учитывает позицию path_jump[0] + смещение, заданное с помощью offset.
−	offset – смещение по осям x,y,z соответственно, с помощью которого задается реальная точка в пространстве (может не находится на аи-ноде).
−	ph_jump_factor - влияет на время прыжка. Визуально с помощью него задается кривизна траектории полёта. Чем он больше, тем прыжок более острый, быстрый (меньше дуга). С помощью данной схемы можно делать: перепрыгивание со здания на здание, выпрыгивание из окна, перепрыгивание высоких ограждений и др. Дефолтное значение = 1,8
−	Примечание:	+	'''''Примечание''''': Ставить снайперу только 2 точки '''''look'''''.<br>
−	Фактически mob_jump - это не состояние, а разовое действие. При переходе в него монстр разворачивается в сторону прыжка и прыгает, поднимая сигнал jumped. Т.е. "on_signal = jumped | имя_схемы_или_nil" – является обязательным параметром в схеме, чтобы знать куда переходить дальше.	+
−	При выборе позиции используется первая точка патрульного пути (0-вой индекс)	+
−	==3.5.7. Mob_camp==	+	Файл: ''gamedata\scripts\xr_camper.script''
−	Механика:	+	==Схема follower==
−	1. Сидит на позиции, смотрит в точку	+	NPC идет за NPC-лидером. Если до лидера расстояние менее 5 метров, то он идет, если от 5 до 20 – бежит в режиме '''''run''''', если свыше 20 – догоняет в режиме '''''sprint'''''.<br>
−	2. Можно задать несколько позиций и время смены позиции.	+	<u>Пути не задаются</u>.<br>
−	3. Перемещается между позициями бегом	+
−	4. При виде врага переходит под универсальную схему (комбат/паника и т.д)	+
−	5. Задаются минимальная и максимальная дистанции от врага до текущей camp-позиции	+
−	6. Если враг уходит далеко - монстр возвращается на позицию	+
−	Использование:	+	'''[follower]'''<br>
		+	'''''leader = <number>''''' - '''''story_id''''' лидера из ''game.ltx'' (число!).<br>
		+	'''''formation_line = true/false''''' - постарается идти сбоку от лидера, в противном случае будет идти сзади.<br>
		+	'''''distance = <number>''''' - расстояние в метрах, на котором будет идти от лидера '''''attendant'''''. По умолчанию – 1,5 метра, если идет цепью, то 5 метров.<br>
		+	'''''state_if_leader_in_meet = <название_анимации>''''' - это есть строка с именем  состояния из '''''state_manager''''', которое будет назначено '''''follower'''''-ам, если командир пребывает в состоянии '''''meet'''''.<br>
		+	'''''anim_walk = <название_анимации>''''' - состояние, в котором фолловер идет за лидером.<br>
		+	'''''anim_run = <название_анимации>''''' - состояние, в котором фолловер бежит за лидером.<br>
		+	'''''anim_sprint = <название_анимации>''''' - состояние, в котором фолловер спринтует за лидером.<br>
−	[logic]
−	active = mob_camp
−	[mob_camp]	+	'''''Примечание''''': Не забыть прописать:
−	path_look = way_look	+	<ini>[smart_terrains]
−	path_home = way_home	+	none = true</ini>
−	time_change_point = 30000	+	:Иначе NPC засосёт в гулаг и никуда он не пойдёт.<br>
−	home_min_radius  = 20	+
−	home_max_radius = 50	+
−	skip_transfer_enemy – если прописать в кастом дату, то монстр не будет принимать врага от друших монстров, если его увидит (для этого нужно всех монстров в разные group разнести)	+
−	Описание параметров:	+	Если все это происходит под гулагом, то вместо '''''story_id''''' лидера, мы прописываем его секцию логики в файле скрипта.<br>
−	*path_home - путь, состоящий из точек, в которых будет находиться монстр	+	Пример:<lua>t = { section = "logic@bar_arena_follower_2",
−	path_look - путь, состоящий из точек, в которые будет смотреть монстр	+	idle    = 0,
−	*time_change_point - время изменения текущей camp-точки  (по-умолчанию10000), мс	+	prior   = 7,
−	* home_min_radius - минимальный радиус от врага до camp-точки (по-умолчанию 30), м	+	state  = {0},
−	* home_max_radius - максимальный радиус  от врага до camp-точки (по-умолчанию 40), м	+	squad  = squad,
		+	group  = groups[0],
		+	...
		+	}</lua>В данном случае для параметра '''''leader''''' необоходимо указать строку '''''bar_arena_follower_2'''''.<br>
−	Особенности:	+	'''''Примечание''''': в релизе игры данная схема не используется.<br>
−	Минимальный и максимальный радиус необходимы для игнорирования врага, если он убежал далеко и для возврата на текущую позицию. Учитывается дистанция от врага до текущей позиции. Если дистанция меньше home_min_radius - атакуем врага, пока враг не исчезнет или дистанция не будет больше home_max_radius.	+
−	Две дистанции необходимы для того, чтобы избежать ситуации, когда игрок стоит на границе радиуса действия и входит/выходит в зону и монстр бегает то в свою camp-позицию, то на врага.	+
−	Выбор текущей позиции производится случайным образом	+
−	Индексы точек пути для path_home и path_look должны совпадать (т.е. монстр сидит во второй точке path_home и смотрит во вторую точку path_look)	+
−	Единственным необходимым параметром является path_look	+	Файл: ''gamedata\scripts\xr_attendant.script''
−	Если не установлен path_home, в качестве кемперской точки учитывается позиция и нода объекта на спауне.	+
−	Для того чтобы монстр смотрел в разные точки на кемпер-позиции, path_look может состоять из нескольких точек.	+	==Схема zoneguard==
		+	У NPC есть две зоны (может быть одна). Он ходит по путям, но когда игрок заходит в зону, отрывает от дел, подбегает к игроку, наставляет на игрока оружие (может кричать, может говорить), если игрок заходит во вторую зону – атакует игрока.<br>
−	Обязательные требования:	+	'''[zoneguard]'''<br>
−	home_min_radius < home_max_radius	+	'''''path_walk = <имя_пути>''''' - путь перемещения.<br>
−	Количество точек путей path_look и path_home должно быть равным	+	'''''path_look = <имя_пути>''''' - путь обзора.<br>
−	P.S. Mob_Camp можно использовать как альтернативу к монстрам под рестрикторами	+	'''''team = <имя_команды>''''' - имя команды синхронизированных '''''zoneguard'''''-ов (из всей команды только 1 будет реагировать на игрока).<br>
		+	'''''zone_guard = <имя_зоны>''''' - зона в пределах которой игрок будет атакован.<br>
		+	'''''zone_warn = <имя_зоны>''''' - зона в пределах которой NPC будет начинать разговор с игроком.<br>
		+	'''''walker_team = <имя_команды>''''' -  для схемы перемещения его в состоянии '''''walker''''' (если не задан, используется значение из поля '''''team''''').<br>
		+	'''''no_move = true/false''''' - персонаж окликнет игрока с места и не будет подбегать к нему.<br>
		+	'''''snd_greet = <название_звуковой_темы>''''' - звук которой будет проигран при обнаружении игрока.<br>
		+	'''''ignore_friends = true/false''''' - будет игнорировать дружественных ему персонажей.<br>
		+	'''''ignore_cond = {+info -info =func !func ~number}''''' - условия, при которых NPC игнорирует игрока.<br>
		+	'''''no_danger = true/false''''' - отыгрывать или нет угрожающую анимацию будучи нейтралом.<br>
		+	'''''anim = <название_анимации>''''' - какую отыгрывает анимацию, если игрок ему не враждебен.<br>
		+	'''''snd_anim_sync = true/false''''' - будет ли синхронизирован звук с анимацией.<br>
−	==3.5.8. Mob_home==
−	Схема является ещё одним решением по замене рестрикторов. Рекомендую все следующие гулаги монстров делать на mob_home, а старые гулаги постепенно переводить на mob_home. У кого рестрикторы работают хорошо и красиво, их можно не трогать.
−	Пример:	+	'''''Пример использования схемы''''':<ini>[zoneguard]
−	[mob_home]	+	path_walk = mil_freedom_zoneguard_walk_kill2
−	path_home = path1	+	path_look = mil_freedom_zoneguard_look_kill2
−	home_min_radius = 10	+	zone_warn = mil_freedom_leader_warn_zone
−	home_max_radius = 30	+	zone_guard = mil_freedom_leader_kill_zone
−	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 =	+
−		+
−	==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_move = true
−	no_rotate = true	+	team = freedom_bodyguards3</ini>
−	on_hit = hit	+
−	on_death = death	+
−	combat_ignore_cond = {-alert}	+
−	[combat_ignore]	+	Файл: ''gamedata\scripts\xr_zoneguard.script''
−	Рассмотрим ее пошагово. Вначале сталкер работает по схеме walker-a. При этом он игнорирует бой, пока не будет поставлен инфопоршн alert. Он ждет 25 секунд, после чего переходит в схему remark. В ремарке он проигрывает идловую анимацию, говорит на указанные темы, не поворачивается и не двигается и точно также игнорирует бой. Если по нему попадут (on_hit) или убьют (on_death), будет поставлен инфопоршн alert и он перестанет игнорировать бой (понятно, что если он будет трупом, то это ему не поможет, но их в сценке трое, и тогда сорвутся в бой все остальные). Если его убьют, то также будет поставлен инфопоршн trup3 который сообщит о том, что этот сталкер убит.	+	==Схема wounded==
		+	Схема раненного. Определяет поведение NPC в состоянии "раненный".<br>
		+	'''''Примечание''''': не рекомендуется задавать схему в качестве активной.
−	А  вот логика его противника:	+	'''[wounded]'''<br>
−	[logic]	+	'''''hp_state = <HP>|<название_анимации>@<название_звуковой_темы>''''' - поведение NPC при значении уровня его здоровья равному '''''HP''''', когда он не видит игрока.<br>
−	active = walker	+	'''''hp_state_see = <HP>|<название_анимации>@<название_звуковой_темы>''''' - поведение NPC при значении уровня его здоровья равному '''''HP''''', когда он видит игрока.<br>
−	combat_ignore = combat_ignore	+	'''''psy_state = <PSY>|<название_анимации>@<название_звуковой_темы>''''' - поведение NPC при псиатаках, в зависимости от уровня пси-здоровья равному '''''PSY'''''.<br>
		+	'''''hp_victim = <HP>|<параметр>''''' - куда будет смотреть NPC при значении уровня его здоровья равному '''''HP''''', возможные параметры:<br>
		+	:*'''''story_id''''' - числовое значение;
		+	:*'''''actor''''' - без комментариев;
		+	:*'''''nil''''' - позиция вычисленная АИ автоматически.
		+	'''''hp_cover = <HP>|true/false''''' - идти в укрытие или нет, в зависимости от значения уровня здоровья равному '''''HP'''''.<br>
		+	'''''hp_fight = <HP>|true/false''''' - разрешено воевать или нет, в зависимости от значения уровня здоровья равному '''''HP'''''.<br>
		+	'''''syndata = <название_анимации>@<название_звуковой_темы>''''' - синхропары для красоты.<br>
		+	'''''help_dialog = <название_диалога>''''' - возможность установить диалог, вместо стандартного '''''actor_help_wounded'''''.<br>
		+	'''''help_start_dialog = <название_диалога>''''' - возможность установить стартовый диалог.<br>
−	[walker]
−	path_walk = soldier_walk1
−	path_look = soldier_look1
−	combat_ignore_cond = always
−	team = assault_group
−	on_signal = assault | camper
−	[camper]	+	'''''Примечание''''': желательно, чтобы все установленные актёрские диалоги для раненых имели условие их появления следующего вида:<br>
−	path_walk = soldier_walk1_2	+	:<xml><precondition>dialogs.allow_wounded_dialog</precondition></xml>
−	path_look = soldier_look1_2	+	'''''Примечание''''': если необходимо поставить несколько состояний, в зависимости от разного значения уровня здоровья, то сами состояния нужно разделять символом ‘|’:<br>
−	radius = 5	+	:<ini>hp_state= 30|help_me@help|10|wounded_heavy@help_heavy</ini>
−	on_info = {+trup1 +trup2 +trup3} walker2	+	:Здесь определятся два состояния при уровне здоровья 30 и 10 соответственно.
		+	:Для параметров '''''hp_state_see''''', '''''psy_state''''', '''''hp_victim''''', '''''hp_cover''''', '''''hp_fight''''' способ такой же.
−	[walker2]	+	'''''Пример использования схемы <small>(в качестве примера взята дефолтная настройка)'''''</small>:<br><ini>hp_state= 30|help_me@help|10|wounded_heavy@help_heavy
−	path_walk = soldier_walk1_3	+	hp_state_see = 30|wounded@help_see|10|wounded_heavy@help_heavy
−	path_look = soldier_look1_3	+	psy_state = 50|{=best_pistol}psy_armed,psy_pain@wounded_psy|20|psy_shoot,psy_pain@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 – проверка на то, что лучшее оружие NPC является пистолетом.</ini>
		+	Файл: ''gamedata\scripts\xr_wounded.script''
−	[combat_ignore]	+	==Схема rest==
		+	Чувак гуляет, хавает, спит.<br>
		+	Нормально не работает, посему в релизе не используется.<br>
−	Он идет в схеме walker, игнорируя бой (причем игнорируя в любой ситуации). Идет в составе группы assault_group. Когда он приходит в конечную точку маршрута (там он синхронизируется с остальными из группы, это приписано в путях) и получает сигнал assault, то переходит в схему camper. В этой схеме у него не прописан combat_ignore, поэтому он начинает стрелять по противнику. После того, как все трое противников будут убиты, каждый из них, умирая ставит инфопоршн trup1, trup2 или trup3 и когда все трое будут убиты, то он переключится на схему walker2 (подойдет к костру).	+	Файл: ''gamedata\scripts\xr_rest.script''
−	==3.9. Схемы логики space_restrictor==	+	==Схема heli_hunter==
		+	Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:<br>
		+	В активную схему вставляется параметр:<ini>heli_hunter = {+info -info =func !func ~number}true/false</ini>
−	Общее замечание: Чтобы исключить ситуацию, когда актёр проскакивает через рестриктор и тот не успевает сработать, старайтесь ставить рестриктор так, чтоб минимальная ширина была больше 2 метров.	+	Пример:<ini>[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 <br>%=bar_freedom_angry_actor%
		+	meet_talk_enabled = true
		+	meet_dialog = bar_svoboda_dialog
		+	heli_hunter = {-bar_ecolog_crush_heli_down} true</ini>
−	==3.9.1. Схема [sr_idle]==	+	Если раньше оверрайд понимал только значения '''''true''''' либо '''''false''''', то сейчас он понимает кондлист, который если возвращает '''''true''''' - то стрельба по вертолету в данной схеме разрешена.<br>
−	Предназначение данной схемы – включить другую схему при срабатывании одного из стандартных условий логической схемы.	+
−	Сама по себе схема ничего не делает.	+
−	Пример настроек рестриктора:	+
−	[logic]	+	==Схема patrol==
−	active = sr_idle	+	Итак, есть предварительная система патруля. Представляет собой вариацию '''''kamp''''' только в состоянии ходьбы. Для ее работы прописываем в '''''custom_data''''' следующее:<br>
−	[sr_idle]	+	'''[patrol]'''<br>
−	on_actor_inside = nil %+esc_actor_inside%	+	'''''path_walk = <имя_пути>''''' - путь по которому ходит NPC.<br>
		+	'''''path_look = <имя_пути>''''' - точки в которые смотрит NPC.<br>
		+	'''''formation = <параметр>''''' - описывет способ построения и не является обязательным. Возможны следующие варианты:<br>
		+	:*'''''back''''' - мужики идут чуть позади командира в два ряда (по умолчанию);<br>
		+	:*'''''line''''' - шеренга;<br>
		+	:*'''''around''''' - вокруг командира.<br>
		+	'''''commander = true/false''''' - будет ли NPC назначен командиром, желательно, чтобы такой красивый он был один. '''''false''''' - по умолчанию.<br>
		+	'''''move_type = <название_анимации>''''' - задает изначальный режим перемещения, по умолчанию '''''patrol'''''.<br>
−	Обратите внимание, что после срабатывания проверки активная схема переключается в nil, чтобы не продолжать бесполезную проверку на каждом апдейте. Можно не задавать nil.	+	При остановке командора в '''''meet''''' мужики останавливаются.<br>
−	Часто эта схема работает вместе со спавнером, рестриктор выдает инфопоршн, при входе в зону, а спавнер по нему уже кого-то спавнит.	+
−	файл \gamedata\scripts\sr_idle.script	+	Если командор помирает, то автоматически будет выбран другой. Командиром становится тот, кто первый попал под схему. Способы построения задаются в вейпоинтах следующим образом:<br>
		+	<ini>ret=0...2</ini>
		+	:*0 - линия;
		+	:*1 – вокруг старшего;
		+	:*2 – по бокам.
−	==3.9.2. Секция [sr_no_weapon]==	+	При движении командор работает как обычный '''''walker''''' и сопровождающие его кадры повторяют его действия. То есть, если в параметрах вейпоинта прописано '''''a=assault''''', то командор помчится с орудием убийства на перевес, а остальные его откопируют.<br>
−	Данная схема убирает оружие у игрока при входе в зону.	+
−	Пример настроек рестриктора:	+
−	[logic]
−	active = sr_no_weapon
−	[sr_no_weapon]	+	'''''Примечание''''': что еще не сделано или глючит:<br>
		+	:*нет возможности автоматически перестроить команду;
		+	:*все идут молча;
		+	:*командор пока не отдает команд;
		+	:*не рекомендуется включать спринт.
−	файл \gamedata\scripts\sr_no_weapon.script	+	'''''Пример использования схемы''''':<ini>[patrol@val_escort_captive_wait]
		+	path_walk          = captive_wait_walk
		+	path_look          = captive_wait_look
		+	commander          = true
		+	formation          = back</ini>
		+	Файл: ''gamedata\scripts\xr_patrol.script''
−	==3.9.3. Секция [sr_sound]==	+	==Схема meet==
		+	Схема позволяющая настроить ситуацию, когда НПС встречает актора.
−	snd = Перечень имён звуков разделенных запятыми.	+	'''[meet]'''<br>
		+	'''''meet_state/meet_state_wpn = <number>|<название_анимации>@<название_звуковой_темы>''''' – задает анимацию и озвучку персонажа,
		+	:в зависимости от расстояния до актера равному '''''number'''''. Для ситуации, когда актор безоружен и вооружён соответственно.<br>
		+	'''''victim/victim_wpn = <number>|<параметр>''''' - задает объект, на который должен будет смотреть персонаж, в зависимости от расстояния равное '''''number'''''.
		+	:Для ситуации, когда актор безоружен и вооружён соответственно. Возможны следующие значения:<br>
		+	::*'''''actor''''' - смотреть на игрока;<br>
		+	::*'''''story_id''''' - смотреть на персонажа со указанным '''''story_id''''';<br>
		+	::*'''''nil''''' - никуда.<br>
		+	'''''use/use_wpn = true/false/self''''' - настройки юзабельности персонажа.
		+	:При установки значения '''''self''''' NPC сам юзнет игрока, как только сможет дотянуться.<br>
		+	'''''zone = <имя_зоны>|<название_анимации>@<название_звуковой_темы>''''' - если актор будет замечен в указанном рестрикторе,
		+	:то NPC будет отыгрывать заданную анимацию и произносить заданный звук.<br>
		+	'''''meet_dialog = <название_диалога>''''' - возможность установить стартовый диалог NPC.<br>
		+	'''''synpairs = <название_анимации>@<название_звуковой_темы>''''' - Если при каком-то наборе условий
		+	:встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.<br>
		+	'''''abuse = true/false''''' - по умолчанию '''''true''''', если '''''false''''', то неюзающийся противник не будет обижаться.<br>
		+	'''''precond = usability/visibility'''''.<br>
−	type = Типы звуков через запятые. Для удобства введены типы наборов звуков. Т.е., например, чтобы не перечислять каждый раз весь набор звуков скрипа деревянного пола, можно указать тип floor_wooden.	+	Любую строку можно задавать кондлистом ('''''{+info -info =func !func ~number}''''').<br>
−	*delay = Задержка перед проигрыванием звука в секундах реального времени, по умолчанию 0.	+	Для облегчения настройки встречи сделана возможность упрощенного  задания дефолта:<br><ini>[walker]
		+	meet = default_meet</ini>Саму секцию '''''default_meet''''' задавать не надо. Все настройки и так возьмутся из дефолта. По дефолту встреча настроена со следующими параметрами:<br>
		+	<ini>[default_meet]
		+	meet_state = 30|hello@hail|20|wait@wait
		+	meet_state_wpn = 30|backoff@threat_weap
		+	victim = 30|actor
		+	victim_wpn = 30|actor
		+	use = true
		+	use_wpn = false
		+	syndata = hello@hail|backoff@threat_weap</ini>
−	*idle =  Длина периода игнорирования входа в зону после начала последнего проигранного звука. Чтоб, например, завывание было не чаще, чем раз в несколько минут. В секундах игрового времени. По умолчанию 0.	+	'''''Примечание''''': если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему '''''meet = no_meet'''''.<br>
−	*rnd = Вероятность (в процентах) того, что звук отыграется. По умолчанию 100.
−	*position = Задает имя пути, в вершинах которого может отыграться звук. Есть зарезервированное значение random. Оно означает случайное место в радиусе 15…50 метров от игрока. Если этот параметр не задан, то подразумевается позиция игрока.	+	Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна.<br>
−	*slide_velocity = Скорость (м/с) передвижения звука по точкам патрульного пути. По умолчанию - 3	+	*'''Ситуация 1'''.<br>
		+	Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.<br><ini>[meet]
		+	meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait
		+	meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap
		+	victim = 50| actor
		+	victim_wpn = 50| actor
		+	use = true<
		+	use_wpn = false</ini>
−	*slide_sound_once = true\false	+	*'''Ситуация 2'''.<br>
−	true - проиграть звук один раз, даже если он не дошел до последней точки пути.	+	Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.<br><ini>[meet]
−	false – если звук закончился, а до последней точки пути не дошел, запустить его ещё раз. По умолчанию false.	+	meet_state = 50|{+info} threat_fire %=killactor% ,walk@ {+info} talk_abuse, wait|10|walk %+info%
		+	meet_state_wpn = 50|{+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait
		+	victim = 50|actor
		+	victim_wpn = 50|actor
		+	use = {-info2} self, false
		+	use_wpn = false</ini>Здесь:<br>
		+	'''''info''''' – инфопорция, которая указывает что мы уже опустили оружие и были достаточно близко к NPC;<br>
		+	'''''info2''''' – инфопорция, которая устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел;<br>
		+	'''''killactor''''' – функция в ''xr_effects.script'' которая обижает NPC на игрока.<br>
−	*play_at_actor = true/false Заставляет звук играться от позиции актера постоянно. Если он будет	+	*'''Ситуация 3'''.<br>
−	равен true и будет задан путь перемещения звука (или рандом), то мы тупо вылетим.	+	Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.<br><ini>[camper]
−		+
−	Предназначение данной схемы: отыграть звук при входе актёра в рестриктор.	+
−		+
−	Поддерживается 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==	+
−		+
−	Данная система отыгрывает партиклы как статичные так и движущиеся в указанном месте и в указанное время. Работет она следующим образом:	+
−		+
−	1) для партикловой системы с путем камеры:	+
−	[sr_particle]	+
−	name = explosions\campfire_03          -имя партикловой системы	+
−	path = particle_test.anm          -имя пути камеры	+
−	mode = 1 (обязательно !!!)	+
−	looped = true/false              -флаг зацикленности партиклов	+
−		+
−	(обязательно с расширением ANM !!!) Здесь партиклы будут молча перемещаться по пути.	+
−		+
−	2) для партикловой системы с обычным патрульным путем:	+
−	[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==	+
−	Итого, схема, которая играет саунд в голове актера. Всякие там переговоры по ПДА и прочие фейки	+
−		+
−	[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 = <condlist>	+
−	*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 = <condlist> - условия срабатывания	+
−	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	+
−		+
−	Для того чтобы сообщение не потеряло адекватность при различных настройках клавиатуры сообщение следует писать с использованием токенов. Например:	+
−		+
−	<string id="tips_labx16switcher_press">	+
−	<text>Чтобы отключить чудо установку нажмите ($$ACTION_USE$$)</text>	+
−	</string>	+
−		+
−		+
−	Вот пример кнопки, которая срабатывает не всегда, а по определенному условию:	+
−		+
−	[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%	+
−		+
−		+
−	==3.10.3. Схема работы прожектора:==	+
−		+
−	В точках look пути, в которые смотрит прожекторщик, нужно прописать	+
−	sl=имя_прожектора	+
−		+
−	Например	+
−	wp00|sl=esc_sl1	+
−		+
−	Тогда при повороте в эту точку персонаж повернет в нее и прожектор.	+
−		+
−	==3.10.4. Кодовые замки:==	+
−		+
−	При введении указанного кода выдает инфопоршн	+
−		+
−	[logic]	+
−	active = ph_code@lock	+
−		+
−	[ph_code@lock]	+
−	code = 1243	+
−	on_code = %+infoportion%	+
−		+
−	Файл: \gamedata\scripts\ph_code.script	+
−		+
−		+
−	==3.10.5. Ph_gate:==	+
−		+
−	То же самое, что и ph_door, но для ворот, состоящих из двух дверей:	+
−	Вместо параметров closed и locked сейчас используются параметры:	+
−	state: состояние, в котором дверь находится при инициализации (по умолчанию none)	+
−	open - в открытом	+
−	closed - в закрытом	+
−	none - в текущем (дефолтном или оставшемся от предыдущей схемы)	+
−		+
−	locking: блокировка дверей (по умолчанию none)	+
−	stick - прилипание дверей к крайним состояниям (пока в процессе настройки)	+
−		+
−	soft - дверь заблокирована с помощью силы, т.е. можно ее открыть/пробить машиной	+
−	Состояния в этом положении:	+
−	open - блокировать в открытом состоянии	+
−	closed - в закрытом	+
−	none - не используется (мягкая блокировка возможна только в крайних положениях)	+
−		+
−	hard - блокировка двери с помощью границ. Ворота можно только сломать	+
−	Состояния в этом положении:	+
−	open - блокировать в открытом состоянии	+
−	closed - в закрытом	+
−	none - в текущем	+
−		+
−	none - дверь не заблокирована	+
−		+
−	Общие параметры:	+
−	left_limit, right_limit - задают угол [0-180] открытия каждой из створок ворот. По умолчанию - 100 градусов.	+
−	breakable - (true/false) определяет можно ли сломать ворота. По умолчанию true.	+
−		+
−	Звуковые параметры аналогичны ph_door	+
−		+
−	Примеры:	+
−	[ph_gate@locked] ;блокировка в открытом состоянии, неразбиваемые.	+
−	state = opened	+
−	locking = soft	+
−	left_limit = 130	+
−	rigt_limit = 60	+
−	breakable = false	+
−		+
−	[ph_gate@opened]	+
−	state = opened	+
−	locking = stick	+
−		+
−	[ph_gate@closed]	+
−	state = closeded	+
−		+
−	Файл: \gamedata\scripts\ph_gate.script	+
−		+
−	==3.10.6. Ph_sound==	+
−		+
−	Прописывается у физического объекта какие звуки он выдает (изначально планировался как матюгальник).	+
−		+
−	[ph_sound]	+
−	snd = имя темы из файла sound_theme.script из таблицы ph_snd_themes	+
−	*looped = true/false зацикленое воспроизведение звука (default - false)	+
−	*min_idle = минимальное время простоя перед включением звука (мс)	+
−	*max_idle = максимальное время простоя перед включением звука (мс)	+
−	*random = true/false (def - false). Если = true, то из темы будет выбран рандомный звук и таким образом звуки будут играться до посинения	+
−		+
−	NB! Если мы задаем random = true и looped = true, то версия сыпется	+
−		+
−	Также поддерждивается кондлист.	+
−	Данная схема работает через задницу, поэтому зацикленный звук будет продолжать отыгрываться, даже если объект уходит в nil. В связи с этим надо создавать новую секцию, которая бы отыгрывала одиночный короткий звук, после которого (поскольку он будет точно также играться раз за разом) ставим on_signal = sound_end| nil	+
−		+
−	Пример подобной извращенной логики:	+
−	[logic]	+
−	active = ph_sound	+
−		+
−	[ph_sound]	+
−	snd = gar_seryi_shooting	+
−	looped = true	+
−	max_idle = 5000	+
−	on_actor_in_zone = gar_seryi_factory| ph_sound@end	+
−		+
−	[ph_sound@end]	+
−	snd = gar_seryi_shooting_2	+
−	looped = false	+
−	on_signal = sound_end| nil	+
−		+
−		+
−	Кроме того специфическим образом создается звуковая схема.	+
−	В sound_theme.script  в начале файла есть секция ph_themes в которой и описываются темы для физ объектов.	+
−	Например:	+
−	ph_snd_themes["gar_seryi_shooting"] = {[[characters_voice\human_01\scenario\garbage\distance_shooting]]}	+
−		+
−	Кроме того (незадекларированная фича) ph_sound можно вешать на рестрикторы. Но за правильность работы в таком случае никто ответственности не несет.	+
−		+
−	Файл: \gamedata\scripts\ph_sound.script	+
−		+
−	==3.10.7. Ph_force==	+
−		+
−	Схема позволяет пнуть предмет в указанную сторону. Прописывается в кастом дате предмета.	+
−		+
−	force = сила, которая прикладывается к объекту. Измеряется в убитых енотах	+
−	time = время прикладывания силы к предмету (в секундах)	+
−	*delay = задержка (в секундах) перед применением силы	+
−	point =  имя патрульного пути, точки которого будут использованы как цели (куда направлять предмет)	+
−	point_index = индекс точки патрульного пути, в стону которого полетит предмет.	+
−		+
−	==3.10.8. Ph_on_death==	+
−		+
−	Схема для отслеживания разрушения физического объекта и выдавания по такому случаю различных эффектов	+
−	Пример:	+
−		+
−	[logic]	+
−	active = ph_on_death	+
−		+
−	[ph_on_death]	+
−	on_info = %эффекты%	+
−		+
−	Юзать исключительно с разрушаемыми физ. Объектами	+
−		+
−	==3.10.9. Ph_car==	+
−		+
−	Настройка возможности игроку управлять машиной.	+
−	секция: [ph_car]	+
−	поле:  usable = <condlist>	+
−		+
−	usable - кондлист возвращающий true (по умолчанию) или false.	+
−		+
−	Пример:	+
−	[logic]	+
−	active = ph_car	+
−		+
−	[ph_car]	+
−	usable = {+val_actor_has_car_key}	+
−		+
−	На основе этой схемы можно сделать машину, которая зведется только если у актера есть ключ именно от нее.	+
−		+
−	==3.10.10. Ph_heavy==	+
−	Прописывается в физ объектах, которые запрещены для швыряния бюрерам и полтергейстам. Например, если они должны лежать на конкретном месте (типа документов сюжетных) или слишком громоздки по габаритам, чтобы их можно было красиво кидать.	+
−	В кастом дате пишем:	+
−		+
−	[ph_heavy]	+
−		+
−		+
−	==3.10.11. Ph_oscillate==	+
−	Схема предназначена для плавного раскачивания физики (лампы, висящие зомби и т.д.)	+
−	Пример логики	+
−		+
−	[ph_oscillate]	+
−	joint = provod  - имя кости к которой будет применена сила	+
−	force = 5        - собственно сила (в ньютонах)	+
−	period = 1000    - время прикладывания силы.	+
−		+
−	Сила прикладывается к кости объекта с линейным наростанием. То есть в течении заданого периода времени сила вырастет с 0 до заявленого значения. После этого настает пауза (сила не применяется) на время period/2. После окончания паузы сила применяется так же, как и в начале, но в обратном направлении.	+
−		+
−	==3.11. Смарттерейны и гулаги.==	+
−	==3.11.1. Смарттеррейн.==	+
−	Под смарттеррейном мы понимаем зону, зайдя в которую, сталкер на некоторое время попадает под гулаг и начинает выполнять работу, предусмотренную этим гулагом. После некоторого времени он выходит из-под гулага и ходит свободно.	+
−		+
−	Как поставить smart terrain?	+
−	Для всех smart terrain нужно:	+
−	1) Поставить smart terrain с необходимым shape. Большой shape не рекомендуется (размер влияет на производительность).	+
−	2) В его custom data прописать настройки.	+
−	3) Расставить пути для соответствующих схем поведения.	+
−		+
−	Параметры custom data:	+
−	[gulag1]	+
−	type = тип гулага	+
−	capacity = макс. вместимость в людях	+
−	*offline = может ли гулаг образоваться в offline (true(по дефолту)/false)	+
−	*squad = squad, который будет проставлен всем сталкерам под гулагом (№ уровня)	+
−	*groups = набор group через запятые	+
−	*stay = min, max время пребывания npc под smart_terrain (по умлочанию – навсегда)	+
−	*idle = min, max время бездействия smart_terrain после ухода последнего npc	+
−	*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.	+
−		+
−	Указывать тип гулага нужно без кавычек.	+
−	Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.	+
−	Все времена задаются в часах игрового времени и могут быть дробными.	+
−		+
−	Пути:	+
−	Имена путей для схем поведения всегда должны начинаться с имени данного smart terrain. Например, esc_smart_ambush_vagon_sleep.	+
−		+
−	Если пути для smart terrain на нескольких человек (campers, walkers), то их имена должны заканчиваться всегда на цифру (esc_smart_ambush_vagon_walk1, esc_smart_ambush_vagon_walk2)	+
−		+
−	Гулагов под одним smart terrain может быть несколько. Их можно настраивать в секциях [gulag2], [gulag3] и т.д. При входе сталкера под smart terrain будет случайно выбран один из доступных на данный момент гулагов.	+
−		+
−	==3.11.1.1. Стандартные типы смарттеррейнов.==	+
−		+
−	Если нужно, чтоб сталкер не захватывался, допишите ему в custom data следующую строку:	+
−	[smart_terrains]	+
−	none = true	+
−		+
−	Если сталкер уже под каким-то smart terrain, то остальные smart terrain он будет игнорировать.	+
−		+
−		+
−	campers	+
−	Кемперы. custom data:	+
−	[gulag1]	+
−	type = campers	+
−	capacity = от 1 до 3	+
−		+
−	Пути:	+
−	camper_walk1, camper_look1	+
−	camper_walk2, camper_look2	+
−	camper_walk3, camper_look3	+
−		+
−		+
−	walkers	+
−	Ходячие. На базе этого можна сделать поиск, обыск и куча всего.	+
−	custom data:	+
−	[gulag1]	+
−	type = walkers	+
−	capacity = от 1 до 3	+
−		+
−	Пути:	+
−	walker_walk1, walker_look1	+
−	walker_walk2, walker_look2	+
−	walker_walk3, walker_look3	+
−		+
−		+
−	search	+
−	Ходячие. На базе этого можна сделать поиск, обыск и куча всего.	+
−	custom data:	+
−	[gulag1]	+
−	type = search	+
−	capacity = 1	+
−		+
−	Пути:	+
−	search_walk, search_look	+
−		+
−	Схема следующая:	+
−	1. Персонаж ходит по точкам, смотрит по сторонам	+
−	2. В определенных точках останавливается и что-то высматривает (caution, search, hide)	+
−	3. При этом говорит определенные реплики (…)	+
−		+
−	rest	+
−	Отдых. Сталкер по очереди то sleeper, то walker, то rest(ест еду, пьёт водку).	+
−	custom data:	+
−	[gulag1]	+
−	type = rest	+
−	capacity = 1	+
−		+
−	Пути:	+
−	rest – путь из двух вершинок (возможно из 1). В одной сидит, в другую смотрит.	+
−	sleep - путь из двух вершинок (возможно из 1). В одной спит, в другую смотрит.	+
−	rest_walk, rest_look	+
−		+
−	3.11.2. Гулаги.	+
−	Гулаг - средство объединения нескольких сталкеров под централизованным управлением. Основные особенности:	+
−	А) Есть список работ гулага. Работа - настроенная схема поведения (или цепочка схем поведения);	+
−	Б) Работы имеют приоритеты;	+
−	В) Гулаг назначает на работы сталкеров входящих в гулаг, начиная с работ с наивысшим приоритетом;	+
−	Г) Гулаг имеет состояния. Каждое состояние характеризуется своим набором работ, отличным от набора работ в любом другом состоянии гулага.	+
−		+
−		+
−		+
−	Гулаг создается следующим образом:	+
−		+
−	1. Необходимо четко определить набор состояний гулага: день, ночь, спокойное, при тревоге и так далее. Для простых гулагов достаточно одного состояния, для крутых и сложных – желательно разные. Это придает разнообразия и смотрится лучше.	+
−		+
−	2. Определяем  максимальное количество людей, которым гулаг может управлять. То есть определяем вместимость гулага. Она должна быть такой, чтобы в любом состоянии гулага гарантированно нашлось занятие для каждого человека.	+
−		+
−	3. Для каждого состояния гулага определяется набор работ. Эти работы могут быть как активного плана (часовой, патруль, и так далее), так и пассивного плана (сидят вокруг костра, спят). Каждая работа имеет свой приоритет. Соответственно пассивные работы должны иметь меньший приоритет.	+
−		+
−	4. Ставится в редакторе количество людей, которые должны быть под гулагом, и накрываются зонкой smart_terrain (источник ошибок – иногда ставят space_restictor). Зонке нужно давать осмысленное название. Это же название будет являться префиксом к названием всех патрульных путей, относящихся к этому же гулагу. Например если вы назвали зонку esc_blockpost, то все патрульные пути должны начинаться с этого префикса, например esc_blockpost_guard_walk. В custom_data зоны необходимо прописать настройку гулага.	+
−	[gulag1]	+
−	type = тип гулага	+
−	capacity = макс. вместимость в людях	+
−	*offline = может ли гулаг образоваться в offline (true/false)	+
−	*squad = squad, который будет проставлен всем сталкерам под гулагом	+
−	*groups = набор group через запятые	+
−	*stay = min, max время пребывания npc под smart_terrain	+
−	*idle = min, max время бездействия smart_terrain после ухода последнего npc	+
−	*cond = список условий, которые необходимы для создания гулага {+info –info =func !func} – если условие не выполняется, то гулаг распускается, а все его подопечные начинают управляться прописанной в custom_data логикой.	+
−	*respawn = имя респауна (вызывает респаунер с заданым именем каждый раз, когда кто-то из самрттеррейна заступает на работу)	+
−		+
−	Capacity нужно задавать всегда. Она может быть равна или меньше числа работ.	+
−	Указывать тип гулага нужно без кавычек.	+
−	Полем offline можно задать, чтоб гулаг не образовывался в офлайн. Т.е. существовать в офлайн он может, а образовываться – нет.	+
−	Если не задан squad или groups, то соответствующие свойства сталкеров не будут изменяться.	+
−	Все времена задаются в часах игрового времени и могут быть дробными.	+
−		+
−	5. В скрипте \gamedata\scripts\gulag_название_уровня.script необходимо прописать условия, при которых сталкеры берутся под конкретный гулаг. В функцию checkNPC необходимо прописать условие:	+
−	if gulag_type == "gar_dolg" then	+
−	return npc_community == "dolg"	+
−	end	+
−		+
−	В эту функцию пока передается два параметра, тип гулага и комьюнити персонажа. В данном случае под гулаг с типом gar_dolg будут приниматься все персонажи, относящиеся к группировке Долг.	+
−		+
−	6. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать переключение состояний гулага.	+
−		+
−	function loadStates(gname, type)	+
−	в нее передается имя зонки и тип гулага. Состояние гулага описывается в виде функции, возвращающей номер состояния гулага. Например:	+
−	if type == "gar_maniac" then	+
−	return function(gulag)	+
−	if level.get_time_hours() >= 7 and level.get_time_hours() <= 22 then	+
−	return 0  -- день	+
−	else	+
−	return 1  -- ночь	+
−	end	+
−	end	+
−	end	+
−	В данном случае если сейчас между 7 и 22 часов, то гулаг находится в дневном состоянии, иначе в ночном.	+
−		+
−	8. В файле \gamedata\scripts\gulag_название_уровня.script необходимо описать должности гулага. В функции loadJob загружаются все допустимые работы. В саму функцию передаются следующие параметры:	+
−	function loadJob(sj, gname, type, squad, groups)	+
−	sj – сама табличка работ гулагов,	+
−	gname – имя нашей зонки смар-тиррейна. Оно используется как префикс.	+
−	Type – тип гулага	+
−	Squad, groups – таблички сквадов и групп, если нам нужно переопределять родные группы сталкеров на какие либо другие. В каждой работе можно указать какой сквад и группа сетится сталкеру при установке на работу.	+
−		+
−	Примерное описание работ гулага:	+
−	Данный гулаг описывает поведение только одного человека, обычно их гораздо больше. Данный человек в нулевом состоянии(день) делает одну работу, в первом состоянии(ночь) делает другую работу.	+
−		+
−	--' Garbage maniac	+
−	if type == "gar_maniac" then	+
−	t = { section = "logic@gar_maniac_camper",	+
−	idle = 0,	+
−	prior = 5, state = {0},	+
−	squad = squad, groups = groups[1],	+
−	in_rest = "", out_rest = "",	+
−	info_rest =  “”	+
−	}	+
−	table.insert(sj, t)	+
−	t = { section = "logic@gar_maniac_sleeper",	+
−	idle = 0,	+
−	prior = 5, state = {1},	+
−	squad = squad, groups = groups[1],	+
−	in_rest = "", out_rest = "",	+
−	info_rest =  “”	+
−	}	+
−	table.insert(sj, t)	+
−	end	+
−		+
−	Описание полей:	+
−	Idle – пауза между повторным выполнениями одного и того же задания. В данном случае паузы нет. Обычно пауза ставится на патруль.	+
−	Prior – приоритет задания. Сперва сталкеры занимают более приоритетные задания. Чем больше число, тем выше приоритет.	+
−	In_rest, out_rest  -  рестрикторы, которые устанавливаются персонажу на данное задание.	+
−	Section – секция в \gamedata\config\misc\gulag_название_уровня.ltx,  где указываются реальные настройки схемы поведения, которая соответствует текущей работе.	+
−	Group сталкера будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1.	+
−	Info_rest – задает ся имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, находящегося на этой работе	+
−	Также в описании работы может быть указаны дополнительные условия, при которых сталкер может занять данную работу. Например:	+
−		+
−	predicate = function(obj)	+
−	return obj:profile_name() == "soldier_commander”	+
−	end	+
−	то есть данную работу сможет выполнять лишь персонаж с профилем soldier_commander.	+
−		+
−		+
−	9. В \gamedata\config\misc\gulag_название_уровня.ltx необходимо указать, какие схемы поведения соответсвуют той или иной работе. Например в случае с вышерассмотренным гулагом gar_maniac:	+
−		+
−	;----------------------------	+
−	;-- GARBAGE MANIAC	+
−	;----------------------------	+
−	[logic@gar_maniac_camper]	+
−	active = camper@gar_maniac_camper	+
−		+
−	[camper@gar_maniac_camper]	+
−	path_walk = walk1	+
−	path_look = look1	+
−		+
−		+
−	[logic@gar_maniac_sleeper]	+
−	active = sleeper@gar_maniac_sleeper	+
−		+
−	[sleeper@gar_maniac_sleeper]	+
−	path_main = sleep	+
−	wakeable = true	+
−		+
−	Настройка здесь соответствует настроке в обычной кастом дате сталкера, с разницей:	+
−	1) пути следует указывать без префикса. То есть если зонка носила название gar_maniac, то пути следует на уровне ставить с названием gar_maniac_walk1, однако в gamedata\config\misc\gulag_название_уровня.ltx следует указывать только walk1.	+
−	2) в именах секций схем поведения после @ добавлять название гулага и, возможно, дополнительные сведения (например, walker2@rad_antena_gate)	+
−	3) в именах секций logic для каждой работы добавлять после @ имя гулага, дополнительные сведения и имя секции активной схемы поведения (например, logic@rad_antena_gate_walker2).	+
−		+
−	В работах для гулагов поля leader больше нет. Есть поле dependent. Работа может быть занята только тогда, когда работа с именем dependent уже занята. Например, follower может быть назначен только тогода, когда уже кто-то назначен на работу лидера (имя работы лидера теперь в поле dependent). Естественно, что приоритет работ, от которых зависят другие, должен быть больше чем у них.	+
−		+
−	==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(название гулага) = {кондлист} - если только в 1 смарттеррейн сталкер сможет прийти, то пишем true.	+
−	Если этот товарищ не должен работать под смарттеррейнами, то пишем ему в кастом дату.	+
−	[smart_terrains]	+
−	none = true	+
−		+
−		+
−	3.12. Логика вертолёта	+
−	Общие сведения:	+
−		+
−	Вертолёт работает на «логике».	+
−	На вертолёт реагируют аномалии.	+
−	Вертолёт не обрабатывает столкновения с геометрией и физикой пока он не сбит.	+
−	Попадания в область кабины, где сидит первый пилот, в десятки раз более болезненны для вертолёта.	+
−	У вертолёта есть универсальная боевая схема на манер сталкеров.	+
−	Пилоты вертолета реагируют репликами на события: хит, видит врага, поврежден (задымился), падает.	+
−		+
−	==3.12.1. Схема heli_move:==	+
−	Общие сведения:	+
−	Позволяет летать вертолёту по патрульному пути, регулировать скорость, зависать, стрелять по различным целям.	+
−		+
−	Для схемы должен быть задан path_move – путь, по которому будет летать вертолёт. Он может содержать одну вершину, если нужно, чтоб вертолёт висел на месте.	+
−		+
−	Можно (но не обязательно) задать path_look – путь, в вершины которого вертолет может смотреть.	+
−		+
−	Вершины этих путей могут быть поставлены где угодно в пределах ограничивающего бокса уровня. Они не зависят от ai-nodes.	+
−		+
−	По пути вертолёт летает без учёта связей между вершинами. Он летает от вершины к вершине в порядке возрастания их номера (т.е. в порядке, в котором их поставили на уровень).	+
−		+
−	Вертолёт старается летать точно по вершинам пути. При желании можно сделать ювелирный пролёт под мостом.	+
−		+
−	Вертолёт старается летать как можно быстрее. Пояснение: если ему задать, что в следующей вершине пути он должен иметь скорость 10 м/с, а его максимальная скорость установлена в 30 м/с, то он не станет сразу лететь 10 м/с. Он сначала будет разгоняться вплоть до 30 м/с и только на подлёте к целевой вершине начнёт тормозить с расчётом прибыть в неё имея 10 м/с.	+
−		+
−	Если в вершине пути path_move задан набор флажков, то вертолёт будет смотреть в любую из вершин path_look, в которых задан такой же набор флажков. Поворачиваться к этой точке вертолёт начнёт с предыдущей вершины пути. На данном этапе вертолет не может, зависнув в одном месте, смотреть поочередно в несколько точек path_look	+
−		+
−	Настройки:	+
−		+
−	*engine_sound = true/false (по умолчанию true)	+
−	Вкл/выкл звук двигателя вертолёта.	+
−		+
−	*invulnerable = true/false (по умолчанию false)	+
−	Неуязвимость. Если true, вертолёт игнорирует все хиты.	+
−		+
−	*immortal = true/false (по умолчанию false)	+
−	Бессмертие. Если true, вертолёт получает повреждения, но не умирает.	+
−		+
−	*mute = true/false (по умолчанию false)	+
−	Отключает универсальные реплики пилотов вертолета.	+
−		+
−	*rocket_delay = msec (время в миллисекундах реального времени)	+
−	Задержака между пусками ракет. По дефолту берется из ltx (сейчас 1250 мсек)	+
−		+
−	*default_velocity = m/sec (скорость с которой летает вертолет, если не заданы другие параметры)	+
−		+
−	Параметры, задаваемые в именах вершин пути path_move:	+
−		+
−	«e» – (сокр. от enemy) задание врага (цели). Стрелять по этой цели вертолёт начнёт уже в предыдущей вершине. Если значение не задано, то будет стрелять в точку из path_look, которая соответствует данной вершине. Если задано «e=actor» (можно сокращённо «e=a»), то огонь будет вестись по актёру. Если задано «e=число», стрелять будет по объекту со story id равным числу.	+
−		+
−	«w» – (сокр. от weapon) каким оружием стрелять. Возможные значения: w=1 – стрелять только пулемётом; w=2 – стрелять только ракетами. По умолчанию стреляет из всего.	+
−		+
−	«v» - (сокр. от velocity) задание максимальной скорости (в м/с) на участке пути от данной вершины до следующей. Если этот параметр не задан, то умолчание берётся из файла helicopter.ltx.	+
−		+
−	«dv» - (сокр. от destination velocity) задание скорости (в м/с), которую вертолёт должен иметь в момент прибытия в данную вершину.	+
−		+
−	«die» - убить вертолёт.	+
−		+
−	«flame» - начать дымить (как будто подбили).	+
−		+
−	Параметры, задаваемые в именах вершин пути path_look:	+
−		+
−	«e» - работает так же как и в path_move. Разница в том, что стрелять по указанной цели вертолёт начнёт лишь тогда, когда прибудет в вершину пути path_move, которая соответствует данной вершине path_look.	+
−		+
−	«w» – см. такой же параметр для пути path_move.	+
−		+
−	«t» - (сокр. от time) длительность времени (в мс реального времени), на протяжении которого вертолёт будет смотреть в данную точку. Если этот параметр не задан, то вертолёт пронесётся без остановки, но постарается на ходу развернуться к этой вершине.	+
−		+
−	==3.12.2. Универсальная боевая схема:==	+
−	Общие сведения:	+
−		+
−	В универсальной боевой схеме вертолёт не привязан к путям.	+
−		+
−	Вертолёт не видит никого. Узнать о враге вертолёт может только при получении хита или из параметра в custom data.	+
−		+
−	Вертолёт стреляет по врагу, если видит его. Если не видит – ищет, облетая вокруг точки, где последний раз видел. Если долго не видит врага – забывает его. Если врага задали принудительно из текущей секции схемы поведения, то он не забудет его, пока находится в этой секции.	+
−		+
−	Настройки:	+
−		+
−	Отдельной секции для этой схемы поведения нет. Поэтому настройки производятся в секции текущей схемы поведения:	+
−		+
−	combat_ignore = true/false	+
−	true означает игнорирование получения хита. Т.е. вертолёт не будет пытаться «отомстить» тому, от кого он получил хит.	+
−		+
−	combat_enemy = nil/actor/StoryID	+
−	С помощью этого параметра можно задать вертолёту конкретного врага. nil – нету врага; actor – игрок; SID – числовое story id врага.	+
−		+
−	combat_use_rocket = true/false	+
−	Можно ли вертолёту пользоваться рокетами.	+
−		+
−	combat_use_mgun = true/false	+
−	Можно ли вертолёту пользоваться пулемётом.	+
−		+
−	combat_velocity = <число>	+
−	Скорсть, с которой вертолет будет делать боевые заходы	+
−		+
−	combat_safe_altitude = <число>	+
−	Высота, относительно самой высокой точки геометрии на уровне ниже которой вертолет не будет опускаться в боевой схеме (может быть отрицательным)	+
−		+
−	К вертолёту подключена схема xr_hit. Работает как у сталкеров. В xr_effects есть группа функций для работы с вертолётом из его custom data:	+
−		+
−	heli_set_enemy_actor - сделать актёра врагом вертолёту	+
−	heli_start_flame - поджечь вертолёт	+
−	heli_die - убить вертолёт	+
−		+
−	combat_velocity = - боевая скорость в этой секции указывается в м/с	+
−	combat_safe_altitude = - высота боевая в метрах, может принимать отрицательные значения	+
−	combat_use_rocket = - true/false использовать ли ракеты в этой секции	+
−	combat_use_mgun = - true/false использовать ли пулемет в этой секции	+
−		+
−	3.13. Meet_manager	+
−		+
−	Синтаксис:	+
−		+
−	[logic]	+
−	meet = meet	+
−		+
−	[walker]	+
−	meet = meet	+
−		+
−	[meet]	+
−	meet_state = 30| state@sound| 20| state@sound| 10| state@sound	+
−	meet_state_wpn = 30| state@sound| 20| state@sound| 10| state@sound	+
−	victim = 30| nil| 20| actor	+
−	victim_wpn = 30| nil| 20| actor	+
−	use = self	+
−	use_wpn = false	+
−	zone = name| state@sound	+
−	meet_dialog = dialog_id	+
−	synpairs = state@sound|state@sound	+
−	abuse = true/false	+
−		+
−		+
−	Вся настройка встречи отныне будет производится в отдельной секции. В секции logic или в текущей схеме можно будет указать, какую именно секцию с настройкой нужно использовать. Секция, которая указана в секции logic будет влиять на обработку встречи свободногулящим сталкером.	+
−		+
−	Перечень полей:	+
−	meet_state, meet_state_wpn – задает анимацию и озвучку персонажа, в зависимости от расстояния до актера. Для случая если актер безоружен либо вооружен соответственно.	+
−	victim, victim_wpn – задает объект, на который должен будет смотреть персонаж. Возможные параметры: nil – никуда не смотрит, actor – смотрит на игрока, story_id – номер стори айди персонажа, на которого нужно будет смотреть.	+
−	use, use_wpn – настройки юзабельности персонажа. Возможны три варианта: true, false, self. При self НПС сам юзнет игрока, как только сможет дотянуться 	+
−	zone – Содержит набор имен рестрикторов, а также анимаций и озвучки, которую НПС будет отыгрывать, если игрок будет замечен в рестрикторе	+
−	meet_dialog – стартовый диалог НПС.	+
−	synpairs – cодержит набор пар состояние_тела@звуковая_тема. Если при каком то наборе условий встреча будет отыгрывать именно это состояние и эту звуковую тему – то они будут синхронизироваться по рандомным анимациям состояния тела.	+
−	аbuse – по умолчанию true, если false, то неюзающийся противник не будет обижаться.	+
−	Любую строку(в общей схеме они написаны строчными буквами) можно задавать кондлистом. ( {+info1 –info2} ward %+info%  )	+
−		+
−	Для облегчения настройки встречи сделана возможность упрощенного  задания дефолта:	+
−		+
−	[walker]	+
−	meet = default_meet	+
−		+
−	Саму секцию [default_meet] задавать не надо. Все настройки и так  возьмутся из дефолта.	+
−		+
−	Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна (Во всех примерах зеленым цветом выделены состояния state_manager, синим – звуковые темы):	+
−		+
−	Ситуация 1	+
−	Игрок вдалеке подзывает нас рукой, при приближении просит убрать оружие, потом согласен говорить.	+
−		+
−	[meet]	+
−	meet_state = 50| hello@talk_hello| 20| wait@wait| 10| ward@wait	+
−	meet_state_wpn = 50| hello@talk_hello| 20| threat@threat_weap	+
−	victim = 50| actor	+
−	victim_wpn = 50| actor	+
−	use = true	+
−	use_wpn = false	+
−		+
−	Ситуация 2	+
−	Сталкер завидя нас просит убрать оружие. После этого подходит и заговаривает с нами. Если мы начинаем уходить от него или достаем оружие – начинает нас стрелять.	+
−		+
−	[meet]	+
−	meet_state = 50| {+info} threat_fire %=killactor%, walk@ {+info} talk_abuse, wait | 10 | walk %+info%; wait | 2 | threat;state	+
−	meet_state_wpn = 50| {+info} threat_fire %=killactor%, threat@ {+info} talk_abuse, wait	+
−	victim = 50| actor	+
−	victim_wpn = 50| actor	+
−	use = {-info2} self, false	+
−	use_wpn = false	+
−		+
−	Здесь: info – инфоропшн, который указывает что мы уже опустили оружие и были достаточно близко к НПС	+
−	Info2 – инфопоршн, который устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел.	+
−	Killactor – функция в xr_effects которая обижает НПС на игрока.	+
−		+
−	Ситуация 3	+
−	Персонаж ходит по патрульному пути на заставе лагеря. Если игрок имеет допуск в лагерь – пропускает его и здоровается, иначе сперва отпугивает, а если игрок пробрался в лагерь – то обижается на него. При этом диалог зависит от того, имеет игрок допуск в лагерь или нет.	+
−		+
−	[camper]	+
	path_walk = path_walk		path_walk = path_walk
	path_look = path_look		path_look = path_look
Строка 2106:		Строка 532:
	[meet]		[meet]
−	meet_state = 30| {+info} wait, threat@ {+info} talk_hello, threat_back	+	meet_state = 30|{+info} wait, threat@ {+info} talk_hello, threat_back
−	meet_state_wpn = 30| {+info} wait, threat@ {+info} talk_hello, threat_back	+	meet_state_wpn = 30|{+info} wait, threat@ {+info} talk_hello, threat_back
−	victim = 30| actor	+	victim = 30|actor
−	victim_wpn = 30| actor	+	victim_wpn = 30|actor
−	use = true	+	use = true
−	use_wpn = true	+	use_wpn = true
−	zone = warnzone| {-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse	+	zone = warnzone|{-info} threat@ {-info} threat_back|kampzone| {-info} true@ {-info} talk_abuse
−	meet_dialog = {+info} dialog1, dialog2	+	meet_dialog = {+info} dialog1, dialog2</ini>Здесь:<br>
−		+	'''''true''''' – вместо анимации, атаковать игрока;<br>
−	Здесь:	+	'''''info''''' – инфопорция, которая говорит, что мы имеем допуск к лагерю;<br>
−	True – вместо анимации, атаковать игрока.	+	'''''warnzone''''' – рестриктор, в котором нас предупреждают;<br>
−	Info – Инфопоршн, который говорит что мы имеем допуск к лагерю	+	'''''kampzone''''' – рестриктор, в котором нас убивают;<br>
−	Warnzone – рестриктор, в котором нас предупреждают	+	'''''dialog1''''' – стартовый диалог NPC, если мы имеем допуск в лагерь;<br>
−	Kampzone – рестриктор, в котором нас убивают	+	'''''dialog2''''' – стартовый диалог NPC, если мы не имеем допуск в лагерь.<br>
−	Dialog1 – стартовый диалог НПС, если мы имеем допуск в лагерь	+
−	Dialog2 – стартовый диалог НПС, если мы не имеем допуск в лагерь.	+
−	Дефолтные настройки:	+
−	По дефолту встреча настроена со следующими параметрами:	+
−		+
−	meet_state = 30|hello@hail|20|wait@wait	+
−	meet_state_wpn = 30|backoff@threat_weap	+
−	victim = 30|actor	+
−	victim_wpn = 30|actor	+
−	use = true	+
−	use_wpn = false	+
−	syndata = hello@hail|backoff@threat_weap	+
−		+
−		+
−	NB: Если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet	+
−		+
−		+
−	==3.14. Отметки на минимапе==	+
−	Появилась возможность не показывать сталкеров на минимапе и на карте (прятать синие и красные точки). Для этого в секции логики или в текущей схеме указываем параметр:	+
−		+
−	[camper]	+
−	show_spot = false (будучи в этой секции сталкер не показывается на карте)	+
−		+
−	[walker]	+
−	show_spot = {+info1} false	+
−		+
−	Сталкер не будет показываться, если у игрока есть инфопоршн info1 и т.д.	+
−		+
−	==3.15. Передача параметров в функции.==	+
−	Ниже перечислен набор функций к которым можно обращаться из кастом даты и при этом передавать в них переменные.	+
−		+
−	NB! Во всех функциях xr_conditions и xr_effects, которые обращались к гулагам по имени, теперь можно использовать как имя, так и story id. Причем если мы указываем имя, то использовать функцию можно только, когда гулаг находится в онлайне, а если мы вешаем на самрттеррейн story_id, то можем обращаться к гулагу и в оффлайне.	+
−		+
−	Описание функций с параметрами присутствующих в xr_conditions и xr_effects.	+
−		+
−	---------------------------------------------------------------------	+
−	xr_conditions:	+
−		+
−	fighting_dist_ge(p) – универсальная функция для combat_ignore, проверка расстояния для игрока	+
−	(в метрах)	+
−		+
−	distance_to_obj_le(sid:dist) - проверка дистанции до обьекта заданного	+
−	story_id.	+
−	Можно использовать, например, в секции follower для определения того, что сталкер подошел на нужную дистанцию к лидеру и    переключать в другую секцию (лидер при этом стоит где-то в ремарке). Эта ситуация возникает, когда после боя надо подогнать одного сталкера к другому, а ихних позиций мы не знаем. Если используется в секции follower, то dist надо ставить большим    distance фолловера, поскольку если поставить их одинаковыми, то данная функция не всегда будет срабатывать.	+
−		+
−	health_le(health) - проверка того, что здоровье npc <= health	+
−		+
−	heli_health_le(health) - аналогично предыдущему, только для вертолета.	+
−		+
−	enemy_group(group1:group2:...) - Проверка на принадлежность врага к одной из групп (правильность работы пока не проверялась)	+
−		+
−	hitted_by(sid1:sid2:...) - Проверка того, что удар был нанесен кем-то из npc, указанных в списке. npc задаются с помощью story_id. Функцию удобно использовать в секции hit.	+
−	Пример:	+
−	[hit]	+
−	on_info = {=hitted_by(407:408)} %+val_escort_combat%	+
−		+
−	killed_by(sid1:sid2:...) - Аналогично предыдущему, но для случая смерти npc. Используется в секции death.	+
−		+
−	is_alive(sid)	+
−	is_alive_one(sid1:sid2:...)	+
−	is_alive_all(sid1:sid2:...) - проверка того, что один, один из нескольких или все из списка соответственно npc, заданные по story_id живы	+
−		+
−	is_dead(sid)	+
−	is_dead_one(sid1:sid2:...)	+
−	is_dead_all(sid1:sid2:...) - аналогично предыдущему, только проверка на "мертвость".	+
−		+
−	check_fighting(sid1:sid2:...) - Проверка того, не является ли кто-то из перечисленных (с помощью story_id) npc врагом даного. Как правило используется в combat_ignore_cond.	+
−		+
−	gulag_empty(gulag_name) - проверка того, что гулаг пуст или вообще не существует.	+
−		+
−	gulag_population_le(gulag_name, num) - проверка того, что количество народу в гулаге <= num	+
−		+
−	gulag_casualities_ge(gulag_name:num) – проверка того, что гулаг понес потери => num	+
−	NB! Потери гулага не обнуляются, так что с этой функцией работать аккуратно.	+
−		+
−	signal(строка) – проверяет, установлен ли у данного НПС в текущей схеме указанный сигнал	+
−		+
−	--------------------------------------------------------------------	+
−	xr_effects:	+
−		+
−	heli_set_enemy(story_id) – сделать npc с указанным story_id врагом веротелу. В одной секции можно задавать только 1 врага.	+
−		+
−	set_gulag_enemy_actor(gulag_name) – сделать актера врагом для данного гулага	+
−		+
−	hit_npc(direction:bone:power:impulse:reverse=false) - нанести хит по npc. Параметры:	+
−	direction - если строка, то считается, что это имя пути и в сторону первой точки производится толчек. Если же это число,  то оно рассматривается как story_id персонажа от которого должен поступить хит.	+
−	bone - строка. Имя кости, по которой наносится удар.	+
−	power - сила удара	+
−	impulse - импульс	+
−	reverse (true/false) - изменение направления удара на противоположное. по умолчанию false.	+
−	Пример:	+
−	[death]	+
−	on_info = {=killed_by(404)} %=hit_npc(404:bip01_spine1:100:2000)%, {=killed_by(405)} %=hit_npc(405:bip01_spine1:100:2000)%	+
−		+
−	set_friends(sid1:sid2:...)	+
−	set_enemies(sid1:sid2:...) - установить друзьями/врагами данного npc и указанных в списке по story_id.	+
−		+
−	play_snd(snd_name:delay=0) - играть звук в голове актёра.	+
−	snd_name - путь к звуку относительно папки sounds	+
−	delay - задержка перед проигрыванием. По умолчанию 0 – проигрываем сразу.	+
−		+
−	play_snd_now (sid:snd_name) – играть звук от указанного объекта	+
−	*звук играется об объекта с указанным story id, без задержки с громкостью 1. Указывается не имя звуковой схемы, а имя файла	+
−		+
−	hit_obj(sid, bone, power, impulse, hit_src=npc:position())	+
−	Дать обьекту, заданому story_id, хит. Отличается тем, что может прописываться в любой кастом дате. Параметры: actor, npc, p[sid,bone,power,impulse,hit_src=npc:position()]	+
−	1. sid - story_id обьекта, по которому наносится хит.	+
−	2. bone - строка. Имя кости, по которой наносится удар.	+
−	3. power - сила удара	+
−	4. impulse - импульс	+
−	5. hit_src (необязательный параметр) - точка (waypoint), из которой по объекту наносится хит. Если не задано, то берется позиция обьекта, из которого была вызвана данная функция.	+
−		+
−	actor_has_item(section)	+
−	Проверка на наличие у игрока соответствующего предмета. Проверка проходит по секции в ltx	+
−		+
−	Функции для работы с HUD'ом.	+
−		+
−	disable_ui_elements(...), enable_ui_elements(...) - отключение/включение елементов HUD'а.	+
−		+
−	Параметры:	+
−	-- weapon - спрятать/показать руки с оружием	+
−	-- input - отключить/включить клавиатуру	+
−	-- hud - спрятать/показать индикаторы на экране	+
−	-- all - отключить/включить все элементы	+
−		+
−	Пример:	+
−	on_info = %=disable_ui_elements(weapon:input)%	+
−		+
−	Есть также сокращенные варианты:	+
−		+
−	disable_ui, enable_ui (вызываются без скобок и параметров).	+
−	Аналогичны вызовам disable_ui_elements(all), enable_ui_elements(all) соответственно.	+
−		+
−	Пример:	+
−	on_info = %=enable_ui%	+
−		+
−	Функция запуска camera_effector'а.	+
−		+
−	run_cam_effector(имя_файла)	+
−		+
−	имя_файла (указывается без расширения) - это имя анимационного файла (с расширением anm)	+
−	из папки S:\GameData\anims\camera_effects\.	+
−		+
−	Пример:	+
−	on_info = %=run_cam_effector(prison_0)%	+
−		+
−	Функция запуска постпроцесса.	+
−		+
−	В связи с изменением процесса создания постпроцессов были внесены изменения в их запуск.	+
−	Теперь есть 2 функции для работы с постпроцессами:	+
−		+
−	run_postprocess(file_name:id:loop) - запуск постпроцесса.	+
−		+
−	-- file_name - имя файла постпроцесса (без расширения) из папки s:\gamedata\anims. Указывается без расширения.	+
−	-- id - номер постпроцесса. Задается опционально. Используется в stop_postprocess.	+
−	-- loop - (true/false) определяет зацикленность постпроцесса. Опциональный параметр. По умолчанию false.	+
−		+
−	stop_postprocess(id) - принудительная остановка постпроцесса.	+
−		+
−	-- id - номер постпроцесса заданный в run_postprocess.	+
−		+
−	Функция выброса содержимого инвентаря актера в определенную точку.	+
−		+
−	drop_actor_inventory(имя_пути)	+
−	выбрасываем все предметы из инвентаря актера в первую точку заданного	+	Файл: ''gamedata\scripts\xr_meet.script''
−	пути.	+
−	Пример:	+	----
−	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
−	===[[Настройка логики #2]]===	+	<font size = 5>[[Часть 2]]</font>
−	[[Категория:Скрипты]]	+	[[Категория:A-Life]][[Категория:Скрипты]]
		+	правка дС (дядя Саша - вопросы сюда imgal@mail.ru)

---

Текущая версия на 15:36, 16 сентября 2014

Содержание
Настройка логики. Часть 0 Настройка логики. Часть 1 Настройка логики. Часть 2 Настройка логики. Часть 3 Настройка логики. Часть 4

Настройки логики

Система флагов (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 | другая_схема

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

Настройка:

На карту для каждого walker-а нужно поставить:

1. Путь path_walk, по которому walker ходит.
   
2. Путь path_look, состоящий из точек, в которые walker смотрит.
   

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

Если персонаж должен стоять на месте, то ему задается одна точка пути path_walk и как минимум одна точка пути path_look, хотя и можно не задавать точку взгляда вовсе (игра автоматически определит точку по умолчанию ту, в которую НПС смотрел изначально), делать этого не следует.

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

Пример 1:

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

Как сделать, чтобы персонаж между определенными точками бежал или крался? Для этого в пути path_walk существуют флажки.
У каждого вейпоинта есть имя: wp00, wp01 и т.д.
Флажки задаются в имени. Их нужно отделять от самого имени с помощью символа ‘|’. Пишеться a=anim, где anim – название анимации. Если мы напишем a=threat то персонаж пойдет в состоянии данжер, если 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, которые обведены на рисунке пунктирной линией, в редакторе ставим общие флажки (в ACDC поле flags). Например, в верхней паре точек ставим флажок 0, а в нижней паре точек – флажок 1.

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

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

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

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

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

t = 5000 - время, на которое персонаж задержится в этой точке (по умолчанию 5000 мсек)

Пример 5:

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

По умолчанию при остановках персонаж играет анимацию idle, если он не в состоянии crouch, либо анимацию hide, если он в состоянии crouch.

Если требуется другая анимация, можно ее указать с помощью флажка:

a = имя_анимации - (по умолчанию idle).
Пишеться a=anim, где anim – название анимации. Если мы напишем a=hide, то персонаж сядет в состоянии данжер, если a=guard, то встанет с оружием наизготовку и т.д.

Примечание: В точках пути path_look используются анимации ТОЛЬКО из раздела «Стоячие и сидячие состояния»!

Система флагов для монстров

Флаги пути движения:
s=имя_звуковой_темы

Устанавливает звуковую тему на пути в данную точку (idle, eat, attack, attack_hit, take_damage, die, threaten, steal, panic, growling).

с

Устанавливает положение ходьбы вприсядку.

r

Устанавливает положение ходьбы бег.

sig=name

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

b=vis/invis

Флаг, исключительно для кровососа. Управляет невидимостью (vis - отключена, invis - включена).

Флаги пути обзора:
t=msec

Время в миллисекундах, которое нужно ждать, смотря в точку.

a=state

Анимация (stand_idle, sit_idle, lie_idle, eat, sleep, rest, attack, look_around, turn).

Случайный выбор пути

По поводу точек пути path_walk.
Есть ещё один интересный факт: следующую точку пути path_walk можно задавать рандомно.
Например:

Нам требуется, чтобы НПС стоящий в точке p0 патрулировал территорию по двум цикличным маршрутам:
p0 -> p1 -> p2 -> p0
p0 -> p3 -> p4 -> p0

Чтобы задать вариацию выбора маршрута относительно точки p0, нужно в ссылке на следующую точку пути указать не одну, а две точки:

p0:links = p1(1), p3(1)

Таким не хитрым образом, НПС для продолжения пути рандомно выберет одну из предложенных точек p1 или p3. После возврата в точку p0 выбор проследует вновь. Варьировать выбор можно в любой точки, например, можно сделать так:

p0:links = p1(1), p3(1)

а в точке p1, также задать выбор:

p1:links = p2(1), p3(1)

НО! Не следует делать выбор между двумя путями, если в пути одна точка! Вот такая схема НЕ ПРИЕМЛЕМА и, лично у меня, вызывает вылет:

Цифры в скобках, означают ту самую вероятность с которой НПС пойдёт в точку. Если цифры задать одинаковые, то и вероятность выбора для каждой точки будет равная, если же, например, в одной из точек указать значение 0.75, а в другой 0.25:

p1:links = p2(0.75), p3(0.25)

то соответственно в точку p2 НПС будет ходить в три раза чаще.

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

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

Схема walker

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

[walker]
path_walk = <имя_пути> - основной путь, по которому ходит NPC
path_look = <имя_пути> - путь, куда смотрит NPC
team = <имя_команды> - команда для синхронизации
def_state_moving1 = <название_анимации> - состояние, в котором NPC движется к первой точке пути, если она близко (patrol по умолчанию)
def_state_moving2 = <название_анимации> - состояние, в котором NPC движется к первой точке пути, если она не слишком далеко (rush по умолчанию)
def_state_moving3 = <название_анимации> - состояние, в котором NPC движется к первой точке пути, если она далеко (sprint по умолчанию)
def_state_standing = <название_анимации> - дефолтное состояние в котором он стоит и смотрит на точку, если в этой точке не задана другое состояние.

В точках path_walk, которым соответствуют точки пути path_look (стоят одинаковые флажки) персонаж останавливается и смотрит в определенную точку, при этом отыгрывая (или не отыгрывая) определенную анимацию.

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

[walker@pri_followers_leader_wave1_wait]
path_walk = wave1_leader_walk2
path_look = wave1_leader_look2
def_state_moving1 = assault
def_state_moving2 = assault
team = followers

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

Схема remark

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

Примечание: не используйте эту схему в качестве активной - это вызовет неправильное поведение NPC.

[remark]
snd_anim_synс = true/false - по умолчанию false. Указывает на то необходимо ли синхронизировать звук с анимацией.
snd = <название_звуковой_темы> - звук ремарка, берётся из файла sound_theme.script. По умолчанию nil.
anim = <название_анимации> - анимация ремарка, по умолчанию wait.
target = <параметр> - куда смотрит сталкер. Есть следующие варианты:

• story_id – числовое значение в ТЧ и ЧН или строковое, с указанием дополнительного параметра и самого SID, в ЗП, в примере ниже указана часть логики монолитовца-проповедника в Припяти, когда тот стреляет в Айса;
  

Пример (ЗП):

target =  story | pri_a17_military_sergeant_morozov

• actor – без комментариев;
  
• nil – позиция вычисленная АИ автоматически;
  
• <имя работы>,<имя гулага> - смотреть на сталкера который находится на определенной работе под гулагом (второй параметр необязателен. В этом случае берется гулаг NPC, для которого задана данная секция ремарка).
  

Пример:

target = logic@cit_killers_base_guard, cit_killers

• <path_name>,<point_number> - можно указывать смотреть в вершину патрульного пути (<имя пути>,<имя точки>).
  

Пример:

target = cit_killers_kamp5,0

Примечание: теперь если значение не задано, то оно равно nil а не actor, как было раньше.

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

Стандартные сигналы remarkа для параметра переключения схемы on_signal:

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

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

[remark@esc_lager_volk2]
anim = guard_rac
snd = esc_wolf_radio
target = actor
on_signal = sound_end| remark@esc_lager_volk3

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

Схема sleeper

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

[sleeper]
path_main = <имя_пути> - точка в которой NPC будет спать - второй поинт, развернувшись в нулевой поинт.
wakeable = true/false – может ли проснуться быстро (если true, то спит на корточках и во сне бормочет).

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

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

[sleeper@esc_blockpost_sleep1]
path_main = sleep1
wakeable = false

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

Схема kamp

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

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

Примечание: Если точка кампа находится в костре, то в оффлайне сталкера прийдут на нее, а когда они перейдут в онлайн, то окажутся внутри костра, где и получат хит.

Чтобы этого не случалось в секции кемпа указывать path_walk из одной точке, название которой <path_kamp_name>_task:

path_walk = <имя_пути>_task

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

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

[kamp@esc_blockpost_kamp1]
center_point = kamp_center
path_walk = kamp_center_task
def_state_moving = raid

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

Схема camper

Свойства камперов:

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

[camper]
path_walk = <имя_пути> - путь по которому ходит NPC.
path_look = <имя_пути> - точки в которые смотрит NPC.
radius = <number> – если расстояние между NPC и противником меньше указанного, то он уходит в универсальный комбат. По умолчанию - 20 метров.
no_retreat = true/false - NPC при виде врага не будет ломиться на ближайшую точку path_walk, а сразу перейдет в режим убивания.

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

def_state_moving = <название_анимации> - состояние, в котором NPC движется на ближайшую точку пути при враге. По умолчанию - assault.
def_state_moving_fire = <название_анимации> - состояние, в котором NPC отстреливается от врага, во время движения на ближайшую точку пути.

По умолчанию - sneak_fire.

def_state_campering = <название_анимации> - состояние, в котором NPC ожидает врага, находясь на пути. По умолчанию - hide.
def_state_campering_fire = <название_анимации> - состояние, в котором NPC отстреливается от врага, находясь на пути. По умолчанию hide_fire.
attack_sound = <имя_звуковой_темы> - возможность переопределять снайперам/камперам звук атаки. По дефолту он равен звуковой теме fight_attack.

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

shoot = <тип_стрельбы> - возможны следующие значения:

• always - значение по умолчанию, стреляет всегда, когда можно;
  
• none - не стреляет вообще;
  
• terminal - стреляет только когда находится на последней точки патрульного пути. Это сделано для облегчения построение атакующих сцен.
  

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

то он тупо продолжает стоять на старом месте и ждать следующей пули.

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

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

[camper@dar_military_scout_hide]
path_walk = walk_hide
path_look = look_hide
radius = 10
no_retreat = true
def_state_moving = assault
def_state_campering = hide_na
shoot = always

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

Схема sniper

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

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

sniper = true

Пример:

[camper@esc_blockpost_camper_day]
path_walk = camper_day_walk
path_look = camper_day_look
sniper = true
def_state_campering = threat

Примечание: Ставить снайперу только 2 точки look.

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

Схема follower

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

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

Примечание: Не забыть прописать:

[smart_terrains]
none = true

Иначе NPC засосёт в гулаг и никуда он не пойдёт.

Если все это происходит под гулагом, то вместо story_id лидера, мы прописываем его секцию логики в файле скрипта.

Пример:

t = { section = "logic@bar_arena_follower_2", 
      idle    = 0,
      prior   = 7,
      state   = {0},
      squad   = squad,
      group   = groups[0],
      ...
    }

В данном случае для параметра leader необоходимо указать строку bar_arena_follower_2.

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

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

Схема zoneguard

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

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

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

[zoneguard]
path_walk = mil_freedom_zoneguard_walk_kill2
path_look = mil_freedom_zoneguard_look_kill2
zone_warn = mil_freedom_leader_warn_zone
zone_guard = mil_freedom_leader_kill_zone
no_move = true
team = freedom_bodyguards3

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

Схема wounded

Схема раненного. Определяет поведение NPC в состоянии "раненный".
Примечание: не рекомендуется задавать схему в качестве активной.

[wounded]
hp_state = <HP>|<название_анимации>@<название_звуковой_темы> - поведение NPC при значении уровня его здоровья равному HP, когда он не видит игрока.
hp_state_see = <HP>|<название_анимации>@<название_звуковой_темы> - поведение NPC при значении уровня его здоровья равному HP, когда он видит игрока.
psy_state = <PSY>|<название_анимации>@<название_звуковой_темы> - поведение NPC при псиатаках, в зависимости от уровня пси-здоровья равному PSY.
hp_victim = <HP>|<параметр> - куда будет смотреть NPC при значении уровня его здоровья равному HP, возможные параметры:

• story_id - числовое значение;
• actor - без комментариев;
• nil - позиция вычисленная АИ автоматически.

hp_cover = <HP>|true/false - идти в укрытие или нет, в зависимости от значения уровня здоровья равному HP.
hp_fight = <HP>|true/false - разрешено воевать или нет, в зависимости от значения уровня здоровья равному HP.
syndata = <название_анимации>@<название_звуковой_темы> - синхропары для красоты.
help_dialog = <название_диалога> - возможность установить диалог, вместо стандартного actor_help_wounded.
help_start_dialog = <название_диалога> - возможность установить стартовый диалог.

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

<precondition>dialogs.allow_wounded_dialog</precondition>

Примечание: если необходимо поставить несколько состояний, в зависимости от разного значения уровня здоровья, то сами состояния нужно разделять символом ‘|’:

hp_state= 30|help_me@help|10|wounded_heavy@help_heavy

Здесь определятся два состояния при уровне здоровья 30 и 10 соответственно.

Для параметров hp_state_see, psy_state, hp_victim, hp_cover, hp_fight способ такой же.

Пример использования схемы (в качестве примера взята дефолтная настройка):

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|psy_shoot,psy_pain@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 – проверка на то, что лучшее оружие NPC является пистолетом.

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

Схема rest

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

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

Схема heli_hunter

Хелихантер может стрелять либо не стрелять по вертолету в зависимости от условий. Делается это так:

В активную схему вставляется параметр:

heli_hunter = {+info -info =func !func ~number}true/false

Пример:

[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 <br>%=bar_freedom_angry_actor%
meet_talk_enabled = true
meet_dialog = bar_svoboda_dialog
heli_hunter = {-bar_ecolog_crush_heli_down} true

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

Схема patrol

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

[patrol]
path_walk = <имя_пути> - путь по которому ходит NPC.
path_look = <имя_пути> - точки в которые смотрит NPC.
formation = <параметр> - описывет способ построения и не является обязательным. Возможны следующие варианты:

• back - мужики идут чуть позади командира в два ряда (по умолчанию);
  
• line - шеренга;
  
• around - вокруг командира.
  

commander = true/false - будет ли NPC назначен командиром, желательно, чтобы такой красивый он был один. false - по умолчанию.
move_type = <название_анимации> - задает изначальный режим перемещения, по умолчанию patrol.

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

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

ret=0...2

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

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

Примечание: что еще не сделано или глючит:

• нет возможности автоматически перестроить команду;
• все идут молча;
• командор пока не отдает команд;
• не рекомендуется включать спринт.

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

[patrol@val_escort_captive_wait]
path_walk           = captive_wait_walk
path_look           = captive_wait_look
commander           = true
formation           = back

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

Схема meet

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

[meet]
meet_state/meet_state_wpn = <number>|<название_анимации>@<название_звуковой_темы> – задает анимацию и озвучку персонажа,

в зависимости от расстояния до актера равному number. Для ситуации, когда актор безоружен и вооружён соответственно.

victim/victim_wpn = <number>|<параметр> - задает объект, на который должен будет смотреть персонаж, в зависимости от расстояния равное number.

Для ситуации, когда актор безоружен и вооружён соответственно. Возможны следующие значения:

• actor - смотреть на игрока;
  
• story_id - смотреть на персонажа со указанным story_id;
  
• nil - никуда.
  

use/use_wpn = true/false/self - настройки юзабельности персонажа.

При установки значения self NPC сам юзнет игрока, как только сможет дотянуться.

zone = <имя_зоны>|<название_анимации>@<название_звуковой_темы> - если актор будет замечен в указанном рестрикторе,

то NPC будет отыгрывать заданную анимацию и произносить заданный звук.

meet_dialog = <название_диалога> - возможность установить стартовый диалог NPC.
synpairs = <название_анимации>@<название_звуковой_темы> - Если при каком-то наборе условий

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

abuse = true/false - по умолчанию true, если false, то неюзающийся противник не будет обижаться.
precond = usability/visibility.

Любую строку можно задавать кондлистом ({+info -info =func !func ~number}).

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

[walker]
meet = default_meet

Саму секцию default_meet задавать не надо. Все настройки и так возьмутся из дефолта. По дефолту встреча настроена со следующими параметрами:

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

Примечание: если нужно, чтобы сталкер не разговаривал с игроком в данной секции, необходимо прописать ему meet = no_meet.

Теперь о том, как с помощью этого конструктора собрать ту реакцию на актера, которая вам нужна.

• Ситуация 1.
  

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

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

• Ситуация 2.
  

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

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

Здесь:

info – инфопорция, которая указывает что мы уже опустили оружие и были достаточно близко к NPC;
info2 – инфопорция, которая устанавливается в диалоге и говорит что персонаж уже сказал нам все, что хотел;
killactor – функция в xr_effects.script которая обижает NPC на игрока.

• Ситуация 3.
  

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

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

Здесь:

true – вместо анимации, атаковать игрока;
info – инфопорция, которая говорит, что мы имеем допуск к лагерю;
warnzone – рестриктор, в котором нас предупреждают;
kampzone – рестриктор, в котором нас убивают;
dialog1 – стартовый диалог NPC, если мы имеем допуск в лагерь;
dialog2 – стартовый диалог NPC, если мы не имеем допуск в лагерь.

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

---

Часть 2 правка дС (дядя Саша - вопросы сюда imgal@mail.ru)