Инсталяция - при активации в нексусе отсортируйте данный мод в самый низ (т.е. сделайте его самым "главным" ) иначе другие моды (спринг клеаринг, например) перекроют. Если это не поможет - проверте точно ли все переписалось . Вцелом, чем больше модов стоит/стояло (отключить esp - мало надо отсутствие чужих ini, отсутствие непакованных моделей деревьев и пр. от других модов ) тем больше вероятность что что-то пойдет не так.
З.Ы. На счет "не попасть в фар-харбор", самый простой способ ini строчка bBorderRegionsEnabled=0убирает непроходимые краевые границы с карт вообще, как класс. => в Resmod.INI, в раздел [General] вписываем эту строчку
Дополненный до всех комбинаций установок DLC (включая вол-теч) архив прежнего варианта субмода-ускорителя (включая вол-теч). Плюс новый вариант, работающий немного по другому принципу. С патчем 1.7.12 не дает опустится ниже 20 fps правда не без последствий - динамически режет объекты в т.ч. LOD. Учет DLC - наборный отдельными файлами. Подробности внутри - pdf. http://koavia.com/n1/fo4/FO4_resmd_fast2.zip
По размерам деревьев - одно замечание, на станции Бэдфорд, северный сарай, дерево 8F6F2 перекрывает доступ к ящику 8EAD7. На него дает квест скриптор на поиск артефактов. Сейчас, если его масштаб поменять с 2 до 1 - получается самое то.
Вообще "правильный" путь описан в (печка от которой надоть плясать) http://www.creationkit.com/fallout....erences Т.е. нужно последовательно построить пре-комбайн а затем пре-виз для всего Содружества. Ток это просто неподъемная задача: - Весь корень лежит в том что СК заточен на изменение пре- для нескольких ячеек, но никак всего мира типа Содружества. - Пре комбайн можно построить для всего мира - команда в СК есть. Ток нужно 24 ГБ мозгов на борту, иначе это превращается в постоянный своп на диск и 18 часов молотилова (у меня с 8 ГБ). Получается нечто, например, все объекты которые можно разобрать (есть соответствующий COBJ). Т.е. если, например, SOBJ:106D95 определяет списком FLST:106D8D в числе прочих деревьев клен STAT:4A073, то по всему Содружеству произведенные от него REFR (1642 штуки) не будут включены в пре-комбайн. -Пре-виз команда есть как для ячейки, так и загруженной!?? (вместо видимой) области (что мало применимо) но для мира - нет. Те нужно РУКАМИ перебирать ВСЕ опорные для пре-виз ячейки (одна на 9 ячеек, поле RVIS у записи CELL). -Вне сомнения эта область модификаций в CK сильно отличается от инструментов применяемых беседкой (исходя из анализа изменений вносимых DLC)
-Если лимит превышен - ни чего не происходит (в игре). Это отвлеченная цифирь - чем выше она у файла субмода - тем меньше ячеек было запаковано при компиляции файла и требуется более мощный комп для игры. Т.е. попробовал один, туго идет - взял меньший и наоборот. -В городе пакованные ячейки - Вы видите обе модели и ванильную и ресурректа - в основном для деревьев, но вообще для всех моделей, что переопределены ресурректом - иначе их не будет видно вообще - будет одна ванила. Про длц неправильно написал, да, не подумавши, так долго крутился с оптимизаций, что и забыл про это - совместимость нужна только для субмода.
Фиолетовый цвет - неполная обработка SCOL объектов - коллекций объектов. Наблюдал такое - попробуй опции вFallout4Custom.ini : [Archive] sResourceDataDirsFinal= bInvalidateOlderFiles=1 (Дом с плющом это коллекция из нескольких статических объектов, без инвалидации сборка результирующей модели идет для каждого плагина в отдельности, а затем на них накладывается текстуры. С инвалидацией - сборка только после того как все плагины будут загружены. Дом это коллекция, состоящая, грубо, из дома и плющей - в моде дом имеет старую модель, а плющи новую - в итоге без инвалидации плющ имеет старую модель и игра не знает как на нее наложить текстуру т.к. она предназначена для новой модели. С инвалидацией - в сборку попадет новая модель и глюк пропадает.)
Белые (серебристые лужи) я наблюдаю постоянно - это шейдер не правильно работает - это ночное отображение лужи - блеск в лунном свете - как исправить, кроме как посредством перезагрузки игры - х.з. Вообще такое у меня бывает через 3-4 часа игры и означает что через несколько десятков минут игра вывалится в винды с ошибкой видеодрайвера - очевидно, что это происходит из-за утечки памяти, которая начинает наползать видео данные. Поскольку у меня стоит скрипт-экстендер с полудюжиной модов под него - на 3 часа устойчивой работы грех жаловаться.
Вот, сочинил "ускоритель" для города и помещений. Вцелом можно играть. Заодно создает совместимость мода с автомотроном и харбором, с ваулт - нет, я его не купил. Полное описалово внутри (pdf). http://koavia.com/n1/fo4/FO4_resmd_fast.zip
Полу-ручная: 1. Содержимое папки DATA в архиве скопировать в папку DATA игры. 2. В NMM на закладке Plugins найти Resmod.esp и поставить против него галку.
Чтобы совсем FPS не садило надо манипулировать с группировкой (precobinating) объектов. Группированные ( прекомбинированные) объекты в игре обсчитываются как единое целое, что резко увеличивает производительность . Правила следующие. - не юзать bUseCombinedObjects=0. Принудительно разбивает все группы, что резко просаживает скорострельность. - добавляемые/изменяемые объекты к/в уже существующим CELL (читай в fallout4.esm) работают по следующему правилу если переопределен хотя бы один объект который ранее (в более ранней по загрузке esp/esm) был определен в форме CELL\XCRI (см при помощи FO4edit) то массив XCRI (precombined meshes, группированных объектов) не действует (инвалидируется) для всей ячейки. И наоборот, если некое последующее изменение в объектах не затрагивает списка XCRI - происходит автоматическое переформирование XCRI с учетом вннесенных ранее изменений. Пример. Возъмем ячейку CELL DD1B "POICC06" - северо-восточная оконечность Сэнкчюри острова - не очень далеко но вне поселения. В голой ваниле тестируем ячейку на группировку: -Попытка в консоли ткнуть на любой статичный объект не приводит к захвату его id. -команда tb не приводит к отображению границ при нахождении в выбранной ячейке. Вывод - статичные объекты в ячейке сгруппированы и производительность высокая.
Возьмем ствол дерева 273с7 и маштабируем его с 0.95 до 3.95. Типа так нужно сделать в моде. Получаем патч mod.esp. Неважно чем его создали f04edit или китом, использовали ли в ките переформирование группировки(World>PreCombine Geometry ) - Ячека "распустится" на отдельные объекты т.к. в fallout4.esm 273с7 содержится в XCRI ячеки DD1B за номером 13. Можно выцедить id статичного объекта и при tb видны границы. Чем больше объектов было группировано в ячейке "до" - тем большие торомоза возникнут, вплоть до падения видеодрайвера.
Теперь группируем ячейку "взад". Берем любой интерактивный объект (что можно открыть, пнуть, взорвать и т.п.), из этой, правленой ячейки. Здесь, например, чемодан, на другом берегу 6499b. И формируем второй патч mod_g.esp c переопределением этого чемодана, ничего с ним делать не нужно просто он должен быть во втором патче, и в этом патче не должно быть объектов из XCRI. Признаки пригодности объекта к "иницализации" группировки: - объект видим - на него нет ссылок (fo4edit>Build reference info, пустая закладка ссылок для объекта). В итоге - при запуске с двумя патчами, получаем ячейку с большим стволом и при том сгруппированную.
ЗЫ для того чтобы spring clearing mod полноценно работал с этим модом нужно его "опустить" до esp (переименовать и убрать флаг esm в заголовке) и поставить загрузкой после данного мода. Работает с ячейками он как описано выше - распускает группирование в ячейках на объекты. Ток объектов переопределено там, лишних - тьма и маленькая тележка... Т.е. если данный мод в поселении изменяет только деревья которые можно было разобрать - интерактивные объекты, то он одновременно и "группирует" ячейку блокируя "росспуск" от spring clearing, грузя sc после данного мода Вы обходите блокировку.
Опупенно! Ток это не дремучий лес, а очень здорово получившаяся заросшая свалка строительного мусора.
По текстурам земли - часть, конечно, пропущена - просто режет глаз "идеальная" куча битого кирпича среди зарослей, обрывки бумаги в луже.
Но это мелочи. Главный вопрос - зачем "распущены" группы объектов, причем глобально (bUseCombinedObjects=0) . С такой установкой некоторые "внутренние" локации не проходимы в принципе потому как там тучи мелких объектов - любой комп просто "умрет" - либо слайд-шоу либо падение видеодрайвера. Убрал - (файл Resmod.INI, bUseCombinedObjects=1) - все выглядит точно также. Или нет?
На счет моделей растительности - можно нагенерить туеву хучу моделей при помощи speed tree (эту технологию юзает движок BigWorld - если пошукать вокруг WoT можно раздобыть набор генерилок-плагинов для 3D редакторов) - там есть "скусный" раздельчик - конвертировать нативный speed-tree объект - получаем оттекстурированный меш, скелет и боундинг меш (полный состав не для всех редакторов) - т.е. все что нужно для того чтобы запихнуть куда угодно.
Мы Вконтакте
Инсталяция - при активации в нексусе отсортируйте данный мод в самый низ (т.е. сделайте его самым "главным" ) иначе другие моды (спринг клеаринг, например) перекроют. Если это не поможет - проверте точно ли все переписалось . Вцелом, чем больше модов стоит/стояло (отключить esp - мало надо отсутствие чужих ini, отсутствие непакованных моделей деревьев и пр. от других модов ) тем больше вероятность что что-то пойдет не так.
З.Ы. На счет "не попасть в фар-харбор", самый простой способ
ini строчка bBorderRegionsEnabled=0убирает непроходимые краевые границы с карт вообще, как класс.
=> в Resmod.INI, в раздел [General] вписываем эту строчку
Плюс новый вариант, работающий немного по другому принципу. С патчем 1.7.12 не дает опустится ниже 20 fps правда не без последствий - динамически режет объекты в т.ч. LOD. Учет DLC - наборный отдельными файлами.
Подробности внутри - pdf.
http://koavia.com/n1/fo4/FO4_resmd_fast2.zip
Вообще "правильный" путь описан в (печка от которой надоть плясать)
http://www.creationkit.com/fallout....erences
Т.е. нужно последовательно построить пре-комбайн а затем пре-виз для всего Содружества. Ток это просто неподъемная задача:
- Весь корень лежит в том что СК заточен на изменение пре- для нескольких ячеек, но никак всего мира типа Содружества.
- Пре комбайн можно построить для всего мира - команда в СК есть. Ток нужно 24 ГБ мозгов на борту, иначе это превращается в постоянный своп на диск и 18 часов молотилова (у меня с 8 ГБ). Получается нечто, например, все объекты которые можно разобрать (есть соответствующий COBJ). Т.е. если, например, SOBJ:106D95 определяет списком FLST:106D8D в числе прочих деревьев клен STAT:4A073, то по всему Содружеству произведенные от него REFR (1642 штуки) не будут включены в пре-комбайн.
-Пре-виз команда есть как для ячейки, так и загруженной!?? (вместо видимой) области (что мало применимо) но для мира - нет. Те нужно РУКАМИ перебирать ВСЕ опорные для пре-виз ячейки (одна на 9 ячеек, поле RVIS у записи CELL).
-Вне сомнения эта область модификаций в CK сильно отличается от инструментов применяемых беседкой (исходя из анализа изменений вносимых DLC)
-В городе пакованные ячейки - Вы видите обе модели и ванильную и ресурректа - в основном для деревьев, но вообще для всех моделей, что переопределены ресурректом - иначе их не будет видно вообще - будет одна ванила.
Про длц неправильно написал, да, не подумавши, так долго крутился с оптимизаций, что и забыл про это - совместимость нужна только для субмода.
Фиолетовый цвет - неполная обработка SCOL объектов - коллекций объектов. Наблюдал такое - попробуй опции в Fallout4Custom.ini :
[Archive]
sResourceDataDirsFinal=
bInvalidateOlderFiles=1
(Дом с плющом это коллекция из нескольких статических объектов, без инвалидации сборка результирующей модели идет для каждого плагина в отдельности, а затем на них накладывается текстуры. С инвалидацией - сборка только после того как все плагины будут загружены. Дом это коллекция, состоящая, грубо, из дома и плющей - в моде дом имеет старую модель, а плющи новую - в итоге без инвалидации плющ имеет старую модель и игра не знает как на нее наложить текстуру т.к. она предназначена для новой модели. С инвалидацией - в сборку попадет новая модель и глюк пропадает.)
Белые (серебристые лужи) я наблюдаю постоянно - это шейдер не правильно работает - это ночное отображение лужи - блеск в лунном свете - как исправить, кроме как посредством перезагрузки игры - х.з. Вообще такое у меня бывает через 3-4 часа игры и означает что через несколько десятков минут игра вывалится в винды с ошибкой видеодрайвера - очевидно, что это происходит из-за утечки памяти, которая начинает наползать видео данные. Поскольку у меня стоит скрипт-экстендер с полудюжиной модов под него - на 3 часа устойчивой работы грех жаловаться.
Полное описалово внутри (pdf). http://koavia.com/n1/fo4/FO4_resmd_fast.zip
1. Содержимое папки DATA в архиве скопировать в папку DATA игры.
2. В NMM на закладке Plugins найти Resmod.esp и поставить против него галку.
Правила следующие.
- не юзать bUseCombinedObjects=0. Принудительно разбивает все группы, что резко просаживает скорострельность.
- добавляемые/изменяемые объекты к/в уже существующим CELL (читай в fallout4.esm) работают по следующему правилу если переопределен хотя бы один объект который ранее (в более ранней по загрузке esp/esm) был определен в форме CELL\XCRI (см при помощи FO4edit) то массив XCRI (precombined meshes, группированных объектов) не действует (инвалидируется) для всей ячейки. И наоборот, если некое последующее изменение в объектах не затрагивает списка XCRI - происходит автоматическое переформирование XCRI с учетом вннесенных ранее изменений.
Пример. Возъмем ячейку CELL DD1B "POICC06" - северо-восточная оконечность Сэнкчюри острова - не очень далеко но вне поселения.
В голой ваниле тестируем ячейку на группировку:
-Попытка в консоли ткнуть на любой статичный объект не приводит к захвату его id.
-команда tb не приводит к отображению границ при нахождении в выбранной ячейке.
Вывод - статичные объекты в ячейке сгруппированы и производительность высокая.
Возьмем ствол дерева 273с7 и маштабируем его с 0.95 до 3.95. Типа так нужно сделать в моде. Получаем патч mod.esp. Неважно чем его создали f04edit или китом, использовали ли в ките переформирование группировки(World>PreCombine Geometry ) - Ячека "распустится" на отдельные объекты т.к. в fallout4.esm 273с7 содержится в XCRI ячеки DD1B за номером 13. Можно выцедить id статичного объекта и при tb видны границы. Чем больше объектов было группировано в ячейке "до" - тем большие торомоза возникнут, вплоть до падения видеодрайвера.
Теперь группируем ячейку "взад". Берем любой интерактивный объект (что можно открыть, пнуть, взорвать и т.п.), из этой, правленой ячейки. Здесь, например, чемодан, на другом берегу 6499b. И формируем второй патч mod_g.esp c переопределением этого чемодана, ничего с ним делать не нужно просто он должен быть во втором патче, и в этом патче не должно быть объектов из XCRI. Признаки пригодности объекта к "иницализации" группировки:
- объект видим
- на него нет ссылок (fo4edit>Build reference info, пустая закладка ссылок для объекта).
В итоге - при запуске с двумя патчами, получаем ячейку с большим стволом и при том сгруппированную.
ЗЫ для того чтобы spring clearing mod полноценно работал с этим модом нужно его "опустить" до esp (переименовать и убрать флаг esm в заголовке) и поставить загрузкой после данного мода. Работает с ячейками он как описано выше - распускает группирование в ячейках на объекты. Ток объектов переопределено там, лишних - тьма и маленькая тележка... Т.е. если данный мод в поселении изменяет только деревья которые можно было разобрать - интерактивные объекты, то он одновременно и "группирует" ячейку блокируя "росспуск" от spring clearing, грузя sc после данного мода Вы обходите блокировку.
По текстурам земли - часть, конечно, пропущена - просто режет глаз "идеальная" куча битого кирпича среди зарослей, обрывки бумаги в луже.
Но это мелочи. Главный вопрос - зачем "распущены" группы объектов, причем глобально (bUseCombinedObjects=0) . С такой установкой некоторые "внутренние" локации не проходимы в принципе потому как там тучи мелких объектов - любой комп просто "умрет" - либо слайд-шоу либо падение видеодрайвера. Убрал - (файл Resmod.INI, bUseCombinedObjects=1) - все выглядит точно также. Или нет?
На счет моделей растительности - можно нагенерить туеву хучу моделей при помощи speed tree (эту технологию юзает движок BigWorld - если пошукать вокруг WoT можно раздобыть набор генерилок-плагинов для 3D редакторов) - там есть "скусный" раздельчик - конвертировать нативный speed-tree объект - получаем оттекстурированный меш, скелет и боундинг меш (полный состав не для всех редакторов) - т.е. все что нужно для того чтобы запихнуть куда угодно.