Скриптование

[Полтергейст 37]

При вызове метода patrol_path_make_inactual() почему-то не всегда убирается путь, то есть непосредственно после вызова и даже на следующих апдейтах метод patrol() продолжает возвращать имя того пути, который был установлен. path_completed() возвращает false.

Самое интересное в том, что после вызова patrol_path_make_inactual путь заново нигде не устанавливается, то есть set_patrol_path нигде не вызывается. Что ещё можно попробовать сделать, чтобы путь обнулился?

[Artos 99]

Viнt@rь, функции работы с ПНВ и фонариком в xr_effects от ЗП (CoP) имеют порок: в них обрабатывается первый попавшийся у актора в инвентаре фонарик...  А в модах нередко имеется возможность наличия у актора не одного фонарика.
Более правильно эти функции переписать, ужесточив условие определения фонарика (должен быть в слоте, а не в рюкзаке):
 

local torch = db.actor:item_in_slot(10) --/ для ТЧ(SHoC) это 9-ый слот

 тогда не будет непоняток, отчего фонарик иль ПНВ не переключает свое состояние.

 

Не вернулся, а просто заглядываю изредка... и не смог на этот раз пройти мимо и не помочь.

 

Изменено 2 Марта 2013 пользователем Artos

[Полтергейст 37]

В этой теме где-то раньше задавали вопрос о том, как отслеживать попадание любого NPC в рестриктор. Есть один способ сделать это без перебора всех NPC с последующей проверкой на вхождение (inside). Для этого в system.ltx или любом включенном в него конфиге нужно создать секцию, содержимое которой будет совпадать с секцией [script_zone], за исключением строки script_binding. Дальше надо написать биндер, в котором обрабатываются коллбеки на вход/выход из зоны (можно подсмотреть, как это делается в xr_zones.script).

 

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

[Shredder 49]

Зачем создавать новую секцию? Можно же эти коллбэки в биндере рестриктора навешать. И не понятно, что ты хочешь сделать, для чего нужно регистрировать попадание любого нпс в зону и использовать это в логике? Разъясни, тогда можно будет что-то предложить.

[Полтергейст 37]

И не понятно, что ты хочешь сделать, для чего нужно регистрировать попадание любого нпс в зону и использовать это в логике?

 

Например, для открывания дверей можно было бы использовать. Или добавлять зону в рестрикторы при входе в неё, например создать такую скрипт-зону вокруг аномалии и всем, кто в неё входит, запрещать идти в аномалию (у себя я так и сделал).

На обычных рестрикторах эти коллбеки не работают, поэтому и нужна другая секция.

 

Вот, кстати, тот вопрос

Изменено 3 Марта 2013 пользователем Полтергейст

[Shredder 49]

1) Двери для НПС и так открываются (в ЗП точно) Если в ТЧ не открываются, тогда можно доработать биндер. Как только нпс попадает в зону, увеличивать переменную-счётчик, когда выходит из зоны - уменьшать. Добавить функцию в xr_condition, которая проверяет если кто-нибудь в этой зоне, считывая этот счётчик. В логике двери добавить проверку этой функции, в неё передавать один аргумент - story_id зоны. Если в зоне кто-то есть - открывать дверь, нет - закрывать. Как бы не сложно.

2) Для обхода аномалий нпсями лучше использовать скрипт от амк, там каждому нпс аномалии добавляются как in-рестрикторы и движок сам не пускает сталкеров в аномалий. А в твоём способе для каждой аномалии придётся добавлять такую зону, которая в итоге тоже будет добавлять аномалии в список in-рестрикторов нпс, когда тот в неё попадёт (в зону, а не аномалию). 

[Полтергейст 37]

тогда можно доработать биндер. Как только нпс попадает в зону, увеличивать переменную-счётчик, когда выходит из зоны - уменьшать

 

Можно, но тогда придётся перебирать всех (!) NPC на уровне и проверять на вхождение в зону с помощью функции utils.npc_in_zone. Это будет съедать ресурсы и может привести к существенным тормозам. Проблема в том, что для обычного рестриктора нельзя отследить момент, когда нпс попадает в зону или выходит из неё.

 

там каждому нпс аномалии добавляются как in-рестрикторы и движок сам не пускает сталкеров в аномалий

Для этого там через каждые пройденные 15 метров также перебирается список всех аномалий на уровне.Хоть и не на каждом update, но всё равно.

 

 А в твоём способе для каждой аномалии придётся добавлять такую зону, которая в итоге тоже будет добавлять аномалии в список in-рестрикторов нпс, когда тот в неё попадёт

 

