Полтергейст

В шапке темы битые ссылки на распаковщики архивов игры, поправьте плз. Не работает первая ссылка и ссылка на Universal Extractor.

@Expropriator, в существующих проектах модифицированных движков от ТЧ такие исправления есть, только кроме них там ещё много всякого нового, не всем нужного.

@Expropriator По существу же понятно о чём я спросил? Ищу проект модификации движка ТЧ, где из изменений есть только исправление вылетов, зависаний, фризов, глюков рендера и UI. Без добавления нового функционала, без геймплейных нововведений, без экспорта новых функций (кроме тех, которые были экспортированы в ЧН и ЗП). Наиболее похожий это OpenXRay, но он на движке ЗП. На движке ТЧ нет таких проектов?

@Expropriator, не очень понял это сообщение. Разве в оригинальном (релизном) движке нет багов?

Есть ли среди проектов по изменению движка такой, где только исправляются баги того функционала, который есть, без добавления нового? Такой, чтобы на выходе был обычный "чистый" движок с исправлением вылетов, подвисаий, визуальных дефектов в UI и т.п.

@AndreySol, я про таблицы значений clsid, на которых эти функции работают. Неудобно, когда они разбросаны по куче разных файлов. Лучше иметь одну большую таблицу, где всё это собрано.

@AndreySol, данные, необходимые для любых функций классификации (IsMonster и тому подобных). Туда же можно сохранить значение stype (modules.stype_чтонибудь). Да много всего можно там хранить, чтобы каждый раз не делать свою табличку для классификации.

А никто ещё не переписывал скрипт class_registrator так, чтобы в нем хранились все таблицы с данными для регистрации классов и классификации объектов? В оригинале данные просто используются один раз при старте игры и не хранятся нигде, что неудобно.

@Dennis_Chikin, могу точно сказать, что по smart terrain есть ещё кучка движковых граблей. Чтобы NPC шёл в смарт, надо чтобы все эти проверки вообще вызывались движком. А это происходит не всегда. ЕМНИП, для NPC должен быть выставлен флаг Interactive, без которого всё это работать не будет. Как минимум, в оффлайне. Так же, надо чтобы can_choose_alife_tasks было выставлено в true. По умолчанию это так, и в оригинале оно нигде не меняется. В модах может и по-другому быть. Например, я таким образом отключал поиск смартов для "эксклюзивных" NPC, чтобы задавать им id смарта в явном виде. И да, алгоритм расчёта предпочтительности смарта на основе его заполненности - это полная шляпа. Должно учитываться как минимум расстояние (ближе - лучше). И не хватает подсчёта "населения" отдельно по каждой группировке.

После выхода игры Pokemon GO и шумихи вокруг неё появилась одна "идея на миллион"... ну вы поняли. Поиск по фразе "Stalker GO" показал, что это пришло в голову не только мне (оно и понятно). Пока не видно, чтобы это где-то обсуждалось серьёзнее восторженных ожиданий, но я думаю что такую возможность не упустят и такая игра будет создана. Вопрос у меня такой. Имеет ли смысл сейчас создавать тему об игре, создание которой скорее всего ещё даже не начато, и которая неизвестно когда выйдет? И если это кому-то интересно, то в каком разделе создавать такую тему?

Не обязательно "в оффлайне". Просто проверяется, дошёл ли. В онлайне это тоже можно наблюдать - сначала идут медленно (работает action_alife_planner), а потом с определённого расстояния немного меняет маршрут и идёт быстрее. Потому что в этот момент задействуется логика, скрипты, состояния в state_mgr.На запрет идти к месту работы в оффлайне параметр job_position_treshold вообще никак не влияет.Насчёт can_choose_alife_tasks надо смотреть исходники движка. Тоже не совсем верно. В оригинальном ТЧ идут к первой точке пути, от неё же и считается расстояние, из которого делается вывод - дошёл или не дошёл. Хотя при определённых переделках скрипта можно посылать их не в первую точку, а последовательно в 1, 2, 3 и т.д.

