NVHR Crash Fix (ТЕПЕРЬ ПОЛНОСТЬЮ!)

[Trust 452]

Цитата

NB: Проблема скорее всего только Линуксовая-Стимдэковая, или же в целом связана с использованием DXVK в Вегасе вместе с NVHR.

Если у вас нету моих проклятущих моментальных крэшей в стрессовых нагрузках (см. ниже Методы Стресс-Тестов) -- обходите мой гайд стороной, так-как для вас он будет только ВРЕДЕН;

Моё решение отката в Линуксе на версию NVHR 2.4 было вызвано безвыходной ситуацией и полной безнадёгой!

 

Здравствуй Народ!

 

Сейчас для NVHR появилась вспомогательная библиотека на основе RPMalloc. Что она делает??? -- Заменяет все остальные функции выделения памяти, не затронутые НВХРом!

Кроме-того...
 

Я проводил 2 вида крэш-теста всех версий NVHR со всеми доступными настройками оптимизаторов движка, таких как Inline Vanilla Functions (StewieTweaks), bUseDefaultPoolForTextures = 1 + iReplaceTextureCreationLocks = 2 + iReplaceGeometryPrecacheLocks = 2 (NVTF), полным конфигом настроек DXVK, и со специальной версией RPMalloc (с тонкими настройками).

 

Виды крэш-тестов таковы: В дед-мани нужно несколько сотен раз проходить через двери загрузки из одного Interior World в другой, после выхода из двери сразу разворачиваясь на 180град и нажимая Е, например между Виллой и Солида дель-Соль.

 

Второй крэш-тест, это В конце Лонсам Роад, в Храме Уллиса -- взрывать толпы меченных 40мм Гранатомётом с плазменными гранатами, и что важно: НЕ ОТКЛЮЧАЯ АГРЕССИВНЫЙ АВТОЛУТ.

 

Тест с Дед Мани показал, что очень быстро пройти/зайти в двери ~500 Раз можно только с версией NVHR 2.4 -- Все остальные версии крашатся с ошибкой R6025 Pure Virtual Procedure Call, причём, без зависимости от конфигов всех остальных оптимизаторов, будь то Инлайн Стиви, или Агрессивные настройки NVTF / DXVK.

 

Так-же, мне удалось выяснить, почему в концовке Лонсам Роад ломается возвращение в Разлом (чтоб побазарить с Уллисом, и пройти на Курьерскую Милю). -- Проблема в том, что я ошибся в суждениях: МИНИМАЛЬНАЯ БЕЗОПАСНАЯ ВЕЛИЧИНА TIMESCALE = 10, А НЕ 8 !!! (Что бы там не говорил Фронтир)

 

====

Что имеем в остатке: Настраивайте свою игру как хотите, за одним исключением -- NVHR должен быть версии 2.4 вместе с компаньоном "RPMalloc Overdrive"!!!

 

====

Если очень хотите, я распишу где взять конфигурируемый RPMalloc Overdrive и поделюсь своими конфигурационными файлами! (например к DXVK)

 

 

 

Изменено 20 декабря, 2025 пользователем Trust
NB!

[Атаман 458]

То есть предложение это взять устаревшую версию NVHR, у которой ряд других проблем, и RPMalloc, который тестил Wall_SoGB и заметил, что конкретно игре RPMalloc ничего не делает (т.е. ни холодно, ни жарко) обусловлено вылетами, которые в первом случае нужно вызвать 500 переходами между локациями (я думаю оно на любой игре вылетит с таким приколом) и затем с прыжком спредподвыподвывертом и нажимом на "е", а во втором случае взрывая толпы полудурков плазмой и ещё используя нелорный и непрактичный из-за перегрузов (на мой взгляд) автолут?

Я думаю, что фикс этим проблемам это не переход на старую версию и не установка непроверенного RPMalloc, а непереход локаций 500 раз за короткое время в Dead Money и отключить автолут на 5 минут в Lonesome Road. Зачем изобретать велосипед?

Изменено 19 декабря, 2025 пользователем Abyssfer

[Атаман 458]

Короче...

