Полтергейст

Возможно ли сделать так, чтобы аномалии реагировали на пули без ковыряния движка? ---- Проверьте в m_stalker.ltx строку attachable_items. Если водки там нет, то это и есть причина, надо дописать. У меня такая же байда с биноклем - везде заменил binocular_a на wpn_binoc, а он так не работает - идёт пустая анимация.

В общем-то ничего сложного в этом нет, именно по такому принципу работают смарты (работы задаются динамическими ltx, смотрите gulag_general.script). Вопрос в том, не придётся ли респавнить объекты для применения параметров? Хотя, если сделать это в виде переключения режимов огня, то это и не нужно, по идее можно даже класс менять. Надо будет попробовать проделать такое с вертолётом, чтобы, к примеру, он мог бросить что-нибудь типа бомбы (сменить класс на G_FAKE с G_RPG7).

Дохнут те, что онлайн, остальные целые и невредимые. Так?

Не надо ничего доспавнивать. Вам нужно просто изменить поле "communities" в большинстве смартов, у которых type = general_lager или general_lair, а именно - дописать в communities как можно больше группировок. В моей версии этого мода, к примеру, долговцы свободно (извиняюсь за каламбур) ходят по кордону. Можно даже встретить военных на АТП, на ферме, на переходе на свалку.

Найдите в all.spawn смарт с именем "esc_lager", там в customdata есть ссылка на этот респавн.

Скорее всего это баг из-за разницы состояний (онлайн/оффлайн) между тайником и предметом. Надо будет попробовать синхронизировать. Первое, что приходит в голову - сделать поле owner в серверном объекте предмета и по нему определять "владельца" предмета, а заодно и его состояние. То есть, значения функций can_switch_*() для предметов подогнать под значения таких же функций для объекта, указанного в поле owner. Тогда все предметы будут переводиться в онлайн/оффлайн одновременно с тайником.

Можно сделать это и без customdata. К примеру, сделать в db таблицу соответствия story_id ключей и машин: db.script ... car_keys_by_sid = {} ... --' Формат заполнения: --' car_keys_by_sid[story_id машины] = story_id ключа После этого в bind_physic_object в use_callback прописать if self.object:clsid() == clsid.car_s then local sim = alife() if sim then local key_obj = sim:story_object(db.car_keys_by_sid[car_sid]) if self.object:object(key_obj:section_name()) ~= nil then --' У игрока есть ключ --' !!! Тут дописываем команду, впускающую игрока в машину else --' Ключа нет, игрока в машину не пускаем end Должно заработать, если знать команду, впускающую/не впускающую игрока в машину. Без цикла скорее всего не получится... Придётся делать так: в bind_stalker в функции update() пишем for k,v in pairs(db.zone_by_name) do if v:inside(self.object:position()) then --' Тут пишем действия, которые выполняются, если игрок попал в какой-то restrictor end end Не знаю, насколько быстро это выполняется. Вполне возможно, что это вызовет тормоза или даже вылет с ругнёй на стек. Добавлено через 23 мин.: Уберите customdata в этой (последней) секции Добавлено через 60 мин.: А вы найдите где-нибудь второй нож или бинокль, откройте инвентарь и нажмите на него двойным кликом. Будет вылет без лога.

Вызывается ли метод on_unregister() для людей и мутантов после вызова on_death()? Если нет, удаляются ли они движком из раздела "рейтинг" в PDA? И ещё: почему при перегрузке метода on_before_register() его вызов из движка убрали? Т.е. cse_alife_human_stalker.on_before_register(npc) больше не вызывается. Можно ли его вернуть обратно без вылетов?

Тупо добавить в db таблицу level_changers = {}. После этого в se_level_changer в on_register() поставить db.level_changers[self:name()] = self и соответственно на on_unregister() ставим db.level_changers[self.id] = nil. После этого можно вот таким циклом for k,v in pairs(db.level_changers) do if k == "имя объекта, для которого создаём отметку на карте" then level.map_add_object_spot_ser(v.id,"имя отметки на карте","Текст, которым метка подписывается в PDA") end end Хотя можно и без цикла обойтись - просто запрашивать значение (так быстрее): local name = "имя объекта, для которого создаём отметку на карте" if db.level_changers[name] ~= nil then level.map_add_object_spot_ser(db.level_changers[name].id,"имя отметки на карте","Текст, которым метка подписывается в PDA") end

- правильно, property_anomaly, насколько я знаю, для обхода используется только посхемно (см. функции add_to_binder в схемах). Если npc идёт независимо от схем (к примеру, переходит из смарта в смарт), то он и не подумает болты кидать. Вероятно, версия патча была меньше, чем 1.0004 (там эта схема вроде не вырезана) Кажется, я понял, что нужно сделать. Варианта решения проблемы 2: 1. Взять из схемы Red75 нахождение ближайшей к NPC аномалии и с помощью скрипта нанести hit этой аномалией, не нанося повреждений. Тогда NPC воспримет аномалию как опасность и кинет в неё болт. Вроде как это более простое решение. 2. Поглядеть, как в xr_danger к встроенному evaluator'у property_danger добавляется скриптовый (в самом конце это видно) и таким же способом подкорректировать поведение property_anomaly (опять же, с помощью функционала схемы anomaly_evader).