Для всего количества аномалий на уровне - не так уж и много, во всяком случае, заметных тормозов и глюков не вызывает. Зато не нужно заморачиваться с расчётом расстояний до каждой аномалии. Нечто подобное разрабы сделали с кострами - каждому костру добавили дополнительную внешнюю оболочку, только добавляются они как default in restrictor, а не динамически.

Изменено 3 Марта 2013 пользователем Полтергейст

[Shredder 49]

1) Зачем перебирать всех нпс? Создаём таблицу, например db.npc_in_zones. В биндере в методах enter_zone, exit_zone делаем npc_in_zones[zone.store_id] = npc_in_zones[zone.store_id] +(-) 1. Теперь, чтобы проверить, есть ли кто-то в зоне с определённым story_id нужно просто проверять npc_in_zones[zone.store_id] and npc_in_zones[zone.store_id] > 0. В xr_conditions добавляем функцию, которая делает такую проверку и используем эту функцию в логике дверей. Другое дело, что для каждой двери придётся отдельную логику прописать.

2) Ну и что. Это перебор всех аномалий, а не 65535 объектов. Твой подход добавления для каждой аномалии отдельной зоны не даст сколь-нибудь заметного прироста фпс, если только у тебя на уровне онлайн сразу 100 нпс. Тут точно шкурка выделки не стоит.

3) Тормозов то не вызовет, но вот сам скрипт добавления таких зон и их связи с аномалиями может оказаться сложнее элементарной проверки расстояния.

[Полтергейст 37]

В биндере в методах enter_zone, exit_zone делаем

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

 

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

[Shredder 49]

1) Так а кто говорил про обычные рестрикторы? Добавляешь новую секцию, биндер которой обрабатывает enter_zone, exit_zone и возле каждой двери на уровне ставишь такую зону, прописав ей story_id. В логике этой двери добавляешь проверку "есть ли кто-нибудь в зоне со story_id = ???".

2) Ну и зря. Там всё легко и просто. Я подключил у себя этот скрипт к ЗП, прекрастно работает.

[Полтергейст 37]

Нашёл способ включить эти коллбеки для обычных рестрикторов, чтобы не возиться с созданием новой секции и биндера. Для этого в файле class_registrator.script заменить эту строку

cs_register(object_factory, "CSpaceRestrictor", "se_zones.se_restrictor", "SPC_RS_S", "script_restr")

на эту:

cs_register(object_factory, "ce_script_zone", "se_zones.se_restrictor", "SPC_RS_S", "script_restr")

Тогда можно будет создавать списки всех, кто находится в этой зоне, добавлять функцию работы с этими списками в xr_conditions и использовать в логике обычных рестрикторов. Кроме этих коллбеков у биндера рестрикторов появятся свои обновления, то есть уже не нужно будет их вызывать из биндера игрока.

Изменено 4 Марта 2013 пользователем Полтергейст

[Shredder 49]

Ты ТЧ ковыряешь? В ЗП рестрикторы и так сам обновляются. И возможно колбэки по умолчанию работают, я не проверял.

[Artos 99]

Познавательный диалог... 

Один только сейчас обнаружил то, что ПЫС'овцы 4 года назад в ЗП сделали (перевели все с CSpaceRestrictor на ce_script_zone), а второй не ведая пользуется и дает советы...

 

Полтергейст, осмелюсь посоветовать к твоему "открытию" повнимательнее посмотреть упоминавшийся выше xr_zones.script, в частности сохранение и чтение объектов попавших в зоны "хитрых" рестрикторов, иначе с сэйвами могут быть "странности"... ;-)

 

Примечание: Упомянутая правка для class_registrator.script проверена на практике уже не один год и каких-либо коллизий в ТЧ не выявлено.

[Shredder 49]

... а второй не ведая пользуется и дает советы...

Да я и не пользуюсь, в ЗП всё и так работает, поэтому я глубоко и не ковырял.

[Полтергейст 37]

сохранение и чтение объектов попавших в зоны "хитрых" рестрикторов, иначе с сэйвами могут быть "странности"... ;-)

Да вот не пойму что-то, там для получения длины хеш-таблицы почему-то используется table.getn, а не увеличение количества в цикле pairs. Это имелось в виду?