Если рассматривать ситуацию строго с технической точки зрения, то R6025 Pure Virtual Procedure Call в контексте Gamebryo почти всегда указывает не на проблему аллокации памяти, а на нарушение жизненного цикла объектов, когда происходит обращение к объекту с уже разрушенной vtable либо вызов метода после частичной деинициализации. Аллокатор, независимо от того системный это malloc или RPMalloc, не способен исправить такие ошибки, поскольку они находятся уровнем выше и связаны с порядком уничтожения объектов, обработкой событий и хуками NVHR во время выгрузки ячеек и переходов между мирами. То, что версия NVHR 2.4 реже ловит R6025 в экстремальных условиях, скорее говорит о менее агрессивном вмешательстве в эти процессы, а не о принципиально более корректной модели управления памятью.
 

Тесты с сотнями быстрых переходов между Interior World с немедленным возвратом и интеракцией представляют собой искусственный стресс сценарий, выходящий за рамки обычного геймплея. Это по сути fuzz тест без пауз на отложенную очистку и сборку мусора, и краши движка в таком режиме ожидаемы для любой версии NVHR, поэтому использовать их как универсальный критерий полной стабильности одной версии по сравнению с другой некорректно.
 

Основные источники нестабильности Fallout New Vegas хорошо известны и лежат в области refcount объектов, отложенного уничтожения геометрии, скриптовых колбэков во время выгрузки ячеек и race condition между рендером и скриптовой виртуальной машиной. RPMalloc не участвует в управлении временем жизни объектов, не контролирует refcount и не синхронизирует deferred destruction, поэтому в реальных игровых сценариях он может лишь слегка изменить профиль фрагментации памяти, но не влияет на корневые причины крашей, связанных с NVHR.
 

Агрессивный автолут при массовых onDeath событиях, взрывах и большом количестве одновременно удаляемых акторов давно известен как триггер неопределённого поведения. В таких ситуациях контейнеры и акторы могут быть удалены, в то время как скрипты продолжают к ним обращаться, а NVHR ускоряет процесс очистки. Это снова проблема жизненного цикла объектов, а не аллокации памяти, и временное отключение автолута в подобных сценах является более логичным решением, чем добавление дополнительного аллокатора.
 

Использование timescale ниже 10 также относится к известным ограничениям движка. При таких значениях начинают накладываться таймеры и события OnUpdate, часть скриптов на это не рассчитана и возникает рассинхрон между игровым временем и фактическими событиями. Связывать эти эффекты с версией NVHR и использовать их как аргумент в пользу отката на более старую версию некорректно.
 

В итоге связка NVHR 2.4 с RPMalloc Overdrive может показывать более стабильное поведение в узких и искусственных стресс сценариях, но она не устраняет архитектурные причины крашей и не является универсальным решением. В реальной игре гораздо более предсказуемый результат даёт корректная настройка NVHR, NVTF и StewieTweaks, умеренные значения timescale и осознанное использование автолута, без попыток компенсировать фундаментальные ограничения движка дополнительными костылями.

Изменено 19 декабря, 2025 пользователем Abyssfer

[FNVFUN 981]

1 час назад, Abyssfer сказал:

В итоге связка NVHR 2.4 с RPMalloc Overdrive может показывать более стабильное поведение в узких и искусственных стресс сценариях, но она не устраняет архитектурные причины крашей и не является универсальным решением.

И не поспоришь ведь.

[Trust Автор вопроса 452]

6 часов назад, Abyssfer сказал:

То есть предложение это взять устаревшую версию NVHR, у которой ряд других проблем, и RPMalloc, который тестил Wall_SoGB и заметил, что конкретно игре RPMalloc ничего не делает (т.е. ни холодно, ни жарко) обусловлено вылетами, которые в первом случае нужно вызвать 500 переходами между локациями (я думаю оно на любой игре вылетит с таким приколом) и затем с прыжком спредподвыподвывертом и нажимом на "е", а во втором случае взрывая толпы полудурков плазмой и ещё используя нелорный и непрактичный из-за перегрузов (на мой взгляд) автолут?

Я думаю, что фикс этим проблемам это не переход на старую версию и не установка непроверенного RPMalloc, а непереход локаций 500 раз за короткое время в Dead Money и отключить автолут на 5 минут в Lonesome Road. Зачем изобретать велосипед?

 

