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

Полтергейст

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

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

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

  • AMKoin

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

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

  1. В шапке темы битые ссылки на распаковщики архивов игры, поправьте плз. Не работает первая ссылка и ссылка на Universal Extractor.
  2. @Expropriator, в существующих проектах модифицированных движков от ТЧ такие исправления есть, только кроме них там ещё много всякого нового, не всем нужного.
  3. @Expropriator По существу же понятно о чём я спросил? Ищу проект модификации движка ТЧ, где из изменений есть только исправление вылетов, зависаний, фризов, глюков рендера и UI. Без добавления нового функционала, без геймплейных нововведений, без экспорта новых функций (кроме тех, которые были экспортированы в ЧН и ЗП). Наиболее похожий это OpenXRay, но он на движке ЗП. На движке ТЧ нет таких проектов?
  4. @Expropriator, не очень понял это сообщение. Разве в оригинальном (релизном) движке нет багов?
  5. Есть ли среди проектов по изменению движка такой, где только исправляются баги того функционала, который есть, без добавления нового? Такой, чтобы на выходе был обычный "чистый" движок с исправлением вылетов, подвисаий, визуальных дефектов в UI и т.п.
  6. @AndreySol, я про таблицы значений clsid, на которых эти функции работают. Неудобно, когда они разбросаны по куче разных файлов. Лучше иметь одну большую таблицу, где всё это собрано.
  7. @AndreySol, данные, необходимые для любых функций классификации (IsMonster и тому подобных). Туда же можно сохранить значение stype (modules.stype_чтонибудь). Да много всего можно там хранить, чтобы каждый раз не делать свою табличку для классификации.
  8. А никто ещё не переписывал скрипт class_registrator так, чтобы в нем хранились все таблицы с данными для регистрации классов и классификации объектов? В оригинале данные просто используются один раз при старте игры и не хранятся нигде, что неудобно.
  9. @Dennis_Chikin, могу точно сказать, что по smart terrain есть ещё кучка движковых граблей. Чтобы NPC шёл в смарт, надо чтобы все эти проверки вообще вызывались движком. А это происходит не всегда. ЕМНИП, для NPC должен быть выставлен флаг Interactive, без которого всё это работать не будет. Как минимум, в оффлайне. Так же, надо чтобы can_choose_alife_tasks было выставлено в true. По умолчанию это так, и в оригинале оно нигде не меняется. В модах может и по-другому быть. Например, я таким образом отключал поиск смартов для "эксклюзивных" NPC, чтобы задавать им id смарта в явном в
  10. Полтергейст

    Новости игр

    После выхода игры Pokemon GO и шумихи вокруг неё появилась одна "идея на миллион"... ну вы поняли. Поиск по фразе "Stalker GO" показал, что это пришло в голову не только мне (оно и понятно). Пока не видно, чтобы это где-то обсуждалось серьёзнее восторженных ожиданий, но я думаю что такую возможность не упустят и такая игра будет создана. Вопрос у меня такой. Имеет ли смысл сейчас создавать тему об игре, создание которой скорее всего ещё даже не начато, и которая неизвестно когда выйдет? И если это кому-то интересно, то в каком разделе создавать такую тему?
  11. Не обязательно "в оффлайне". Просто проверяется, дошёл ли. В онлайне это тоже можно наблюдать - сначала идут медленно (работает action_alife_planner), а потом с определённого расстояния немного меняет маршрут и идёт быстрее. Потому что в этот момент задействуется логика, скрипты, состояния в state_mgr.На запрет идти к месту работы в оффлайне параметр job_position_treshold вообще никак не влияет.Насчёт can_choose_alife_tasks надо смотреть исходники движка. Тоже не совсем верно. В оригинальном ТЧ идут к первой точке пути, от неё же и считается расстояние, из которого делается вывод - дошёл ил
  12. Не заворачивать, а преобразовывать. Все данные из таблицы работ перекинуть в объект, потом получить имя пути и сам путь, и сохранить в объект. В класс можно перенести целую кучу методов, отвечающих за всякие проверки и назначения работ. Для человекочитаемости это точно пойдёт на пользу. Разве? По-моему смысл другой. В оригинале это расстояние, ближе которого в онлайне персонажу устанавливается логика (setup_logic_что-то-там). Дальше этого расстояния логика не работает. Полезность - сомнительна. Некоторые схемы могут подглючивать, если они активируются далеко от первой точки пути.
  13. Мой вариант (одна функция, работающая и в online, и в offline). function has_alife_info(info_id) if not (sim and info_id and info_id:len() > 0) then -- ругаемся в лог end if actor then -- online return actor:has_info(info_id) end -- offline return sim:has_info(0, info_id) end Для избавления от лишних проверок сделать немного по-другому - написать 2 разные функции для online и offline проверке, и в биндере игрока написать что-то такое _G.has_alife_info = has_info_online -- пишем в net_spawn _G.has_alife_info = has_info_o
  14. Так я об этом и пишу. Если специально не создавать на каждый чих новый gulag type с собственным condlist'ом (вместо использования логики там, где это возможно), то большой простыни из кучи секций и длинных condlist'ов не будет. И как раз получится, что вместо простыней из load_states станет достуен condlist. В смысле, показать как должны выглядеть конфиги и описание работ?
  15. Упрощение - в наглядности. С номерными state не сразу понятно, что они значат, надо их для каждой работы прописывать, надо искать, где и как они считаются. К тому же все эти 'if type == "gulag_1" then ... elseif type == "gulag_2" then' выглядят не очень красиво. А так сразу видно, какие работы и при каких условиях доступны, всё собрано в одном конфиге. Нет разделения на несколько смартов. Если сделать, чтобы работало и так и так, то переделывать не обязательно. Разве что оставить на будущее парочку переменных, которыми при необходимости можно отключить старый способ обработки. Раб
  16. Для отдельных NPC порядок посещения смартов определяется в секции smart_terrains из customdata. На него эти правки вообще не влияют. Для всех обитателей смарта такого механизма и в оригинале не было. Можно было только запретить всем идти в указанный смарт, но это и после правок можно делать. Просто надо будет писать конфиг так, чтобы при определённом условии все типы работ блокировались, и все с них выгонялись.
  17. Потому что вместо них можно использовать несколько gulag type. В конфиге это будет выглядеть примерно так: Вместо использования состояний, тип esc_fabrika_bandit разделён на esc_fabrika_bandit_normal и esc_fabrika_bandit_alarm. А general_lager здесь для того, чтобы не делать отдельный несюжетный смарт esc2_st_fabric.
  18. Я так понимаю, копия нужна для защиты оригинала от изменения. После вызова obj:command( act, false) действие добавляется в очередь. А вот какие странности будут, если попытаться изменить его после добавление в очередь local new_act = action_first(obj, что-то_там) new_act:set_action(что-то_ещё) - можно только догадываться. И кстати переменную act лучше переименовать, т.к. есть одноимённый экспортированный класс.
  19. Это и будет то, что имеется, просто методы будут вызываться не из смарта, а из самой работы. Один раз при загрузке работ преобразовывать их из таблиц в объекты, объединяя при этом работы с одинаковой секцией логики в один объект. Все эти объекты занести в индексированную таблицу (которая self.Job) и в хеш-таблицу, в которой ключом будет имя секции. Вот, собственно, и всё. А что их учитывать? Для каждого типа работ сделать промежуточный объект, в котором будет храниться вся инфа о типе работ (имя ltx и ссылка на него, ссылка на gulag_***.script, текущий state), и пропускать все обра
  20. При правильном подходе толк будет. Во-первых, вместо хранения кучи таблиц, описывающих работы с одинаковой логикой, достаточно всего один раз их преобразовать в объекты. Так, чтобы на одну секцию логики приходился только один объект работы. В этих же объектах хранить табличку NPC, назначенных на эту работу. Сокращение количества записей о работах может увеличить производительность. Да и на каждый чих дёргать работы из таблицы уже не нужно будет. Во-вторых, в такой класс можно перенести все методы, в которых взаимодействует только одна работа и один NPC. Это не так уж мало.Это повысит нагляд
  21. Касательно допиливания smart_terrain'ов напильником. Я так думаю, лучше все работы завернуть в класс с соответствующими методами. Т.е. чтобы каждая работа была не табличкой, а объектом класса. Для объединения работ с одним "gulag type" создать ещё один класс, в который засунуть проверку условий приёма NPC и всякие атавизмы типа номерных состояний.
  22. Я делаю так - в биндере на этапе reinit принудительно очищаю все запомненные объекты через enable_memory_object, и отключаю неписям зрения (enable_vision). Включаю обратно только после того, как игра загрузилась полностью (т.е. игрок уже не видит экран загрузки). Помимо этого прописал в enemy_callback и схеме xr_danger игнорирование всех врагов и опасностей до того, как игра загрузится. Частично это помогло. Во всяком случае почти исчезли ситуации, когда никем не обнаруженный игрок сохранился где-то спрятавшись за углом, а потом загрузился и все сразу его заметили. Насколько это влияет на эт
  23. Похоже на какие-то косяки в реализации скрипта xr_danger. Evaluator для stalker_ids.property_danger должен возвращать false, если источником опасности является сам объект, или он далеко, или опасность была давно. Помимо этого можно для "просроченных" или неуместных опасностей дописать удаление объекта из памяти (через enable_memory_object). В оригинале, насколько я помню, такое удаление происходит только для игнорируемых врагов. Хотя определять тип звука по ogg-комментарию, а не по событию, вызывающему этот звук - это как-то... странно.
  24. Это движковый вылет, я его уже описывал. Вылечить без ковыряния движка нельзя. Просто надо учитывать, что сочетание anim.free и move.crouch недопустимо.
  25. Я бы проверил на предмет того, откуда берётся gulag.name. Если НЕ из strn:name() (где strn - объект smart_terrain), то тогда всё понятно. Вероятно, туда каким-то образом попадает type вместо name.

AMK-Team.ru

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