Атаман

Не помню)))

Могу ошибиться командами на консоли, так что попробуй на тестовом сохранении: update3d - перезагрузить модель и легонько сбросит поведение на ресет (поверхностно) resetai - совственно перезапустит ей мозг Если не заработает - поищи, не перезаписывает ли у тебя её ничего из других модов и убедись в FNVedit в этом. Если нет, то посмотри какую модель поведения она использует. Если foolhardy - попробуй сменить на "brave" и там ещё можно выставить флаг мол защищает союзников П.С. Иногда они так делают, когда кончились патроны или оружие которое ты им пихаешь не подходит им по навыкам и такое

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

ЗДЕСЬ АНКЛАВ. Стальные трусы подтверждаем. Сертифицированы. Лозунги - нет. Продолжайте обсуждение. Мы смеёмся и записываем. God bless America.

СООБЩЕНИЕ ПРИНЯТО. Очередной гражданин Пустоши объявил себя будущим Республики. Стандартная ситуация. Братство уже слышало это перед падением Старого Мира, перед каждой войной и перед каждым "расцветом". Республика любит лозунги. Братство - рабочие лазеры. Ты верь. Мы - проверим. Ad Victoriam.

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

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

Короче... Если рассматривать ситуацию строго с технической точки зрения, то 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 и осознанное использование автолута, без попыток компенсировать фундаментальные ограничения движка дополнительными костылями.

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