Всё крайне просто: Устаревшая версия не падает вообще, новые версии -- падают от 15 переходов.

 

Тоже и Лонсам  Роад -- Новые версии триггерятся на краш, старая версия -- стоит железобетонно.

 

Поясни пожалуйста, какие там есть "фундаментальные проблемы"??!

 

Мне всё это пишетъ челъ, который на запрос "Протесть Пожалуйста" -- запустил Дед Мани на 3 минуты, прошёл 3 локи, закрыл, и ответил "Не падает", без тяжёлого стресс-тестирования.

 

Кроме-того, ты не используешь ДХВК, потому я не могу считать твои суждения "Авторитетным Источником".

[Trust Автор вопроса 452]

6 часов назад, Abyssfer сказал:

Короче...

Если рассматривать ситуацию строго с технической точки зрения, то R6025 Pure Virtual Procedure Call в контексте Gamebryo почти всегда указывает не на проблему аллокации памяти, а на нарушение жизненного цикла объектов, когда происходит обращение к объекту с уже разрушенной vtable либо вызов метода после частичной деинициализации. Аллокатор, независимо от того системный это malloc или RPMalloc, не способен исправить такие ошибки, поскольку они находятся уровнем выше и связаны с порядком уничтожения объектов, обработкой событий и хуками NVHR во время выгрузки ячеек и переходов между мирами. То, что версия NVHR 2.4 реже ловит R6025 в экстремальных условиях, скорее говорит о менее агрессивном вмешательстве в эти процессы, а не о принципиально более корректной модели управления памятью.
 

Тесты с сотнями быстрых переходов между Interior World с немедленным возвратом и интеракцией представляют собой искусственный стресс сценарий, выходящий за рамки обычного геймплея. Это по сути fuzz тест без пауз на отложенную очистку и сборку мусора, и краши движка в таком режиме ожидаемы для любой версии NVHR, поэтому использовать их как универсальный критерий полной стабильности одной версии по сравнению с другой некорректно.
 

Основные источники нестабильности Fallout New Vegas хорошо известны и лежат в области refcount объектов, отложенного уничтожения геометрии, скриптовых колбэков во время выгрузки ячеек и race condition между рендером и скриптовой виртуальной машиной. RPMalloc не участвует в управлении временем жизни объектов, не контролирует refcount и не синхронизирует deferred destruction, поэтому в реальных игровых сценариях он может лишь слегка изменить профиль фрагментации памяти, но не влияет на корневые причины крашей, связанных с NVHR.
 

Агрессивный автолут при массовых onDeath событиях, взрывах и большом количестве одновременно удаляемых акторов давно известен как триггер неопределённого поведения. В таких ситуациях контейнеры и акторы могут быть удалены, в то время как скрипты продолжают к ним обращаться, а NVHR ускоряет процесс очистки. Это снова проблема жизненного цикла объектов, а не аллокации памяти, и временное отключение автолута в подобных сценах является более логичным решением, чем добавление дополнительного аллокатора.
 

Использование timescale ниже 10 также относится к известным ограничениям движка. При таких значениях начинают накладываться таймеры и события OnUpdate, часть скриптов на это не рассчитана и возникает рассинхрон между игровым временем и фактическими событиями. Связывать эти эффекты с версией NVHR и использовать их как аргумент в пользу отката на более старую версию некорректно.
 

В итоге связка NVHR 2.4 с RPMalloc Overdrive может показывать более стабильное поведение в узких и искусственных стресс сценариях, но она не устраняет архитектурные причины крашей и не является универсальным решением. В реальной игре гораздо более предсказуемый результат даёт корректная настройка NVHR, NVTF и StewieTweaks, умеренные значения timescale и осознанное использование автолута, без попыток компенсировать фундаментальные ограничения движка дополнительными костылями.

 

Если ответить тебе коротко, без флуда, то я скажу так:

 

Это проблема мемори-маппинга Сверх-Большого Хипа с интерференцией управления памятью в ДХВК.

 

Если кратко, то просто в форке НВХР Уолла, на гитхабе, попроси Уолла уменьшить хип с Двух Гигабайт, до границ хипа версии 1991 года 2.4

[Trust Автор вопроса 452]

6 часов назад, Abyssfer сказал:

