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

Полтергейст

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

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

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

  • AMKoin

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

Оценочная активность

36

1 подписчик

Информация

  • Город
    Ростовская область

Недавние посетители профиля

1 061 просмотр профиля
  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' выглядят не очень красиво. А так сразу видно, какие работы и при каких условиях доступны, всё собрано в одном конфиге. Нет разделения на несколько смартов. Если сделать, чтобы работало и так и так, то переделывать не обязательно. Разве что оставить на будущее парочку переменных, которыми при необходимости можно отключить старый способ обработки. Раб

AMK-Team.ru

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