Не заворачивать, а преобразовывать. Все данные из таблицы работ перекинуть в объект, потом получить имя пути и сам путь, и сохранить в объект. В класс можно перенести целую кучу методов, отвечающих за всякие проверки и назначения работ. Для человекочитаемости это точно пойдёт на пользу. Разве? По-моему смысл другой. В оригинале это расстояние, ближе которого в онлайне персонажу устанавливается логика (setup_logic_что-то-там). Дальше этого расстояния логика не работает. Полезность - сомнительна. Некоторые схемы могут подглючивать, если они активируются далеко от первой точки пути. Но это проблема или реализации этих схем, или криво написанной логики. То, что отметка о начале работы (beginJob) устанавливается, можно не принимать во внимание. Просто устанавливать её при достижении первой точке пути и не заморачиваться. Запретить NPC идти к месту "работы" можно или установкой object_flags, или вызовом can_choose_alife_tasks(false) (но не абы-как и абы-где), или установкой ему нулевой скорости передвижения в оффлайне. Position_treshold не влияет ни на что из этого. Условия - это predicate что ли? Ну разве что для тех случаев, когда надо вытеснять кого-то из смарта, когда кто-то другой занял работы "с условиями"... но всё равно не вижу в этом смысла. Такой параметр больше подходит для самих работ, чтобы можно было назначить нескольким NPC одну и ту же логику, не создавая для этого несколько работ (это одна из причин для хранения работ в виде объектов, а не таблиц). Что читаются плохо - это дело привычки. Да и всё равно от них не уйти уже, используются везде. Задавать явно возможность остаётся - написать {=вызов_функции} и в самой функции уже расписывать все подробности.