Короче...

Если рассматривать ситуацию строго с технической точки зрения, то R6025 Pure Virtual Procedure Call в контексте Gamebryo почти всегда указывает не на проблему аллокации памяти, а на нарушение жизненного цикла объектов, когда происходит обращение к объекту с уже разрушенной vtable либо вызов метода после частичной деинициализации. Аллокатор, независимо от того системный это malloc или RPMalloc, не способен исправить такие ошибки, поскольку они находятся уровнем выше и связаны с порядком уничтожения объектов, обработкой событий и хуками NVHR во время выгрузки ячеек и переходов между мирами. То, что версия NVHR 2.4 реже ловит R6025 в экстремальных условиях, скорее говорит о менее агрессивном вмешательстве в эти процессы, а не о принципиально более корректной модели управления памятью.
 

Тесты с сотнями быстрых переходов между Interior World с немедленным возвратом и интеракцией представляют собой искусственный стресс сценарий, выходящий за рамки обычного геймплея. Это по сути fuzz тест без пауз на отложенную очистку и сборку мусора, и краши движка в таком режиме ожидаемы для любой версии NVHR, поэтому использовать их как универсальный критерий полной стабильности одной версии по сравнению с другой некорректно.
 

Основные источники нестабильности Fallout New Vegas хорошо известны и лежат в области refcount объектов, отложенного уничтожения геометрии, скриптовых колбэков во время выгрузки ячеек и race condition между рендером и скриптовой виртуальной машиной. RPMalloc не участвует в управлении временем жизни объектов, не контролирует refcount и не синхронизирует deferred destruction, поэтому в реальных игровых сценариях он может лишь слегка изменить профиль фрагментации памяти, но не влияет на корневые причины крашей, связанных с NVHR.
 

Агрессивный автолут при массовых onDeath событиях, взрывах и большом количестве одновременно удаляемых акторов давно известен как триггер неопределённого поведения. В таких ситуациях контейнеры и акторы могут быть удалены, в то время как скрипты продолжают к ним обращаться, а NVHR ускоряет процесс очистки. Это снова проблема жизненного цикла объектов, а не аллокации памяти, и временное отключение автолута в подобных сценах является более логичным решением, чем добавление дополнительного аллокатора.
 

Использование timescale ниже 10 также относится к известным ограничениям движка. При таких значениях начинают накладываться таймеры и события OnUpdate, часть скриптов на это не рассчитана и возникает рассинхрон между игровым временем и фактическими событиями. Связывать эти эффекты с версией NVHR и использовать их как аргумент в пользу отката на более старую версию некорректно.
 

В итоге связка NVHR 2.4 с RPMalloc Overdrive может показывать более стабильное поведение в узких и искусственных стресс сценариях, но она не устраняет архитектурные причины крашей и не является универсальным решением. В реальной игре гораздо более предсказуемый результат даёт корректная настройка NVHR, NVTF и StewieTweaks, умеренные значения timescale и осознанное использование автолута, без попыток компенсировать фундаментальные ограничения движка дополнительными костылями.

 

По версии Цезаря -- это какая-то Диалектика Гегеля. Вместо железной практики -- это всё гипотезы и философия.

 

Твои утверждения, что "Такая-то версия имеет множество фундаментальных проблем" -- на практике ничего не решает.

 

Никто не инвестировал столько сил в понимание стабильности этой дряни как я. )))

[Trust Автор вопроса 452]

Абиссфер! Чел, ты....

 

Приклей ДХВК, и иди гоняй стресс-тесты двое суток... НА СТИМДЭКЕ.

 

ЛЮБАЯ. ПОВТОРЮСЬ: ЛЮБАЯ версия НВХР имеет кучу проблем, Теорема Эскобара, сменял стрижа на ежа.

[Trust Автор вопроса 452]

7 часов назад, Abyssfer сказал:

Короче...