Ещё один недостаток - после загрузки объекты не проверяются на нахождение внутри рестриктора, хотя сохраняемые NPC могли запросто в оффлайне куда-нибудь уйти. На "Арене" такого всё равно не происходит, а в остальных случаях проверку делать надо обязательно.

 

Один только сейчас обнаружил то, что ПЫС'овцы 4 года назад в ЗП сделали

У меня нет под рукой скриптов от ЗП, а в интернете я нигде не нашёл упоминаний такой правки для ТЧ.

Изменено 5 Марта 2013 пользователем Полтергейст

[Shredder 49]

Ещё один недостаток - после загрузки объекты не проверяются на нахождение внутри рестриктора, хотя сохраняемые NPC могли запросто в оффлайне куда-нибудь уйти.

Так кто мешает в методе net_spawn зоны перебрать все онлайн объекты и проверить их на вхождение в эту зону? Тогда и сохранять ничего не нужно будет.

[Artos 99]

Полтергейст, как нередко бывает, ошибка некоего разработчика ПЫС возможно и не дала развития этому направлению. 'table.getn' - в данном случае именно ошибка (легко устранимая).

Ну а считать недостатком то, что попросту невозможно в принципе - заблуждение. Ну как можно ожидать от еще не до конца забинденного рестриктора и, вполне вероятно, еще далеко не всех забинденных неписей/объектов возможности проверки 'нахождения внутри'? ;-) Хотса иметь такую проверку - пиши свою с использованием уже заспавненных серверных объектов и конечно же с погрешностью...

Ну и не стОит оправдывать "изобретательство велосипедов" тем, что самому же лень поглядывать по сторонам...

 

Shredder, не зашоривайся (и других тоже) только на очевидном и обще-используемом. Алгоритм игры далеко не ограничен временем от "уже все загружены и забиндены" и до "уже все сохранены"... Подобные упрощения и игнорирования того, что между загрузкой (load) и нет-спавном (net_spawn) имеется тоже немаловажный момент, приводят порой к странным вылетам и проблемамЮ да и лишают возможности что-либо сделать нестандартное. Тебе, в твоих ковыряниях может и не требуется учитывать, хотя ... скорее просто натыкался на "стену" и уходил в сторону.

 

Ну а без конкретики (которой нет в исходном вопросе) - далее вопрос переходит в оффтопик или флуд... закругляюсь.

[Shredder 49]

Artos, ты как-то непонятно объяснил. Пусть даже не net_spawn, а первый апдейт зоны. Ну и что, что возможно ещё не все НПС вышли в онлайн, нас интересуют только те, кто уже вышел. А те кто буду выходить, отметятся через колбэки, или нет?

[Artos 99]

Shredder, не я непонятно объяснил (да и не объяснял, а пытался дать пищу для твоих/ваших размышлений!), а ты непонятлив из- за своей зашоренности... Я тебе про "фому", а ты то про "ерему", а то и дальше... 1-ый апдейт зоны еще дальше от момента старта игры, чем net_spawn . "те, кто будет выходить" - конечно же отметятся. Но это уже после достаточно длительного времени по меркам алгоритмов игры.

А если требуется в самом начале манипулировать со свойствами тех, кто был иль не был в зоне?! К твоему сведению, от инициализации модулей/скрипов при загрузке игры и до "1-го апдейта" проходят секунды (а в некоторых модах и десятки).

 

Без конкретики подобное достаточно бессмысленно пояснять. 

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

Все хорошо, когда игрок играет непрерывно и не делает сэйвы в активные фазы выброса.

Но вот когда сделан сэйв именно в активную фазу, когда неписи уже рассажены по "укрытиям-подвальчикам" и расставлены по позициям - возникают при загрузке сэйва проблемы. Если в сэйв не писать "все и вся" то как узнать кому какое укрытие было прописано, а кто был снаружи? Логика для неписей читается и активируется ДО их первых апдейтов и какая AI-схема и какая секция (не зашориваться только на штатных!) им будет первой прописана - зависит как раз от начальных параметров.

 

[Shredder 49]

И всё-таки, если взять в расчёт применение таких зон к "открытию дверей для НПС" и своеобразному методу "обхода аномалий", которые и были упомянуты Полтергейстом, то сохранение объектов, находящихся в зоне не нужно. Т.к.

 1) нужно учитывать только онлайновых НПС

 2) колбэк on_enter срабатывает, если онлайновый НПС был уже в области зоны и вышел в онлайн

 3) колбэк on_exit срабатывает, когда НПС, находящийся в зоне уходит оффлайн.