Лидеры

Там есть сейчас небольшая ошибка в скрипте. Все кто нужно - о проблеме уже знают, но вот заплатка актуальная. BookToCapsHotfix.esp

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