Если рассматривать ситуацию строго с технической точки зрения, то R6025 Pure Virtual Procedure Call в контексте Gamebryo почти всегда указывает не на проблему аллокации памяти, а на нарушение жизненного цикла объектов, когда происходит обращение к объекту с уже разрушенной vtable либо вызов метода после частичной деинициализации. Аллокатор, независимо от того системный это malloc или RPMalloc, не способен исправить такие ошибки, поскольку они находятся уровнем выше и связаны с порядком уничтожения объектов, обработкой событий и хуками NVHR во время выгрузки ячеек и переходов между мирами. То, что версия NVHR 2.4 реже ловит R6025 в экстремальных условиях, скорее говорит о менее агрессивном вмешательстве в эти процессы, а не о принципиально более корректной модели управления памятью.
 

Тесты с сотнями быстрых переходов между Interior World с немедленным возвратом и интеракцией представляют собой искусственный стресс сценарий, выходящий за рамки обычного геймплея. Это по сути fuzz тест без пауз на отложенную очистку и сборку мусора, и краши движка в таком режиме ожидаемы для любой версии NVHR, поэтому использовать их как универсальный критерий полной стабильности одной версии по сравнению с другой некорректно.
 

Основные источники нестабильности Fallout New Vegas хорошо известны и лежат в области refcount объектов, отложенного уничтожения геометрии, скриптовых колбэков во время выгрузки ячеек и race condition между рендером и скриптовой виртуальной машиной. RPMalloc не участвует в управлении временем жизни объектов, не контролирует refcount и не синхронизирует deferred destruction, поэтому в реальных игровых сценариях он может лишь слегка изменить профиль фрагментации памяти, но не влияет на корневые причины крашей, связанных с NVHR.
 

Агрессивный автолут при массовых onDeath событиях, взрывах и большом количестве одновременно удаляемых акторов давно известен как триггер неопределённого поведения. В таких ситуациях контейнеры и акторы могут быть удалены, в то время как скрипты продолжают к ним обращаться, а NVHR ускоряет процесс очистки. Это снова проблема жизненного цикла объектов, а не аллокации памяти, и временное отключение автолута в подобных сценах является более логичным решением, чем добавление дополнительного аллокатора.
 

Использование timescale ниже 10 также относится к известным ограничениям движка. При таких значениях начинают накладываться таймеры и события OnUpdate, часть скриптов на это не рассчитана и возникает рассинхрон между игровым временем и фактическими событиями. Связывать эти эффекты с версией NVHR и использовать их как аргумент в пользу отката на более старую версию некорректно.
 

В итоге связка NVHR 2.4 с RPMalloc Overdrive может показывать более стабильное поведение в узких и искусственных стресс сценариях, но она не устраняет архитектурные причины крашей и не является универсальным решением. В реальной игре гораздо более предсказуемый результат даёт корректная настройка NVHR, NVTF и StewieTweaks, умеренные значения timescale и осознанное использование автолута, без попыток компенсировать фундаментальные ограничения движка дополнительными костылями.

 

ЖЕЛЕЗОБЕТОННЫЙ ФАКТ: Эта Версия, 2.4, не падает ВООБЩЕ. Остальные -- падают ПОСТОЯННО.

ЧЯДНТ???

 

Ты говоришь, мол, мои Тесты -- СИНТЕТИЧЕСКИЕ. Но ты не в состоянии предложить ничего лучше.

 

Я предложил ПРАКТИЧЕСКОЕ РЕШЕНИЕ -- Эта Версия -- не падает никак, остальные -- падают постоянно.

 

Вся остальная теория походит больше на пустые слова, не подкреплённые практикой.

[Trust Автор вопроса 452]

7 часов назад, Abyssfer сказал:

То есть предложение это взять устаревшую версию NVHR, у которой ряд других проблем, и RPMalloc, который тестил Wall_SoGB и заметил, что конкретно игре RPMalloc ничего не делает (т.е. ни холодно, ни жарко) обусловлено вылетами, которые в первом случае нужно вызвать 500 переходами между локациями (я думаю оно на любой игре вылетит с таким приколом) и затем с прыжком спредподвыподвывертом и нажимом на "е", а во втором случае взрывая толпы полудурков плазмой и ещё используя нелорный и непрактичный из-за перегрузов (на мой взгляд) автолут?

Я думаю, что фикс этим проблемам это не переход на старую версию и не установка непроверенного RPMalloc, а непереход локаций 500 раз за короткое время в Dead Money и отключить автолут на 5 минут в Lonesome Road. Зачем изобретать велосипед?

 