Мой вариант (одна функция, работающая и в 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_offline -- в net_destroy

Так я об этом и пишу. Если специально не создавать на каждый чих новый gulag type с собственным condlist'ом (вместо использования логики там, где это возможно), то большой простыни из кучи секций и длинных condlist'ов не будет. И как раз получится, что вместо простыней из load_states станет достуен condlist. В смысле, показать как должны выглядеть конфиги и описание работ?

Упрощение - в наглядности. С номерными state не сразу понятно, что они значат, надо их для каждой работы прописывать, надо искать, где и как они считаются. К тому же все эти 'if type == "gulag_1" then ... elseif type == "gulag_2" then' выглядят не очень красиво. А так сразу видно, какие работы и при каких условиях доступны, всё собрано в одном конфиге. Нет разделения на несколько смартов. Если сделать, чтобы работало и так и так, то переделывать не обязательно. Разве что оставить на будущее парочку переменных, которыми при необходимости можно отключить старый способ обработки. Работа смарта - то же, что и раньше. То, что хранится в таблице Jobs. Тип работы, gulag type - то, что в конфиге пишется в строке type. При правильной организации самой логики (logic@что-то_там) чтобы получить такую простыню, надо очень постараться. Часть условий просто уйдёт внутрь логики. Вместо переключения gulag type будет привычное переключение секций логики персонажей. Сюжетные условия редко включают в себя что-то кроме инфопоршней, и больше двух-трех type вряд ли потребуют для себя. Те единичные случаи, где условия будут выглядеть слишком длинно и непонятно, можно засунуть в функцию в xr_conditions и вызывать оттуда. Если там условия реально одни и те же, можно через #include ссылаться на типовые конфиги там, где это требуется. Как раз можно будет избавиться от написания loadStates и уменьшить эти самые файлы. В принципе, можно и с checkStalker/checkMonster также поступить, но тогда или строка cond разбухнет ещё больше, или потребуется делать ещё один condlist в конфиге. Тут пока ещё есть над чем думать. Оттого, что это всё будет не в виде одной простыни, а раскидано по параметрам путей, конфигам и скриптам, меньше всё равно не получится. Можно конечно пытаться делать "самособирающуюся" из путей логику, но обобщить и "сжать" всё - не получится. Где-то всё равно это придётся писать, особенно для сюжетной логики.

Для отдельных NPC порядок посещения смартов определяется в секции smart_terrains из customdata. На него эти правки вообще не влияют. Для всех обитателей смарта такого механизма и в оригинале не было. Можно было только запретить всем идти в указанный смарт, но это и после правок можно делать. Просто надо будет писать конфиг так, чтобы при определённом условии все типы работ блокировались, и все с них выгонялись.

Потому что вместо них можно использовать несколько gulag type. В конфиге это будет выглядеть примерно так: Вместо использования состояний, тип esc_fabrika_bandit разделён на esc_fabrika_bandit_normal и esc_fabrika_bandit_alarm. А general_lager здесь для того, чтобы не делать отдельный несюжетный смарт esc2_st_fabric.

Я так понимаю, копия нужна для защиты оригинала от изменения. После вызова obj:command( act, false) действие добавляется в очередь. А вот какие странности будут, если попытаться изменить его после добавление в очередь local new_act = action_first(obj, что-то_там) new_act:set_action(что-то_ещё) - можно только догадываться. И кстати переменную act лучше переименовать, т.к. есть одноимённый экспортированный класс.

Это и будет то, что имеется, просто методы будут вызываться не из смарта, а из самой работы. Один раз при загрузке работ преобразовывать их из таблиц в объекты, объединяя при этом работы с одинаковой секцией логики в один объект. Все эти объекты занести в индексированную таблицу (которая self.Job) и в хеш-таблицу, в которой ключом будет имя секции. Вот, собственно, и всё. А что их учитывать? Для каждого типа работ сделать промежуточный объект, в котором будет храниться вся инфа о типе работ (имя ltx и ссылка на него, ссылка на gulag_***.script, текущий state), и пропускать все обращения к gulag_***.script через него. Во избежание путаницы не использовать несколько типов работ и переключение state в одном смарте. От последнего со временем вообще лучше избавиться. Как тогда быть с путями, логикой и именованием этих "укрытий"? Да и рельеф на других уровнях (где игрок не был ещё) вряд ли можно просчитать...

При правильном подходе толк будет. Во-первых, вместо хранения кучи таблиц, описывающих работы с одинаковой логикой, достаточно всего один раз их преобразовать в объекты. Так, чтобы на одну секцию логики приходился только один объект работы. В этих же объектах хранить табличку NPC, назначенных на эту работу. Сокращение количества записей о работах может увеличить производительность. Да и на каждый чих дёргать работы из таблицы уже не нужно будет. Во-вторых, в такой класс можно перенести все методы, в которых взаимодействует только одна работа и один NPC. Это не так уж мало.Это повысит наглядность и человекочитаемость кода. Для реализации поддержки нескольких "gulag type" потребуется как-то объединять работы разных типов. Возможно потребуется делать ещё один класс, хотя можно попробовать обойтись и обычной таблицей. Если бы не было номерных состояний и списка группировок в строке communities, то этого можно было бы вообще не делать.

Касательно допиливания smart_terrain'ов напильником. Я так думаю, лучше все работы завернуть в класс с соответствующими методами. Т.е. чтобы каждая работа была не табличкой, а объектом класса. Для объединения работ с одним "gulag type" создать ещё один класс, в который засунуть проверку условий приёма NPC и всякие атавизмы типа номерных состояний.

Я делаю так - в биндере на этапе reinit принудительно очищаю все запомненные объекты через enable_memory_object, и отключаю неписям зрения (enable_vision). Включаю обратно только после того, как игра загрузилась полностью (т.е. игрок уже не видит экран загрузки). Помимо этого прописал в enemy_callback и схеме xr_danger игнорирование всех врагов и опасностей до того, как игра загрузится. Частично это помогло. Во всяком случае почти исчезли ситуации, когда никем не обнаруженный игрок сохранился где-то спрятавшись за углом, а потом загрузился и все сразу его заметили. Насколько это влияет на это "дальновидение" - не знаю, специально не проверял, т.к. принудительный оффлайн намертво отключил. Можно ещё попробовать вызвать skip_transfer_enemy(true), но вроде бы это только для зверей...

Похоже на какие-то косяки в реализации скрипта xr_danger. Evaluator для stalker_ids.property_danger должен возвращать false, если источником опасности является сам объект, или он далеко, или опасность была давно. Помимо этого можно для "просроченных" или неуместных опасностей дописать удаление объекта из памяти (через enable_memory_object). В оригинале, насколько я помню, такое удаление происходит только для игнорируемых врагов. Хотя определять тип звука по ogg-комментарию, а не по событию, вызывающему этот звук - это как-то... странно.

Это движковый вылет, я его уже описывал. Вылечить без ковыряния движка нельзя. Просто надо учитывать, что сочетание anim.free и move.crouch недопустимо.

Я бы проверил на предмет того, откуда берётся gulag.name. Если НЕ из strn:name() (где strn - объект smart_terrain), то тогда всё понятно. Вероятно, туда каким-то образом попадает type вместо name.