Перейти к контенту

Полтергейст

Опытные
  • Число публикаций

    318
  • Регистрация

  • Последнее посещение

  • AMKoin

    30 [Подарить AMKoin]

Весь контент пользователя Полтергейст

  1. Обнаружил в игре такой баг (проверял на патче 1.0006): при спавне какого-нибудь объекта скриптом, функция on_register серверного объекта может вызваться дважды. Этим и объясняются "странности" с параметром m_smart_terrain_id: в том примере объект регистрировался в каком-то смарте до второго вызова on_register, если ему вызовом :can_choose_alife_tasks(false) не было запрещено это сделать. Обходить баг и выводить в консоль имена объектов, которые вызывают on_register дважды, можно как-то так (пример для se_monster):
  2. Недавно столкнулся с одной неприятной особенностью параметра m_smart_terrain_id, который есть у всех классов, наследуемых от cse_alife_monster_abstract. Я пробовал переделать скрипт smart_terrain.script так, чтобы регистрировать в них эксклюзивных NPC с помощью присвоения m_smart_terrain_id и последующего вызова register_npc из смарта. Появилась куча проблем с двойными регистрациями: несмотря на то, что я непосредственно перед регистрацией в смарт какого-нибудь NPC отключаю ему автопоиск смартов вызовом brain():can_choose_alife_tasks(false), он каким-то образом уже оказывается зарегистрированным в другом смарте ещё до этого вызова. А причина оказалась простой: у NPC, только что заспавненных скриптом, при запросе значения из этого параметра вызывается обновление планировщика brain():update(). Даже если я использую функцию smart_terrain_id() для запроса значения - тот же результат. Пример:
  3. Пробовал создавать артефакты на клиентском классе CBlackGraviArtefact (имя скриптового сета - AF_BGRAV) и столкнулся с неприятной проблемой: каждый раз на месте перехода арта в онлайн отыгрывается зацикленный партикл anomaly\galantine, отыгрыш которого вшит в движок (это можно увидеть даже "блокнотом"). Кто-нибудь с этим сталкивался? Этот скриптовый сет в оригинальной игре нигде не используется, возможно в билдах есть.
  4. Проверку делал в функции update() биндера NPC.
  5. Столкнулся с одним неприятным багом, скорее всего движковым. Суть проблемы: иногда свойство stalker_ids.property_enemy принимает значение true (если запрашивать его через property_storage), но при этом метод best_enemy() возвращает nil, даже если выключить enemy_callback (проверку по combat_ignore). Как такое вообще может быть?
  6. Есть ли поддержка чтения/записи свойств, уникальных для классов cse_alife_item_document и cse_alife_item_pda?
  7. В ТЧ есть функция game_object.invulnerable(), которая не внесена в lua_help. Работает и на чтение, и на изменение - только что проверял.
  8. Сохранение/загрузка реализованы вот таким кодом: function se_zone_anom:STATE_Write(packet) cse_anomalous_zone.STATE_Write(self, packet) packet:w_u16(self.m_restrictor_id) end function se_zone_anom:STATE_Read( packet, size ) cse_anomalous_zone.STATE_Read( self, packet, size ) self.m_restrictor_id = packet:r_u16() end Так у второй аномалии не скриптовый класс, поэтому класс se_zone_anom её вообще не касается.
  9. Artos Не будет. Я же написал - self.m_restrictor_id сохраняется и загружается, то есть после сохранения/загрузки или перехода в оффлайн повтороного спавна не будет. Двухслойным назвал из-за того, что планировалось сделать, чтобы аномалия была внутри этого рестриктора. То есть мне нужно разобрать net_packet'ы и заполнить эту таблицу? В таком случае, можно ли просто скопировать их с аномалии?
  10. Вчера пробовал сделать "двухслойные" аномалии и столкнулся с одной непонятной проблемой: только что заспавненная аномалия не реагирует ни на кого (ни на игрока, ни на болты). Как делал: 1. Сначала создал в конфигах вот такую секцию
  11. Artos В том-то и дело, что слышат, просто никак не реагируют. Собственно, я только из-за этого и взялся за эту (бредовую?) затею, т.к. думаю, что разрабы не зря включили детекторы в список объектов, на звук от которых срабатывает callback.sound.
  12. Чтобы подавал звук, как у ГГ. Анимации самих НПС есть в оригинале (используются в квесте с Кругловым), только их нужно запускать скриптами.
  13. Недавно у меня возник вопрос про активацию предметов (выбор активного) у npc. К примеру, оружие можно выбирать по слотам или напрямую через set_item(), а фонарик через enable_attachable_item(). Каким способом можно выбрать детектор (так, чтобы он работал, а не просто висел)? Пробовал через set_item - не помогло. А слот для детектора, насколько я знаю, есть только у игрока.
  14. Ндр А откуда такие выводы? Скрипты (в особенности xr_motivator) оригинальные? Возможно, после смерти npc по какой-то причине продолжает вызываться hit_callback при попадании. При вызове death_callback(...) все коллбеки должны отключаться (как в оригинале). Снайпер с пулеметом, в названиях костей опечаток нет? Анимация idle для модели прописана? P.s. про функции сохранения/загрузки читай в справочнике функций и классов (конкретно - класс object_binder, классы cse_alife_*)
  15. Снайпер с пулеметом Это битые сохранения. Ошибки ищите в функциях STATE_Read/STATE_Write для серверных объектов, save/load в биндерах клиентских объектов, а также в функциях работы с пакетами (в скриптах того мода, который установлен). Могут быть подобные вылеты, связанные с попытками задать недопустимые соответствия серверных/клиентских классов (таблицу возможных соответствий для ТЧ я выложил в справочнике по функциям и классам) в class_registrator.script. В таких случаях возможно даже зависание игры, естественно, без лога. Кстати, об оружии. Нельзя прописывать наличие подствольников оружию, у которого Class = WP_LR300 это может быть причиной порчи сохранений. То же самое касается всего оружия, у которого скриптовый серверный класс основан на классе, отличном от cse_alife_item_weapon_magazined_w_gl.
  16. Вылет без лога случается, если установить состояние тела равным move.crouch и ментальное состояние anim.free. Например, вот такой код npc:set_mental_state(anim.free) npc:set_body_state(move.crouch) вызовет вылет без лога. В скриптах state_mgr оригинальной игры (ТЧ) установка этой комбинации состояний запрещена, поэтому при установке состояний через state_mgr.set_state(...) такого вылета не может произойти. Но если состояние устанавливается напрямую (как показано выше) или запрет в state_mgr снят, то вылет будет.
  17. malandrinus Сейчас ещё раз перепроверил - всё работает, никакого вылета. Возможно, была какая-то другая причина - ошибочка вышла. Оффлайн обновления тоже проверял ещё раз - нормально работают, как и написал. Обновляются через определённый промежуток времени. Это было бы полезно для скриптов типа amk_offline_alife, чтобы обновления объектов вызывались самими объектами, а не из обновления биндера игрока. И ещё. Скриптовый сет для группы (online_offline_group) может быть перегружен (только делать это нужно функцией c_register, а не cs_register). Только что проверил и заспавнил один такой объект - вылетов, зависаний и прочих ошибок замечено не было. В функции on_before_register() скриптового класса поставил вывод в лог - сообщение успешно вывелось.
  18. Real Wolf Попробуйте сразу после вызова функции добавления рестрикторов вывести какое-нибудь сообщение в лог (не важно какое). Если выводится - значит, что-то неправильно добавляете. P.S. рестриктор-то один добавляете или несколько в цикле?
  19. Artos, Так я о движковой пишу. Если установить enemy_callback (пример использования есть в xr_combat_ignore), который всегда возвращает false, то движковая схема (stalker_ids.action_combat_planner) должна никого не воспринимать как врагов. Однако NPC продолжают стрелять. В xr_danger тоже сделал, чтобы возвращало false - не помогло.
  20. Кто-нибудь может мне объяснить, почему NPC продолжают стрелять, если установлен enemy_callback, который всегда возвращает false? При проверке опасностей в xr_danger тоже возвращается false. Что я делаю не так?
  21. К слову об оффлайне. Оффлайновые обновления (те, что от планировщика) мне удалось заставить заработать. Для этого я всего лишь заменил вызов self:brain():update() на self:update() и перегрузил последнюю функцию, ничего не добавляя (осталось только cse_alife_*.update()). Не уверен, что последнее на что-то повлияло. После всех этих изменений игра вылетела, ругаясь на отсутствие некоторых параметров в m_person.ltx, проблему решил установкой параметра Scheduled = off. После этого оффлайн-обновления заработали.
  22. Заметил у NPC некоторые странности с переключением состояний. Если я ставлю им через set_state какое-нибудь состояние (например, анимацию раненого) после определённого события (попадания например), то ничего не происходит, даже если устанавливать его на каждом update. А вот если просто установить это состояние в update без проверки условий (то есть, чтобы анимация отыгрывалась всегда), то всё нормально. Хотя set_state вызывается в обоих случаях, т.е. в первом случае условия смены состояния выполняются. Кто-нибудь может подсказать, что я делаю неправильно?
  23. ColR_iT position_threshold не влияет на то, будет ли NPC искать себе работу, а задаёт расстояние, при котором NPC считается "приступившим к выполнению обязанностей". Поиск работы происходит ещё до вызова register_npc в смарте. info_rest отсекает реакцию на события, происходящие снаружи заданного рестриктора. По-хорошему их следовало бы разделить также на in и out, но почему-то этого не сделали. Насколько я понял, параметры squad и group определяют, будет ли NPC вообще зарегистрирован в смарте. Сравнивается с соотв. параметрами самого NPC, но смысла в этом я не вижу никакого. online - попытка запрета (ИМХО - также бессмысленная) перехода в оффлайн.
  24. Так, с set_state вроде разобрался - приходится каждый раз задавать указанное состояние в update самого NPC. Пробовал ставить состояние единожды, через hit_callback - никакого результата. Чего только не делал, даже запрещал обновление state_mgr, если нужное состояние уже установлено. Ничего не помогает. Неужели совсем никак нельзя сделать так, чтобы состояние не сбрасылалось, без вмешательства в эвалуаторы?

AMK-Team.ru

×
×
  • Создать...