Не то пальто. Опять же: ты со своей критикой, опять-таки, ничего не можешь мне предложить.

Критикуешь -- предлагай. А ты утверждаешь, типа "чтоб игра не падала в стресс-ситуации, просто на неё не дыши, чтобы не провоцировать стресс".

Это не решение.

 

+ У тебя НВР, в котором видимо есть и свои фиксы, и отсутствует ДХВК.

 

Ты мол говоришь, УМВР ("У Меня Всё Работает"), "а у меня такая-же нога и не болит!".

Но есть Нюанс -- твой тестовый стенд отличается от моего очень сильно.

Пойди наверни СФВ на Стимдэк, тогда будет толк с этого разговора.

[Trust Автор вопроса 452]

4 часа назад, Trust сказал:

непереход локаций 500 раз за короткое время в Dead Money и отключить автолут на 5 минут в Lonesome Road. Зачем изобретать велосипед?

 

Если оно ломается там, значит ломается и в некоторых других местах, потому надо делать не так как ты предлагаешь "ПРИ ВОЗНИКНОВЕНИИ СИМПТОМОВ СПРЯТАТЬ ГОЛОВУ В ПЕСОК" -- а решать проблему по-настоящему!

 

4 часа назад, Trust сказал:

которые в первом случае нужно вызвать 500 переходами между локациями

 

Ты опять что-то путаешь. Мой тест показал, что твоя любимая версия крашится на 12 переходах, а моя не крашится на 500 (и вообще я устал её мучать раньше чем наступил бы краш)

 

4 часа назад, Trust сказал:

и ещё используя нелорный и непрактичный из-за перегрузов (на мой взгляд) автолут?

 

Зная, что я основной автор автолута, и его всё время юзаю для лулзов (симуляции клептомана) ты всё-таки решил это сказать... Я аналогично отношусь к редизайнам нпц и рассам, так-как они больше жрут оперативной / видео памяти, и на мой взгляд не имеют большого смысла, но я же это мнение держу при себе, да?

[Атаман 458]

Я не спорю, что в твоём стенде NVHR 2.4 ведёт себя стабильнее. Я спорю с тем, что из этого следует универсальный вывод “2.4 не падает вообще, остальные фундаментально плохие”. R6025 - это симптом ошибки жизненного цикла объектов, а не размера хипа или аллокатора, и аллокаторы лишь меняют тайминги проявления. Стресс-тесты полезны как сигнал, но без фиксации окружения они показывают только поведение конкретной конфигурации, а не общую истину. Откат на 2.4 может быть рабочим обходом для твоей сборки, но это не устранение причины и не решение, которое можно безопасно рекомендовать всем. Если ты считаешь, что проблема именно в связке NVHR и DXVK, это нужно доказывать воспроизводимым кейсом с минимальным набором переменных, а не капсом. Всё остальное - разные костыли под разные стенды.

Изменено 20 декабря, 2025 пользователем Abyssfer

[Trust Автор вопроса 452]

3 минуты назад, Abyssfer сказал:

Я не спорю, что в твоём стенде NVHR 2.4 ведёт себя стабильнее. Я спорю с тем, что из этого следует универсальный вывод “2.4 не падает вообще, остальные фундаментально плохие”. R6025 - это симптом ошибки жизненного цикла объектов, а не размера хипа или аллокатора, и аллокаторы лишь меняют тайминги проявления. Стресс-тесты полезны как сигнал, но без фиксации окружения они показывают только поведение конкретной конфигурации, а не общую истину. Откат на 2.4 может быть рабочим обходом для твоей сборки, но это не устранение причины и не решение, которое можно безопасно рекомендовать всем. Если ты считаешь, что проблема именно в связке NVHR и DXVK, это нужно доказывать воспроизводимым кейсом с минимальным набором переменных, а не капсом. Всё остальное - разные костыли под разные стенды.

 

Окей, я тебя понял

 

Сверху добавлю плашку, что это гайд для линукс / стимдек и возможно ДХВК+Вин.

[Атаман 458]

