BASE1707

y0la @kaktamvandam@АндрейТанк Так. По поводу экспериментального патча. 1) Игра переведена на рельсы x64-движка (в качестве основы был взят форк abramcumner). Помимо этого, исправлено большое количество багов/дропов FPS, встречающихся ещё в оригинальном ЗП. Инновационного здесь ничего нет, акцент идёт именно на стабилизации. 2) Многие пользователи жаловались на графические проблемы, связанные, к примеру, с тенями. Был произведён откат шейдеров до состояния "ЗП + STCoP". Все странные наработки/недопилы, имеющие место быть, были убраны. 3) Множественные правки по скриптовой части. Ввиду изменённого Luabind игра перестала игнорировать какие-либо ошибки, связанные непосредственно со скриптами (в отличие от оригинального движка). Примеры: некорректные перегрузки функций (вместо 2 аргументов передаются 3), необработанные потенциальные nullptr/nil в коде, и многие другие ошибки, которые в любой момент могли спровоцировать если не битые сейвы, то хотя бы вылет. Стоит также явно упомянуть, что работа над патчем ещё не окончена. Мы каждый день ведём сбор информации о проблемах, осуществляем диагностику и основе полученных сведений модифицируем скриптовую базу игры. Не всё сразу. Поэтому, если конкретно у Вас возникает какая-либо из проблем, не разобранная ранее и Вы уже установили патч: 1) опишите, что произошло 2) опишите последовательность действий 3) (по возможности) прикрепите последний доступных сейв 4) (по возможности) прикрепите лог-файл 5) (!) прикрепите минидамп (.mdmp). Спасибо.

Maks2012 Без модификации движка никак. Если правильно помню, сброс позиции скроллбара происходит из-за того, что при апдейте инвентаря (взят/убран предмет) происходит ре-инициализация всякой мишуры, в результате чего скроллбар получает позицию (0, 0) и уходит в самый вверх. Правка, исправляющая это, действительно имеется в OGSR. При желании, можно перенести на тот же 1.0007 без волокиты.

Можно - но только при желании ковырять движок. Во-первых, нужно зарегистрировать дополнительный кейбинд по аналогии с оригинальными (для начала см. файл xrGame/xr_level_controller.h). Во-вторых, отлавливать срабатывание этого кейбинда в оружейных классах (см. CWeapon::Action(...)), при обнаруженном нажатии вызывать переход к состоянию eBore (в ЗП делается при помощи SwitchState(eBore)). До перехода следует проверить, что оружие ничем не занято, находится в состоянии eIdle, при этом у него не активен прицел и т.п. В-третьих, вырезать из апдейта CWeapon оригинальный переход к состоянию скуки.

zero777 Лог малоинформативен - походу, движковая ошибка. Генерация минидампа могла бы спасти ситуацию, однако, сейчас приходится тыкать пальцем в небо. Попробуйте: 1) поставить отдельно >правленный скрипт< по пути gamedata/scripts. 2) сменить тип освещения в опциях. Если ничего из вышеперечисленного не поможет - будем думать дальше.

zero777 Сгенерировался лог/минидамп?

Gryazniy_Garik Приветствую, вылет по-прежнему происходит?

Вылеты в Припяти (по крайней мере, обнаруженная их часть) были связаны со скриптовыми ошибками интегрированного AI Additional (модуль: rx_addons.script). Как я понимаю, правка этого скрипта пока что не попала в фикс, поэтому, попробуйте поставить отдельно >правленный скрипт< (переместить в gamedata/scripts с заменой).

Если не верите мне - откройте любым текстовым редактором исходный код Зова Припяти и поищите ключевую фразу "Your video card doesn't meet game requirements.\n\nTry to lower game settings." При наличии базовых знаний C/C++ всё станет понятно. Я же ещё раз говорю - дело именно в шейдерах. Объективно: были найдены проблемы, будем исправлять.

Подобная ошибка возникает в том случае, когда компиляция шейдеров завершилась неудачно. shaders_cache чистили?

WILD_USEC Судя по всему, обрезание моделей происходит из-за движковой константы VIEWPORT_NEAR. Движок STCoP, в отличие от Call of Chernobyl, для отрисовки худовых моделей использует дополнительную константу (VIEWPORT_NEAR_HUD в исходном коде), значение которой значительно меньше.

Contentic Во-первых, я не переходил с Вами на "ты". Во-вторых, уже два человека указали дальнейший вектор решения задачи. Я даже упомянул конкретную функцию, в сторону которой стоит копать. Вы обвиняете других в истерике и нежелании помогать, хотя сами не удосужились даже файл открыть.

Да, действительно, эта тема предназначена для конкретных вопросов по моддингу, а не для "я не понимаю, объясните мне по пальцам". Если Вы отказываетесь самостоятельно добывать информацию, пролистывать готовые скрипты/сниппеты кода (учитывая, что на текущий момент "слепых" мест в движке не осталось) и учиться на своих ошибках, включая синдром выученной беспомощности - лучше покиньте моддинг, сохраните себе больше нервов. Серьёзно. А по поводу вопроса - Вам M31 и так дал хорошую подсказку. Смотрите ui_load_dialog.script, объект - self.list_box. Как он инициализируется, как к нему применяется метод AddExistingItem() и прочее. Если же Вы не хотите в этом разбираться - поймите, что никому, кроме Вас самих, это в общем-то и не нужно. P. S.: Это не агрессия в Вашу сторону, а парадигма, на которой "выросло" большинство "крупных" модмейкеров.