Не верится что-то. У меня бывает, что кто-то из группы Петрухи при штурме АТП стопорится перед аномалией и начинает бросать болты, при этом в аномалию чел не влетал. Даже если так, я думаю, можно как-то попробовать прописать аномалию в danger_objects неписю либо отключить фильтрацию аномалий как опасностей в xr_danger.script. Займусь этим, когда закончу с неписями, смартами и их переходом в онлайн/оффлайн и обратно.

Если разобраться, то можно выправить. Итак, по пунктам: 1. Нпс стоят и просто десятками эти болты сыплют - скорее всего потому, что мимо кидают. Это из-за каких-то косяков в state_mgr_direction они не могут выбрать направление. 2. Да еще вдобавок во время боя - опять же, в state_mgr во время действия anomaly_planner состояние устанавливается в combat. В оригинале я не видел проверку класса обекта look_object на "аномальность" - только IsStalker и IsMonster.

Только не {!black_screen}, а %!black_screen%. В фигурных скобках условия, между %% - действия.

В xr_motivator.script находим и удаляем вот это: Походу это какая-то движковая схема обхода аномалий, которую отключали только для зомби, а потом решили отключить вообще для всех из-за глюков с анимациями. Теоретически корявость рук и выбор направления можно исправить через правку state_mgr.script, практически пока сделал только выбор болта, если look_object - аномалия. Сообщение от модератора Cyclone Посты можно редактировать в течение 15 мин после написания. Даблпост используй только по прошествии этого времени.

Это не только в mob_* так делается. Так работают все схемы, использующие пути смартов. Принцип прописывания имён путей можно проследить в скрипте gulag_general.

У меня такой вопросик: Как функция can_switch_online() работает для смартов? Проверяет наличие NPC из смарта в онлайне или вызывает для них такую же функцию? Или как-то ещё?

Никак. В inventory_sect.ltx осталась возможность это делать (менять true на false и обратно для каждого слота), но её использование приводит к вылету без лога. У меня к вам такой вопросик: кто-нибкдь из читающих этот пост за всё время игры когда-нибудь видел NPC, кидающих болты по аномалиям? А то у меня вдруг обнаружилась такая фича но работает немного коряво. Корявость в том, что у NPC немного руки дрожат и кидают они их не совсем туда, куда надо. А так задумка очень неплохая.

Экстренный респавн скорее всего будет работать только если есть серверный объект респавнера, потому что это функция function se_respawn:spawn() Я вот думаю, может ли заспавниться объект класса RESPAWN? То есть, могут ли респавны создаваться динамически? Если да, то это и есть причина.

То ли это у меня глюки, то ли у движка игры, но люди всё равно появляются. Я убрал из all.spawn все секции, у которых section_name = respawn , а также ссылки на них (в смартах. Но это не помогло. Сейчас ищу во всех файлах вызовы alife:create(), похоже это единственный вариант В том-то и дело, что respawn от АМК (в основном это тушканчики и прочая живность) я не трогал, да и спавнятся в основном люди.

А если я убираю респавны вообще и прописываю всем смартам в поле communities нужные группировки - что происходит? Откуда они все спавнятся? Может это в движке зашито?

o_0 Сейчас без причин стал вылетать с ругнёй на "Error in error handling". Кто знает, что это за ерунда такая? Странно, что без причин. Такими темпами он скоро напишет, что скрипты заселены аномалиями... // Присылать надо полный лог, а не "огрызок" из него... Министр.

Разве этот класс вообще используется в ТЧ?

Ну вот у меня с add_restrictions было так: Пишу в amk_anoms в биндере аномалий в функции net_spawn() вот такой код: for k,v in pairs(db.creactures) do v:add_restrictions("", self.object:name()) end (предварительно сделал, чтобы вертолёты в этот список не добавлялись) После этого в xr_motivator тоже в net_spawn() пишу for k,v in pairs(db.anomaly_by_name) do self.object:add_restrictions("", k) end (при условии, что db.anomaly_by_name[anomaly:name()] = anomaly, т.е там хранятся аномалии, которые в онлайне) Результат - вылет с ругнёй на стек. В state_mgr не нашёл ни одной функции, которая вызывала бы сама себя, поэтому и подумал насчёт одновременности.

Не обязательно "сама себя". Насколько я понял, достаточно, чтобы функция многократно вызывалась за короткий промежуток времени не важно откуда. Такое я случайно спровоцировал, когда эксперементировал с добавлением restrictor'ов, хотя никакой рекурсии не было. Сначала я думал, что если игра ругалась на state_mgr, то в нём собака и зарыта, но вчера сам видел, как перед вылетом npc начинают то исчезать, то появляться снова - т.е. скакать из онлайна в оффлайн и обратно. Учитывая, что can_switch_* вызывается раз в секунду, то скорее всего такие глюки при большом скоплении npc именно из-за этого. А это уже тянет за собой частый вызов net_spawn() и net_destroy() для биндера, к которому как раз "приделан" state_mgr, вот мы и имеем то, что имеем...

Хочу избавиться от вылетов из-за переполнения стека, которое иногда возникает, если в онлайне много NPC. На одной из предыдущих страниц мне подсказали, что надо копать в сторону функций can_switch_*() и по возможности заменить их переменными, вроде как количество вылеты из-за переполнения стека должны если не исчезнуть, то хотя бы уменьшиться.