Shredder

Отлично. Я тоже собирался такую систему делать, правда без анимации. Но теперь просто дождусь релиза И маленький момент, зачем он вздыхает, перед тем как начинает пить? Там же вода. Я понимаю, что это стандартный звук, но начало можно отрезать. В целом идея и реализация на отлично!

Проверь имена смартов, указанные в simulations.ltx. Скорее всего опечатка где-то, потому что вот код:

STRIFER, в dialogs_zaton.script

Вопрос по state_mgr. В ЗП часто онлайновые НПС во время выброса не успевают добежать до укрытия. Я решил устранить эту ошибку, но столкнулся с проблемой. В схеме xr_reach_task.script я добавил следующий код

А куда ты их прописал в simulations.ltx? В [start_position_pripyat]? Если ты оставил код в se_actor закоментированным (--sim_board.get_sim_board():fill_start_position()), то естественно у тебя ничего спавниться не будет

Если ai сетку не трогал, то достаточно только спавн собрать. В SDK делаешь Compile->Build, потом Compile->Make Game. В папку gamedata/levels/pripyat закидываешь из расспакованого ЗП файл level.ai (из levels/pripyat). Затем собираешь спавн: start bin\designer\release\xrai -no_separator_check -s pripyat. Да, квестов не будет.

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

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

В общем, нет. Никакие действия пользователя в инвентаре отследить нельзя. Ты можешь сделать документ по типу используемого предмета и проверять секцию в колбэке use_item биндера актора.

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

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

Не могу точно утверждать, что в ТЧ работает так же, но в ЗП в логику добавляется такой параметр: can_select_weapon = false

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

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

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) Тормозов то не вызовет, но вот сам скрипт добавления таких зон и их связи с аномалиями может оказаться сложнее элементарной проверки расстояния.

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

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

Поэтому, если вызвать функцию из примера просто как is_wounded(...), то эта функция будет и запрашиваться из таблицы _G. Там такой нет. Вылет. Я видимо что-то не понимаю. Сперва поиск функции будет осуществляться в текущем модуле (_M), там она есть. От куда вылет?

Посоветую перед строкой 611 добавить проверку:

Ищи в этой теме http://www.amk-team.ru/forum/index.php?showtopic=10538, там написано, как собрать готовый xrGame.dll

CUIScrollView, будет только вертикальный скролл.

start bin\designer\release\xrai -no_separator_check -s zaton,jupiter,pripyat, на выходе будет zaton.spawn, переименовывай в all.spawn и кидай в игру.

Другого способа я не знаю. Если я не ошибаюсь, чтобы собрать полный спавн (т.е. всех локаций) нужны level.spawn каждой локации, каждый в своей папке, тогда можно попробовать собрать полный спавн, Правда если ты что-то добавлял через acdc это потеряется. Тогда после сборки спавна распаковываешь его acdc и подсовываешь файлы от того, который рабочий (расспакованный all.spawn) Я не гарантирую, что получится, но я бы на твоём месте попробовал так. Может кто из гуру SDK дадут более дельный совет.

xray-extension для ЗП

А all.spawn заменял?