Полтергейст

Выкладываю свой код по частям. 1) Фрагмент из биндера NPC (xr_motivator) (в функции net_spawn сразу осле установки коллбеков)

Artos В том и странность: функция remove_all_restrictions виснет, но если удалять отдельно каждый рестриктор через alife():remove_in_restriction(...), то всё нормально. Для клиентского объекта функция add_restrictions тоже виснет, в то время, как alife():add_in_restriction(...) работает как надо. KD87 Дело в том, что удаление рестрикторов я делаю в функции net_destroy. Если я вызову remove_all_restrictions(), то ничего не произойдёт - игра просто напишет, что объект, для которого эта функция вызвана, не найден.

Ранг добавляется за хождение по smart_terrain'ам. В AMK помимо этого в оффлайн боях добавляется за победу.

KD87 У меня чистая игра 1.0006, могу ли я использовать parse_stalker_packet из amk.script для разбора пакетов? В AMK в se_stalker после чтения/записи онлайн работ идёт чтение/запись числа, а в чистой 1.0006 вместо них идёт 2 bool значения. Вот сама функция:

Вопрос по net-пакетам. По какому смещению находится таблица in-рестрикторов для класса cse_alife_human_stalker?

Флуд почищен, список причин вылетов обновлён. Вчера столкнулся с непонятным вылетом без лога, причина скорее всего в рестрикторах. Дело в том, что я пытался прописать всем NPC (людям) в рестрикторы все аномалии, находящиеся на этом уровне, с помощью функции alife():add_in_restriction(npc, restrictor_id). При net_destroy, соответственно, удалял их с помощью alife():remove_in_restriction(npc, restrictor_id). Также был учтён баг с удалением рестриктора, прописанного кому-то. При самой игре вылета нет, но если сохраниться возле какого-нибудь NPC и потом загрузиться, то вылет был. Возможно, из-за того, что была попытка прописать всё это в рестрикторы дважды, либо весь этот список как-то неправильно сохраняется.

Это только начальное направление взгляда при спавне. Как-то можно это сделать через net_packet'ы, но проще воспользоваться функцией set_desited_direction(вектор_направления_взгляда). Вот только не знаю, относительно чего этот вектор задаётся - посмотри в логических схемах (скриптах) или в том же state_mgr примеры использования.

По поводу коллбеков: 1. Коллбеки типа callback.sound перехватывают звуки только от сталкеров, монстров, игрока и детекторов. 2. Есть кое-какие предположения насчет коллбеков action_animation, action_movement, action_object, action_particle, action_sound и action_watch. Если посмотреть в lua_help на описание функций set_action() из класса entity_action, то становится понятно, что они нужны для отслеживания действий монстров. Для остальных объектов они, скорее всего, работать не будут. Вот только нет примеров использования.

Исправил - всё равно не работает. Судя по тому, что выводилось в лог, коллбек "воспринимает" только сталкеров, монстров и (почему-то) детектор игрока. Поэтому такой способ определения аномалий, к сожалению, не годится.

Сегодня пытался сделать обход аномалий с помощью отслеживания звуков, но по какой-то причине аномалии не добавляются в рестрикторы... Почти весь код реализован в одной функции. Формат таблицы self.anomaly: self.anomaly[anom_id] = name anom_id - id аномалии, name - её имя.

Вылет без лога может случаиться, если вызвать метод update() из серверного объекта мёртвого NPC. Скорее всего для brain():update() будет то же самое, но надо будет ещё потестировать для более точных данных. Ещё один источник проблем - функции cse_alife_smart_zone.register_npc() и cse_alife_smart_zone.unregister_npc(). Причём вылеты от них бывают не при каждом вызове, а "плавающие" (через раз). В смартах они не используются (видимо, именно поэтому разрабы их убрали), но на всякий случай оставлю это тут.

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

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

В дополнение к таблице соответствия серверных и клиентских классов (пост №29): в файле xr_game.dll ближе к концу есть упоминания соответствий серверных и клиентских классов (причём внутри движка имена этих классов могут отличаться от тех, что экспортированы в LUA). Кроме этого, классы делятся на парные и непарные. Непарные остаются без соответстия, т.е. они "чисто серверные" или "чисто клиентские". Если я правильно понял, непарные классы наследованы от неэкспортируемого класса CObjectItemSingle, парные - от CObjectItemClientServer. Вырезка из файла xr_game.dll (убраны нечитаемые символы) под спойлером.

Да, небольшое дополнение: после установки коллбеков (которые в update) надо присвоить self.callbackset = true.

