В сталкире есть 4 типа рестрикторов:
- IN, в который нельзя входить
- OUT, из которого нельзя выходить
- NONE, который по умолчанию для всяких там событий и триггеров
- и непонятный NOT A default restrictor, который хрен пойми для чего нужен.

Собственно вопрос - для каких целей придуман последний по списку тип рестрикторов? Не нашёл, где он используется, окромя катсцен.

Судя по всему это просто дефолтный тип, который выставляется по-умолчанию, не более.

Что-то тема заглохла. Для чего-же всё-таки нужен этот четвёртый тип?

Это рестриктор, который гарантирует несрабатывание на кого-либо. NOT A - подразумевается NOT Action.

Мы ночью с ребятами в дискорде, а конкретно на сервере MetroEX, уже бурно обсуждали почему рестрикторы называются рестрикторами, а не trigger volumes. Система которая используется в сталкире, а так же была унаследована в метро, видимо очень сложна и тем кто всю жизнь сидел на других движках трудна для понимания.

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

И чем тогда это отличается от шейпа? Непонимат

А шейпы игра не использует, они только в ЛЕ.

Если глянуть в сорцы то с NOT A restrictor как-раз всё просто и понятно, в классах которые обрабатывают рестрикторы для АИ он не регистрируется, и соответственно на АИ никак не влияет.
Но это наводит на другой аналогичный вопрос: какую функцию для АИ выполняет NONE default restrictor? Они как-раз регистрируются.

Простым языком говоря, когда ты когда в рестриктор заходишь, он срабатывает. Остальное отбросим. На NOT A рестрикторах отключена проверка контакта сферы рестриктора с объектом, он никогда при контакте не сработает.
Я бы сказал, что это нужно больше для ускорения, потому как там отсекаются все дальнейшие проверки на таких рестрикторах. К примеру ты штук 100 расставишь рестрикторов с таймерами или подобной байдой, для которых контакт не нужен. И будут меж ними 100 неписей ходить туда-сюда. Так вот чтоб рестрикторы постоянно впустую не проверялись на контакт, им лучше поставить NOT A тип. Что-то типа того.

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

Есть скрипт_зона, которая основана на рестрикторе и и работает примерно как описано, но в ней тип рестриктора нигде не проверяется. И скрипт_зона вроде нигде не используется в игре.
Вместо этого в sr_* скриптах накорячена проверка находтся ли актёр внутри обычного рестриктора и дёргаются нужные коллбеки в зависимости от изменения этого состояния. Тип рестриктора так-же не проверяется.

Я попутал срабатывание с обнаружением. Такие рестирикторы еще на стадии обнаружения отсекаются. Ну и плюс не регистрируется. В общем, АИ максимально не обрабатываются. Так что да, я чутка перепутал, но суть та же осталась.

"NONE default restrictor" может добавить НПЦ в in/out рестрикторы какая-то другая подсистема. Например, скрипт обхода аномалий.

Вот надысь заметил, что у монстров и у сталкеров в m_stalker.ltx есть параметр:

SpaceRestrictionSection = space_restrictor, zone_mine_field

Это по идее названия "объектов", куда лезть не нужно. То есть, если через запятую добавить названия секций всех аномалий, то они их будут обходить?

Upd: посмотрел, в xrgame.dll 1.0006 нет такого параметра. В xrgame.dll 2215 есть. Похоже, из финалки выкусили, но в исходниках упоминаются.

Должно работать. Только прописываются не секции, а имена объектов аномалий

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


Сейчас этот параметр читается СДК. ЛЕ прочитает из конфига, запишет в нет-пакет, а движок уже прочитает из нет-пакета. В ЛЕ соотвествует свойствам in_space_restrictions, out_space_restrictions.

Другими словами, в спавн сталкера. Вот смотрю некоторые спавны, разобранные через ACDC. У сталкеров и монстров есть параметры:

dynamic_out_restrictions =
dynamic_in_restrictions =

Примечание:
dynamic_out_restrictions - Рестрикторы, за пределами которых объекту нельзя быть.
dynamic_in_restrictions - Рестрикторы, внутри которых объекту нельзя быть.

Так вот, все стоят пустые. Отсюда вопрос, работает ли фича в ЛЕ (ТЧ) вообще? И если движок игры ее поддерживает, может возможно через ACDC заполнить эти поля? И есть ли у кого примеры из ACDC с заполненными полями?

Но возможно рестрикторы пишутся в спавн самим аномалиям. В ACDC у каждой аномалии/костра есть заполненный пункт restrictor_type = цифра.
Выходит, в соответствии с этой статьей аномалиям есть смысл ставить цифру 2 или 4, чтобв НПСи в них не заходили.

Это они и есть.


Надо заполнить их в ЛЕ, собрать спавн, разобрать его асдс и сразу увидишь, работает или нет. В исходниках все для работы есть. И да, за 20 лет никто не удосужился проверить.


Конечно возможно. Перечисляешь через запятую имена аномалий.


Аномалии это и есть рестрикторы. Если хочешь, чтобы аномалия автоматически добавилась всем монстрам и НПЦ на уровне в список мест, куда заходить нельзя, ставишь тип 2(default in restrictor).

Если у тебя есть скрипт обхода аномалий на рестрикторах или движковый на них же, ставишь тип 0. Тогда скрипт добавит аномалию в список мест, куда заходить нельзя, только для конкретного НПЦ.

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

Тогда понятно, проще цифру "тип 2(default in restrictor)" прописать, чем ковыряться в этих хитросплетениях.

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

Еще во времена АМК написали скрипты динамических аномалий и их обхода. И все эти СДК/оллспавновские изыски стали неактуальны.

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

На ваниле да, хотя alpet в движке NLC 7 это дело улучшил, стало больше поддерживать. Кому надо - можно посмотреть в репо сорцов как сделано.
Но в любом случае вещь эта тормозная. В скриптах обхода аномалий применяют хак - лишь некоторое кол-во самых ближних рестрикторов (аномалий) добавляют мобам. Динамически, разумеется. Отдаленные извлекают. Ну, таким вот макаром обходчик более-менее фурычит.