Полтергейст

В шапке темы битые ссылки на распаковщики архивов игры, поправьте плз. Не работает первая ссылка и ссылка на 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 в конфиге. Тут пока ещё есть над чем думать. Оттого, что это всё будет не в виде одной простыни, а раскидано по параметрам путей, конфигам и скриптам, меньше всё равно не получится. Можно конечно пытаться делать "самособирающуюся" из путей логику, но обобщить и "сжать" всё - не получится. Где-то всё равно это придётся писать, особенно для сюжетной логики.