Недавно в "ковырялке" кто-то писал про срабатывание коллбеков на выкладывание/взятие предмета при переходах между локациями. Нашёл решение (теоретически, на практике пока не проверялось) этой проблемы. В некоторых местах разрабы ставили проверку на "чёрный экран", т.е. видит ли игрок что-нибудь, или же ещё идёт загрузка. Чтобы коллбеки вызывались только ПОСЛЕ появления первого кадра игры, надо сделать в bind_stalker.script такие изменения: 1. Добавляем переменную, которая показывает, установлены ли коллбеки function actor_binder:__init (obj) super(obj) ... self.callbackset = false ... end 2. Переносим в функцию update() все коллбеки, которые не должны вызываться до окончания загрузки. function actor_binder:update(delta) object_binder.update(self, delta) ... if device().precache_frame >1 then return end if self.callbackset == false then self.object:set_callback(callback.on_item_take, self.on_item_take, self) self.object:set_callback(callback.on_item_drop, self.on_item_drop, self) self.object:set_callback(callback.trade_sell_buy_item, self.on_trade, self) self.object:set_callback(callback.take_item_from_box, self.take_item_from_box, self) self.object:set_callback(callback.article_info, self.article_callback, self) end ... 3. В функции reinit должны остаться все остальные коллбеки: self.object:set_callback(callback.inventory_info, self.info_callback, self) self.object:set_callback(callback.task_state, self.task_callback, self) self.object:set_callback(callback.level_border_enter, self.level_border_enter, self) self.object:set_callback(callback.level_border_exit, self.level_border_exit, self)

Что под этим понимается? Если имеется в виду определение освещённости предмета или NPC - нет. Иначе разрабы не стали бы заморачиваться с sr_light-рестрикторами. Есть только параметры, регулирующие "зрение" NPC, но выполняется это всё внутри движка и в LUA не экспортировано.

Да.

Какого бинокля? Есть wpn_binoc, ему эти строки вроде бы без разницы (можешь закомментировать и проверить). Если binocular_a, то эти строки необходимы для отыгрыша анимации (например, в самом начале когда Петруха смотрит в бинокль на бандитов).

Так это нужно прописывать не в update, а в функцию, вызываемую при попадании (hit_callback). Тогда никаих лишних переменных вводить не придётся.

Сделать-то можно для какого-то данного конкретного NPC. Но делать таким способом коллбек для всех (!!) NPC не очень разумно - это просто трата ресурсов. Причём, когда я в death_manager полностью убрал спавн и удаление предметов (кроме фонариков, гитар, болтов) ничего подобного не наблюдалось: после смерти НПС патроны всегда оставались при нем. Так при смерти НПС оружие не удаляется. Или как?

По идее, в скриптах есть только 2 коллбека на смерть NPC: клиентский (xr_motivator.script, функция death_callback) и серверный (se_stalker.script, функция on_death). Тот скрипт (если это скрипт делает), который удаляет патроны, должен быть прописан в одной из них. Если это не скрипт, то какой-то баг движка. Такая вот расплата за бесконечные патроны у NPC.

Найди коллбек на использование предметов в bind_stalker.script и пропиши туда спавн использованной аптечки при использовании ещё не использованной. Можно при смерти НПС удалить его и на том месте заспавнить обычный физический объект с моделью этого НПС. Но тогда нельзя будет рыться по рюкзакам убитых + удаление и спавн могут быть заметны.

Их нет, но обращения к ним идут при запуске приложений, использующих Direct3D. Отследить можно программой Sysinternals Registry Monitor. В этом и суть. Увеличение FPS налицо. Если во время этого теста сделать PrintScreen, то можно увидеть, что кубик правильно отображается. Просто для нашего глаза такое движение слишком быстрое, вот мы и не успеваем ничего разглядеть. На играх с бОльшим количеством объектов увеличение FPS должно быть не таким заметным. Для того и выложил твик, чтобы проверить. FlipNoVsync - включает одноименную возможность ("капс") видеокарты, если есть. Проверить её наличие можно утилитой DXCapsViewer. FewVertices - получен эксперементально + кто-то уже выкладывал его на одном форуме по видеокартам. В принципе, можно обойтись одним FlipNoVsync, если не доверяете эксперементально полученным твикам.

Если не умеешь или не знаешь что и где править - конечно лучше. Я неоднократно пользовался некоторыми вот такими своими твиками, которые получал эксперементально - всё работает. Разве что во время эксперементов могут быть проблемы, но непроверенные твики я не выкладываю. Я подобного и не утверждаю. Нужно понимать, что прирост в производительности за счёт твиков реестра достигается либо отключением чего-то ненужного (и, как следствие, высвобождением ресурсов), либо небольшой потерей качества. Если эта потеря будет незаметна для глаза - почему бы и нет? Direct3D не является компонентом, без которого загрузка системы невозможна. Расположение параметров твика известно, их в любой момент можно удалить (первоначально их там нет).