ТЫКАРЬ Баги с машинами (инвертированное управление, зависание в воздухе, некорректное расположение актора при сейв-лоаде) уже исправлены правками движка, который, на текущий момент, находится в разработке. HIK Сгенерировался лог/минидамп (.mdmp)? Benny_g Можете предоставить скриншоты? Хотя бы в личные сообщения.

Очень странная формулировка, не уверен, что правильно понял. Так или иначе, за работу с динамическими источниками освещения (фонарь, фары машин, подсветка аномалий и т.п.) отвечает движковой класс ref_light. Учитывая, что исходный код DA закрыт, могу лишь предположить, что зажигалка для освещения использует объект этого класса, а его дальность/яркость просчитывается в виртуальном методе UpdateCL, в зависимости от объёма сохранившегося топлива. Веду к следующему: если программисты DA заблаговременно не экспортировали скриптовые функции для работы с условным CLigther (остаётся лезть в lua_help.script, а также искать следы работы с зажигалкой в других скриптах) - осуществить желаемое без движковых правок не является возможным (сорцов нет, а реверс-инженера для таких целей Вы вряд ли найдёте). P. S.: Возможно речь идёт не о самом освещении, а о партиклах огня, которые начинают отыгрываться на активной зажигалке. Ситуация примерно та же - смотреть в скрипты, искать следы вызова партиклов для худовых объектов, если нет нужного - у-вы.

Символ f, указанный в значении переменной/литерала, в языках программирования С/С++ соответствует типу данных float (число с плавающей запятой небольшой точности). Учитывая, что речь идёт не об исходном коде движка, а о конфигах, указывать его, как правило, нет нужды (парсеры всё сделают за вас). Ближе к делу: 2.f можно представить как 2.0. По поводу единицы измерения, я глянул код соответствующего класса: после считывания значения, движок производит математические операции с Device.fTimeGlobal, что соответствует секундам реального времени.

Пример реализации дополнительных коллбеков (press/hold/release button) на X-Ray 1.6:

Графические предустановленные пресеты хранятся в configs/rspec_*.ltx. Как костыльный аналог, при инициализации главного меню/нет_спавне актора в некоторых модах вызывается скрипт, работающий напрямую с консолью, пример: get_console():execute("r3_dynamic_wet_surfaces on")

Во-первых, для вопросов, связанных непосредственно с движком, существует отдельная тема. Во-вторых, окно ввода набито некритическими предупреждениями, информации о самих ошибок (кроме заключения линковщика) - нет. В-третьих, репозиторий принадлежит непонятно кому и непонятно что там содержится. Есть большая вероятность того, что проект в принципе-то без предварительных правок и не соберётся.

Если это объект, который можно поместить в инвентарь (класс S_FOOD и подобное), при его поднятии (появлении в инвентаре ГГ) сработает коллбек actor_binder:on_item_take (файл bind_stalker.script). Остаётся сравнить секцию с необходимой и вызвать соответствующие функции (выдачу инфопоршня и т.д.).

Правка исходного кода движка. Смотреть в сторону CWeaponMagazined (WeaponMagazined.cpp) и его дочерних классов, менять там, где фигурируют строковые литералы anm_reload и snd_reload. Если нет опыта в С/C++ - можно дёрнуть из открытых репозиториев, подобная правка присутствует практически везде сейчас.

Либо не в ту секцию смотришь, либо при переносе классы поломал (если движок тыркал). Вылеты по нехватке аттрибутов, которых быть и не должно - один из признаков.

Как раз таки нет. Основной функционал Wine (и его форков соответственно) заключается в перехвате вызовов и дальнейшей подмене библиотек. Ощутимый дискомфорт практически отсутствует, напротив - порою бенчмарки показывают положительный эффект от подобного вмешательства. У меня самого в качестве активной ОС используется Debian 11. При этом идёт работа над модификацией движка: сборка производится на вспомогательной машине под управлением Windows 10 (да и то, потому что перетащить солюшн под CMake руки не доходят), после чего готовые бинарники спокойно перекатываются на GNU/Linux и запускаются через PortProton. Просадок нет, технических (в т. ч. графических) артефактов - тоже, всё прекрасно работает. Повторюсь, основная проблема заключается лишь в том, что потенциально затраченные человекочасы (даже не говорю про иные ресурсы) приведут лишь к неиграбельному шлаку без права на существование, поскольку трилогия изначательно не была заточена под мобильные платформы.

Успешные запуски на GNU/Linux осуществляются спокойно и без Open X-Ray - спасибо таким быстро развивающимся проектам как Wine и PortProton. Другое дело, что перетаскивать игру на платформу, которая под неё не заточена как минимум в плане геймдиза - более чем бессмысленно.