Есть ещё один момент, который ты обходишь. Ты несколько раз писал про DXVK и обещал гайд под него, но при этом продолжаешь продвигать сценарий с NVHR, хотя на практике у большинства тяжёлых сборок DXVK уже сам по себе является узким местом и часто задыхается даже без NVHR. В связке DXVK + NVHR нагрузка и количество точек отказа только растёт, что подтверждается багрепортами и обсуждениями в темах NVHR. При этом это подаётся как универсальное решение, хотя фактически опирается на конкретную среду и конкретную реализацию DXVK, и без отдельных тестов на других конфигурациях такие выводы переносить некорректно.
 

Плюс твои тесты проводятся на чистой SFW без модулей, тогда как SFW:RA имеет принципиально другой профиль нагрузки по текстурам, моделям, скриптам и общему объёму контента. При существенно большем суммарном прохождении стабильное "время жизни" одной игровой сессии там, наоборот, обычно меньше, и система быстрее доходит до пограничных состояний по памяти и синхронизации, из-за чего поведение, стабильное на чистой SFW, может ломаться на RA.

Написал раньше, чем увидел ответ, ну да ладно, пусть будет..

Изменено 20 декабря, 2025 пользователем Abyssfer

[Trust Автор вопроса 452]

9 минут назад, Abyssfer сказал:

Есть ещё один момент, который ты обходишь. Ты несколько раз писал про DXVK и обещал гайд под него, но при этом продолжаешь продвигать сценарий с NVHR, хотя на практике у большинства тяжёлых сборок DXVK уже сам по себе является узким местом и часто задыхается даже без NVHR. В связке DXVK + NVHR нагрузка и количество точек отказа только растёт, что подтверждается багрепортами и обсуждениями в темах NVHR. При этом это подаётся как универсальное решение, хотя фактически опирается на конкретную среду и конкретную реализацию DXVK, и без отдельных тестов на других конфигурациях такие выводы переносить некорректно.
 

Плюс твои тесты проводятся на чистой SFW без модулей, тогда как SFW:RA имеет принципиально другой профиль нагрузки по текстурам, моделям, скриптам и общему объёму контента. При существенно большем суммарном прохождении стабильное "время жизни" одной игровой сессии там, наоборот, обычно меньше, и система быстрее доходит до пограничных состояний по памяти и синхронизации, из-за чего поведение, стабильное на чистой SFW, может ломаться на RA.

Написал раньше, чем увидел ответ, ну да ладно, пусть будет..

 

Вкратце: "Если пользователь не-экспериментатор и живёт в Виндовс -- смысла в ДХВК почти нет".

 

Это только для тех, кто играет на дэке или в настольном лунипсе.

Я могу конечно запостить полный конфиг ДХВК со всеми переведёнными объяснениями функций, например, как сделать, чтобы выжать макс-фпс, или наоборот, за счёт небольшого снижения сделать поведение аналогичным виндовому д3д

[Lord_Inqusitor 8]

1 час назад, Trust сказал:

 

Вкратце: "Если пользователь не-экспериментатор и живёт в Виндовс -- смысла в ДХВК почти нет".

 

Это только для тех, кто играет на дэке или в настольном лунипсе.

Я могу конечно запостить полный конфиг ДХВК со всеми переведёнными объяснениями функций, например, как сделать, чтобы выжать макс-фпс, или наоборот, за счёт небольшого снижения сделать поведение аналогичным виндовому д3д

А что по итогу? Если брать, например, DXVK, с чем его можно ставить, а с чем нет?

[Trust Автор вопроса 452]

4 минуты назад, Lord_Inqusitor сказал:

А что по итогу? Если брать, например, DXVK, с чем его можно ставить, а с чем нет?

 

Если НВХР от 3.0 до 4.2 бешенно чудит с этими крашами загрузок локаций Дед Мани и в концовке Лонсам Роад, в последней битве в Храме Улисса -- вероятно, поможет версия 2.4

 

Но это следует проверять отдельно, так-как судя по всему, моя проблема с моим же решением -- линуксовая.

 

Всё остальное * мешать не будет.

[Lord_Inqusitor 8]

13 минут назад, Trust сказал:

 

Если НВХР от 3.0 до 4.2 бешенно чудит с этими крашами загрузок локаций Дед Мани и в концовке Лонсам Роад, в последней битве в Храме Улисса -- вероятно, поможет версия 2.4

 

Но это следует проверять отдельно, так-как судя по всему, моя проблема с моим же решением -- линуксовая.

 

Всё остальное * мешать не будет.

Я как раз воспользовался информацией из этого поста и был приятно удивлен работой игры, но потом что-то пошло не так, я что-то по глупости накрутил, и у меня сломалась игра))
Да так, что даше после удаления всех этих оптимизаторов, у меня все-равно не работала даже новая игра, хочу вот еще раз попробовать, а случайно нет каких-нибудь интересных конфигов для DXVK и прочего? Был бы очень благодарен

[Trust Автор вопроса 452]

30 минут назад, Lord_Inqusitor сказал:

Я как раз воспользовался информацией из этого поста и был приятно удивлен работой игры, но потом что-то пошло не так, я что-то по глупости накрутил, и у меня сломалась игра))
Да так, что даше после удаления всех этих оптимизаторов, у меня все-равно не работала даже новая игра, хочу вот еще раз попробовать, а случайно нет каких-нибудь интересных конфигов для DXVK и прочего? Был бы очень благодарен

Мне в 18 часов по Берлину привезут малёх пива и сигарет, я соберусь, и запакую тебе конфиги

 

Можешь ещё попробовать такую тему:
Dusty Distance Redone (на 99 дальности) + FogCulling -- оно немножко улучшает в такой связке производительность.

Ещё в моём конфиге вписан FOV 60 -- тоже для усиления производительности.

И есть ещё хороший мод Performance Of Titans

[Trust Автор вопроса 452]

И из новья -- Cell Offset Generator

[Lord_Inqusitor 8]

8 минут назад, Trust сказал:

Мне в 18 часов по Берлину привезут малёх пива и сигарет, я соберусь, и запакую тебе конфиги

 

Можешь ещё попробовать такую тему:
Dusty Distance Redone (на 99 дальности) + FogCulling -- оно немножко улучшает в такой связке производительность.

Ещё в моём конфиге вписан FOV 60 -- тоже для усиления производительности.

И есть ещё хороший мод Performance Of Titans

Спасибо, буду ждать!)

[Trust Автор вопроса 452]

22 часа назад, Lord_Inqusitor сказал:

Спасибо, буду ждать!)

https://drive.google.com/file/d/1wq6vi1xIFrW98DS88C0KuiY94Q6mYrp1/view?usp=sharing

 

ЭТО АРХИВ ДЛЯ_ИЗУЧЕНИЯ!!! НЕ ЗАМЕНЯЙ ФАЙЛЫ БЕЗДУМНО!!!

ИЗУЧИ КОНФИГИ, И Я ОТВЕЧУ НА ВСЕ ТВОИ ВОПРОСЫ.

[Trust Автор вопроса 452]

22 часа назад, Lord_Inqusitor сказал:

Спасибо, буду ждать!)

ФАЙЛ НАХОДИТСЯ НА ГУГЛО-ПРОВЕРКЕ,

И ПОКА НЕДОСТУПЕН НИКОМУ КРОМЕ МЕНЯ.

[Trust Автор вопроса 452]

В 20.12.2025 в 13:04, Lord_Inqusitor сказал:

Спасибо, буду ждать!)

Можешь скинуть мне в ЛС свой контакт Телеграма?

 

Я попытаюсь тебе выслать все конфиги в архиве, без бинарников. -- Проверка файлов на них аггрится очень и не даёт переслать

[Lord_Inqusitor 8]

7 минут назад, Trust сказал:

Можешь скинуть мне в ЛС свой контакт Телеграма?

 

Я попытаюсь тебе выслать все конфиги в архиве, без бинарников. -- Проверка файлов на них аггрится очень и не даёт переслать

Да, сейчас в лс напишу

[Lord_Inqusitor 8]

9 минут назад, Trust сказал:

Можешь скинуть мне в ЛС свой контакт Телеграма?

 

Я попытаюсь тебе выслать все конфиги в архиве, без бинарников. -- Проверка файлов на них аггрится очень и не даёт переслать

Вообще обычно я запаковываю архив под паролем, и шифрую имена файлов, тогда по идее не забанит гугл
 

 

Спойлер

 

Изменено 21 декабря, 2025 пользователем Lord_Inqusitor