Объединение несколько плагинов в один с помощью FNVEdit

Открываем FNVEdit перед нами список установленных плагинов

Выбираем нужные плагины для объединения. В данной статье я решил объединить 4 .esp в один из мода:
"Change the weapon for partners." v 1.0
Мне не понравилось, что мод разбит на 4.esp выполняющих по сути одно и тоже.
Убираем галочки с ненужных файлов ПКМ (правая кнопка мыши) >> Select None и выбираем 4 файла:
Cass.esp, CrecBoon.esp, Veronica.esp, Raul.esp, выбрали жмем OK немного подождем пока идет загрузка и
Если все нормально загрузилось, увидим вот это:

Открываем файл, в который мы будем переносить данные других файлов и файл донор.
Для этого жмем на (+) рядом с файлом и видим еще категории, тоже раскроим их
(т. к подкатегорий у нас немного можно раскрыть их все, если бы у нас мод был бы более объемным и сложным стоило
открывать категории одну за другой).
В данном случае я буду переносить данные из Cass.esp в Veronica.esp
Раскрыли и увидели вот это

Нам надо скопировать все из Cass.esp в Veronica.esp, но мы видим, что Veronica.esp нет подкатегории Armor и нам необходимо ее создать.
Щелкаем ПКМ на Veronica.esp находим Add (добавить) находим в выпадающем списке ARMO – Armor и щелкаем на нем.
У нас создалась новая категория Armor, но она пока еще пуста и в нее надо скопировать строку Экипировка Касса
Делается это так, сначала скопируем FormID (ПКМ на Экипировка Касса выбрать Change FormID и в открывшемся окне скопировать FormID),
После этого переходим к Veronica.esp >> Armor >> ПКМ >> Add >> ARMO – Armor >> ПКМ >> Вставить
У нас добавилась новая строка, и она красная (красный цвет признак того, что есть различия в ресурсах с одинаковым FormID), наша же задача
Убрать эти различия. Щелкаем на то, что мы добавили и видим:

Четыре столбца 1-й в данной статье не рассматривается, 2-й FalloutNV.esm изменить его нельзя даже можете не пытаться,
3-й Cacc.esp который мы копировали и 4-й Veronica.esp с которым мы сейчас будем работать.
Как наверно Вы уже заметили в Veronica.esp почти все строки или пустые или неверные параметры.
Будем исправлять. Как? Очень просто, идем сверху в низ, и первое видим несоответствие: EDIT – EditorID исправляем для этого
Надо схватить нужную строчку (появится (+) и перетянуть в соседнюю, осторожно не промахнитесь), потом следующую
Экипировка Касса (Вы наверно заметили, что одинаковые строки приобретают зеленый цвет, и наша задача сводится к тому, чтоб все позеленело).
Некоторые строки можно таскать целыми блоками, к примеру, BMDT – Biped Data

Схватите пустую верхнюю строчку, и перетащите, вместе с ней перетащатся связанные строки.
Если все сделали правильно, то окно должно приобрести такой вид:

Далее работаем с Non-Player Character, т. к в Veronica.esp он уже есть то создавать нам его не понадобится,
А просто надо добавить новый ресурс Касс, делается все также копируем FormID ПКМ >> Change FormID >> Копировать
и вставляем ПКМ >> Non-Player Character >> Add >> NPC_ Non-Player Character >> Вставить.
Далее синхронизируем также как делали с предыдущем ресурсом (Методом перетаскивания).
Ну и осталось скопировать Weapon (Оружие). Объяснять не буду делается все точно так же.
Когда с Cass.esp закончили, начинаем работу со следующим файлом.
В итоге у нас должно получится следующее:

Теперь сохраним (в процессе редактирования утилита будет предлагать Вам сохранится

, дело Ваше принять предложение или нет,
Но я все-таки советую последовать предложению и сохраниться, особенно в первое время пока не набьете руку,
сохранения не перезаписываются, а добавляются с датой и временем сохранения. В любой момент можно откатится назад.)
Сохраняемся, нажав в верхнем правом углу на «Х»

Жмем ОК.
Теперь можно переименовать файл как Вы желаете, я его переименовал в All partners.esp.
Удаляем ненужные файлы.
Все. Надеюсь, эта небольшая статья смогла вам помочь.
Строго не судите и сильно не закидывайте меня помидорами, т.к. это первая моя статья и я только учусь.
Рад любым вопросам и пожеланиям, пишем и обсуждаем.
Спасибо!

Сначала об "отвязке" мастер-файла от плагина.

Для примера возьму свой плагин "Питт для Вегаса" В нем есть файл-еспешник ThePittNV_Fix.esp у которого в мастерах числится файл ThePittNV.esm Будем отвязывать этот мастер от еспешника.

Запускаем FNVEdit. После загрузки откроется окно выбора файлов, в котором галочками будут отмечены те файлы, которые последний раз загружались в игру. То есть - те, что были отмечены ранее в мод-менеджере NVMM. Чтобы не тратить время и не снимать по-одиночке все ненужные галочки - кликаем ПКМ в любом месте этого окна и выбираем строчку "Select None". Все галочки снимутся. Отмечаем нужный еспешник галочкой и жмем ОК.

Плагин загрузится в редактор и вместе с ним автоматически загрузится его "родители": основной мастер-файл игры FalloutNV.esm (он будет загружаться при загрузке ЛЮБОГО вегасовского мода) и второй родительский - ThePittNV.esm .Раскрываем плюс напротив названия нашего плагина, чтобы получить доступ к разделам мода и переходим на строчку File Header (заголовок файла). В правой половине окна раскроются параметры этой строки. Мы видим, что у данного еспешника в разделе Master Files имеются два мастер-файла. Как говорилось выше - это FalloutNV.esm и ThePittNV.esm Нам нужно удалить второй Питтовский мастер. Ставим курсор на заголовок Master File для второго мастера и жмем ПКМ. В выпавшем контекстном меню выбираем строчку Remove. Ненужный мастер-файл будет удален.

Точно таким же образом удаляются все родительские файлы для любого плагина: мастера и, сдуру назначенные вместо мастеров еспешники. Почему сдуру - потому что еспешник НЕ МОЖЕТ быть мастером для другого еспешника. И когда один еспешник с помощью "кувалды" вбивают другому еспешнику в качестве мастера - в итоге возникает куча багов у малоопытных мододелов. Подробно об этом рассказывалось на форуме Modgames.net

Раз зашел разговор о "привязке", т.е. назначении какому-либо еспешнику дополнительного мастера - опишу и этот процесс.

Грузим необходимый еспешник в редактор, переходим в строку заголовка File Header и в правой половине окна в строке Master Files кликаем ПКМ. В контекстном меню выбираем строчку Add (добавить)

У нас появится новая строчка в списке мастеров с пустой записью. Кликаем ПКМ на строке MAST - Filename и в контекстном меню выбираем строчку Edit (правка).

В открывшемся окне пишем без ошибок название того мастер-файла, который мы дополнительно хотим назначит этому еспешнику. Пишем не только имя, но и указываем расширение: Esm или Esp. Но с учетом того, что говорилось выше о последствиях назначения еспешнику другого еспешника - лучше этого не делать. А назначать, как положено - только мастер-файлы ESM. Если уж возникла острая необходимость для работы использовать в качестве мастера-файла другой еспешник - то лучше всего предварительно этот еспешник сделать мастер-файлом ESM.

Как сделать из мастер-файла ESМ файл-плагин ESР (и наоборот) говорилось много раз.

Есть куча способов, но самый простой - это через FNVEdit. Еще раз напомню, как это делается. Загружаем в редактор нужный мастер-файл и опять же переходим в раздел File Header. В правой половине окна делаем клик правой кнопки мыши на строчке Record Flags и в выпавшем контексте выбираем строчку Edit.

В открывшемся новом окне убираем галочку ESM . Жмем ОК. Закрываем редактор. При закрытии будет предложено сохранить изменения. Сохраняем.

ЗАТЕМ ИДЕМ В ПАПКУ DATA ИГРЫ И МЕНЯЕМ РАСШИРЕНИЕ У ЭТОГО ФАЙЛА!!! (у Вас должно быть в свойствах папки включено отображение расширений для зарегистрированных типов файлов) Меняем расширение с ESM на ESP. Потому что мастер-файл должен иметь расширение esm , файл-плагин - расширение esp. Во-первых: таков порядок, установленный Беседкой. Во-вторых: это позволит избежать путаницы, непонимания и возникновения непредвиденных "заморочек" у других мододелов, использующих этот плагин. В-третьих: позволит избежать возможных багов в игре. Меняем расширение и теперь наш мастер стал еспешником.

Чтобы сделать из еспешника мастер-файл - выполняем ту же операцию.

Заходим в File Header. Затем на строчку Record Flags и отмечаем галочку ESM. Сохраняем. Меняем расширение с esp на esm. Теперь бывший еспешник стал полноценным мастер-файлом.

Ну а теперь разговор о слиянии еспешника с мастер-файлом.

Есть разные способы и даже программы, которые делают это автоматически (правда за результат работы таких программ ручаться не могу). А можно делать всё руками через FNVEdit. Правда, если файл-еспешник, который нужно слить с мастером, будет большого объема - то работа займет довольно много времени. Работа, в принципе, не сложная, но очень нудная. Опять же, для примера возьму свой мод-портацию "Питт для Вегаса". Мод состоит из мастер-файла esm, в котором содержится вся база данных этого мода и файл-плагина esp, в котоый внесены некоторые поправки к мастеру. В частности - подправлены некоторые параметры оружия и добавлены некоторые объекты в локации.То есть - данный еспешник является фикс-плагином, устраняющим некоторые недоделки мастера. А поскольку еспешник грузится в игру всегда только после своего мастера - именно его данные и будут использоваться игрой.

Загружаем в редактор файл ThePittNV_Fix.esp и начинаем по очереди раскрывать плюсики его разделов. Для примера - раздел Оружия (Weapon). Как видно на скриншоте - этот плагин затрагивает параметры пяти "оружий". Строчки, подсвеченные зеленым цветом, означают, что расхождений с оригиналом нет. А вот строчки, подсвеченные желтым означают, что между мастер-файлом и плагином имеются различия. Например, Стальной кастет имеет отличия по параметрам DNAM - изменен урон и уровень навыка (на скриншот не попало, но это и не важно) Чтобы "сравнять показатели" ставим в правой половине окна курсор мыши на желтую строчку, зажимаем левую клавишу мыши и перетягиваем строчку из столбца от ThePittNV_Fix.esp в столбец к ThePittNV.esm

Если после этой операции у нас в левой половине окна строчка "Стальной кастет" стала зеленой - значит больше никаких расхождений с оригиналом нет. Если осталась по-прежнему желтой - то в правой части окна пролистываем параметры этого кастета вниз и ищем следующую желтую строчку. Если нашли - перетягиваем вышеописанным способом из столбца плагина в столбец мастера. И так до тех пор, пока кастет не "позеленеет".

Аналогично поступаем с остальным оружием. Если кроме оружия, плагин меняет объекты в других разделах - переходим в такой раздел и копируем столбцы.До позеленения...

Вышесказанное касалось тех объектов, которые присутствуют и в мастер-файле и в плагине. Но бывает и так, что плагин вносит НОВЫЕ объекты, которых нет в мастер-файле. Новую броню, например (что-то я, как "Паук"-Троицкий, стала часто говорить "например") или новый объект в интерьере. Или же нужно перенести данные из одного мода в другой. В таком случае - такой объект целиком копируется из плагина в мастер.

Например (тьфу!!!) на скриншоте видно, что в некой ячейке расположен новый коллизионный маркер, которого не было в основном мастере.


То, что это совершенно новый объект, видно по его "бесцветности" Он не закрашен ни зеленым, ни желтым цветом, то есть - у него нет аналога ни в родительском мастер-файле ThePittNV.esm, ни в основном FalloutNV.esm . Можно просто скопировать все данные этого объекта в мастер, но тут мааленький нюанс. Форм-айди этого объекта начинается не на те же цифры, что форм-айди всех объектов в родительском мастере.
Поясню.
В данный момент в редактор загружено всего три файла: основной мастер-файл игры FalloutNV.esm, а также ThePittNV.esm и его фикс-плагин ThePittNV_Fix.esp.
У FalloutNV.esm форм-айди начинаются на 00, поскольку он "основной и неприкасаемый".
У файла ThePittNV.esm форм-айди начинаются на 01, поскольку он загружен первым после Б-га.
А у ThePittNV_Fix.esp форм-айди начинаются на 02, поскольку он загружен вторым. (естественно, если в редактор или игру загружено другое количество файлов - начала их форм-айди сменятся в зависимости от порядка загрузки.)
И если просто скопировать объект из этого еспешника в его родительский мастер - то в мастере он будет с форм-айди, начинающимся на 02, этакой "белой вороной" среди всех 01. Иногда это не вызывает никаких осложнений, но иногда, особенно если у пользователя установлено огромное количество модов, может так совпасть, что в результате переназначения айди в зависимости от порядка загрузки, эта "белая ворона" совпадет с совершенно другим объектом из другого мода. Тут-то и возможен глюк, конфликт разных модов. Поэтому лучше всего все объекты в одном моде привести "к общему знаменателю". То есть - чтобы все объекты мода имели одинаковое начало своих форм-айди.

Для этого сначала раскрываем ветки разделов родительского мастера ThePittNV.esm и кликаем ПКМ на любом разделе, ну хоть на разделе Активаторов. В выпавшем контексте выбираем строчку Add.

Откроется окошко добавления нового объекта, в котором будут выставлены цифры - форм-айди этого будущего объекта. Выделяем их и копируем через Contrl+C. После этого жмем Отмена (Cancel). Эти манипуляции мы проделываем для того, чтобы не подбирать "вручную" новый форм-айди для нашего объекта в еспешнике, а взять готовый, незанятый айди.


Возвращаемся к еспешнику, выделяем курсором строчку с новым объектом, которому будем менять форм-айди и делаем ПКМ. В контекстном меню выбираем строчку Change FormID

Откроется маленькое окно, в котором будет высвечено ТЕКУЩЕЕ форм-айди этого объекта. Удаляем его и через Contrl+V вставляем скопированный ранее из мастера "незанятый" пока никем форм-айди и жмем ОК.

Видим, что шрифт на строчке изменился на жирный. Это значит, что в параметры данного объекта внесены какие-то изменения. Но строчка по-прежнему бесцветная. Теперь её надо скопировать из еспешника в мастер-файл. Ставим курсор на эту строку, затем ПКМ и в контексте выбираем строчку Copy as override into...

Откроется окно, в котором будет предложено в какой из загруженных в редактор и доступных для копирования перенести эти данные. Или же скопировать их в совершенно новый есп. Выбираем, естественно, нужный нам мастер ThePittNV.esm и жмем ОК

Теперь видим, что данная строка позеленела. То есть - у неё (у этого объекта) в родительском мастер-файле появился полный аналог.

Повторяем все манипуляции для остальных найденных новых объектов, пока не скопируем все из еспешника в мастер.Затем сохраняем плагин.
В редакторе нет отдельной кнопки сохранения, поэтому сохранится можно либо в процессе работы, когда выскакивает периодическое сообщение о сохранении, либо сохранится можно при закрытии редактора. В любом случае - в окне сохранения отмечаем только мастер ThePittNV.esm .

После окончание всей работы мы имеем мастер-файл ThePittNV.esm в которой перенесены все данные из еспешника ThePittNV_Fix.esp.
То есть, по сути - мы склеили мастер и плагин и этот плагин ThePittNV_Fix.esp больше уже не потребуется и его можно удалить с компа.

ЗЫ. Иногда при смене форм-айди может выскочить окошко с сообщением, что данный объект связан\используется другими объектами и будет выдан список таких объектов. Ничего страшного, отмечаем ВСЕ эти объекты галочками (ПКМ и строчка Select All) и дважды жмем ОК.

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

Небольшие корректировки к описанному в шапке, носящие принципиальный характер: я исхожу из того, что эта ветка для начинающих модостроителей, тк для остальных должно быть тривиальной операцией. Поэтому, все должно быть написано так, чтобы не привело к косякам у новичков, а тут есть ряд моментов.
Любые корректировки очереди мастеров через fo3edit/fnvedit должны осуществляться предельно продуманно ибо чревато.
1) Вручную удалять мастера можно только если он последний, а не из середины очереди. Все собственные formid модуля у которого проводятся подобные правки имеют ОТНОСИТЕЛЬНЫЕ смещения по отношению к очереди мастеров в headere. То есть: если например очередь: fallout3.esm; anchorage.esm; thepitt.esm и вы удалите мастера из середины списка то есть anchorage, то рефы внутри formid, которые задействуют ресурсы мастера собьются (в данном случае все что использует thepitt.esm). (надеюсь тут все понятно)
(в fo3edit/fnvedit еще есть script 'list record referencing specific plugin' по которому надо убедиться, что это собственно вообще допустимо)
=
2) Добавлять мастеры вручную в header через fo3edit недопустимо, тк это автоматом превратит все собственные записи в инжекты, которые при наложении на formid с мастером уровнем выше с идентичным номером превратятся в оверрайды. Причем почти наверняка произойдет наложение записей разных типов, это приведет к неработоспособности плагина. Например: у вас есть плагин мойплагин.esp (его адресация будет 02) использующий fallout3.esm (00); anchorage.esm (01). Вы хотите добавить еще мастер thepitt.esm, например запись в мойплагин.esp имеет formid 0x001000 (в данном случае это будет 02001000 тут питт еще не добавлен) и является placed object. В питте же тоже например есть собственная запись 0x001000, которая activator. Когда вы в свой плагин добавите мастер thepitt.esm вручную в header то запись собственная мойплагин.esp 02001000 превратится в инжект и тут же в оверрайд собственной записи thepitt.esm 0x001000. Будет каша мала.
=
3) Единственный корректный вариант делать ЭТО через гекк: прогружаете свой модуль как active соответственно, но при этом дополнительно щелкаете thepitt.esm для загрузки также (это еще когда его нет в мастер списке мойплагин.esp), производите формальную модификацию и сохраняетесь. Фокус в том, что гекк автоматом набивает в ваш плагин ВСЕ фактически прогруженные esmы, даже если вы оттуда не используете никакой ресурс. Этот момент надо учитывать в том числе, если не хотите, чтобы было внесено что-то лишнее.
=
4) Есть еще вариант и fo3edit: опять же, есть мойплагин.esp с мастерами fallout3.esm,anchorage.esm. На этапе начальной загрузки fo3edit также дополнительно отмечаете thepitt esm, затем заходите именно секцию плагина thepitt.esm куда-нибудь на минимальновзаимосвязанную запись например MISC (я это обычно использую), щелкаете на первое попавшееся правой кнопкой и 'copy as override', там укажите мойплагин.esp Потом можно будет увидеть, что все записи в мойплагин.esp станут болдом (жирный шрифт), это признак что прошла автоматическая перенумерация всех записей мойплагин.esp c УЧЕТОМ вновь добавленного НОВОГО мастера thepitt.esm (вот тут то как раз все будет нормально, инжекты не попрут) Хотя лично я не доверяю fo3edit тк этот автоматический renum идентичен скриптовому renum, а у него есть косяк: он иногда перенумеровывает не все, а иногда по два раза. Поэтому единственный валидный - только гекк.
=
5) Обязательств соответствия расширения плагина и его фактического состояния по флагу ESM в headere нет, это как минимум использует тот же fo3edit для masterupdate и даже являясь по расширению esp, но по флагу esm, что игрой, что редактором воспринимается как ESM. На masterupdate esp плагинах например того же косяка с разным цветом тела и головы вроде не наблюдается.
=
А теперь самое главное в том числе и Hellraiser почему я это сегодня ночью написал: сталкивался с этим и до этого, но пришлось встретится с косяком и в своем проекте. Например: есть moda.esm; modb.esm в третьем фолле которые используют все плагины dlc, соответственно очередь мастеров у них anchorage;thepitt;brokenstell;pointlookout;zeta И мастерил я свой esp частично срезая ненужное с этих самых модов moda.esm; modb.esm, добавлял мастеры в плагин корректировок по мере манипуляций не вручную в header, а через 'copy as override', правда в нем итоговая очередности dlc esmов оказалась совсем другой (то есть например zeta;anchorage;brokensteel;pointlookout;thepitt). Это был не один день работы, потом попробовал загрузить свой плаг в гекк, чтобы кое-что подрихтовать ... а он не загрузился. Просто в конце, не как бывает зависает или крешит, начал по черному глючить, то есть значок курсора с BUSY обратно превращается в нормальный после 100 загрузки, но в полях редактора не появляются записи. Вот и приплыли.
Cел, подумал, а давайка вручную очередь мастеров в header подправлю как у модов сборки (собственно как положено им быть), откорректировал, слетели внутренние ссылки на ресурсы esmов dlc, как написал выше.
-
В моей ситуации не пустить коту под хвост результат недельной чистки удалось только применив ход конем, увы, не думаю что получится в любой ситуации, так что лучше мастера добавлять именно через гекк. Вопхнуть мой плагин в него все-таки удалось (а не пускала именно разная очередность мастеров на двух файлах сборки (там было все как положено) и дополнительном плагине), провел формальную модификацию, сохранил. Вуаля, на плагине с некорректной очередностью все выправилось в положенный порядок и никакие внутренние рефы записей не сбились. Fo3edit/FnvEdit так делать не умеет.

PS То что приведены в качестве примера файлы третьего фаллоута надеюсь понятно что разницы нет никакой.
PSS Возможно все выше написано слегка сумбурно, извините, я не пейсатель.
-
PSSS И еще, более сложный косяк: используются moda.esm,modb.esm,modc.esm . Первый moda.esm список мастеров стандартный, fall3 и все dlc в положенном порядке. modb.esm ссылается на moda.esm но у него в мастер списке только fallout3.esm, anchorage.esm, thepitt.esm; modc.esm ссылается на moda.esm и на modb.esm и также имеет в своем списке все dlc + fall3.esm в правильном порядке.
=
Во-первых такая конструкция при определенных комбинациях не прогружалась в гекк, думал там глюк в записях пока не напоролся с откровенной непрогрузкой как выше.
А вот во-вторых: в самой игре происходили странноватые вещи с контентом принадлежащим именно modb.esm (очень долго описывать что, если кратко - такое впечатление что 'запинались' часть предельно прозрачных package, которым и глючить не было никаких оснований) у которого список esm был не полный, хотя чисто теоретически все должно было быть нормально.

Скачиваем http://yadi.sk/d/NmnWcoquDqWxd  это одиночный finalize cell  wasteland (-1,-5) он же вход перед мегатонной, с зелеными  navm все понятно. Нужен fo3edit 2.5.3 и fo3edit серии experimantal 3.0.31.0 (3.0.30.0 не  используем, он на подсекции pld2(again?) package все сносит).
Вышеуказанный файл прогрузите и там и там, расцветка в 2.5.3 другая, черный цвет означает - разница в записях есть, но содержимое суммарно идентично. (когда перепроверку navm делаю - всегда только его и использую)
Теперь в обеих версиях редактора переходите на запись например 5a7af и в поле справа щелкаем правой конкой и выбираем 'hide no conflict row', как ни странно но в разных редакторах увидите разный результат, в 2.53 останется пустое поле, а вот 3.0.31.0 так не умеет, останется список различающихся connection (самый нижний параметр подсекции navm).
-
Идем на navm 7638a (там проще всего объяснить) на fo3edit 3.0.31.0 не забываем снять галочку simple record для полного отображения подсекции navm.
Загружаемся через 3.0.31.0; hide no conflict row; останется всего лишь две 'различные записи'; отключаем hide no conflict row; смотрим
подсекция NVTR -> triangle 0; edges triangle 0
в fallout3.esm там стоит циферка 1 в плагине 0
-
triangle 1; edges triangle 1
в fallout3.esm цифра 0 в плагине 1
-
Они просто поменялись местами - именно это я называю флуктуацией.
Суть в том, что в этих самых edges указывается лишь ВНУТРЕННИЙ номер connection (по приписке справа от этих циферок 0 и1 в edges  видно
-
1(Triangle #305 in [NAVM:0002D1E1])(for...    в первом случае в fallout3.esm
0(Triangle #99 in [NAVM:0002D1E1])(for ... во втором случае в fallout.3sm
-
Как видно и в фолле и плагине несмотря на различие в номерах connection эти значения идентичны (те что за круглыми скобками). То есть: номера connection в конце каждаго NAVM и его значения имеют ИСКЛЮЧИТЕЛЬНО внутренний смысл данного навмеша, влияния на соседние навмеши connection оказывать не могут, они нужды только для адресации triangle в подсекции NVTR из нижнего списка connection, но не более. Помойму это и так видно.
-
ОЧЕНЬ ВАЖНЫЙ МОМЕНТ: как не спороть косяк и не перепутать навмеш с просто флуктуацией c тем, у которого действительно что-то изменилось - элементарно по вышеописанному, у них подсекции NVTR должны быть идентичны, если есть хоть одно различие - все, они уже разные (либо разница в любой другой подсекции). А то можно так наудалять вовсе не то. То есть если в 3.0.31.0 после hide no conflict row остается только раздел connection - это одинаковые. На brokenstell.esm мегабайт такого лишака.
-
Навмеш 2D1E1: очень хорошо что проскочило изменение подсекции NVGD для примера. Для ребьюлда навмешей ессно используется последняя версия гекка для фолла и соотв для вегаса. Такое будет встречаться нередко особенно на ванильных файлах - это переносить в исходный в соответствии с рекомендациями ребьюлда, это не косяк, просто изначальная ванилла что в фолле, что в вегасе сделана рукож... дилетантам из беседки, которые походу сами не ведали, что творили. То есть это - не косяк и случайная манипуляция гекка.
-
Случай: обкатывал я как-то fallout3.esm через гекк и случайно заметил по editor warning, что в одной ячейке не подведен навмеш к двери, зашел в ячейку, подтянул пару точек навм к двери и нажал finalize, чтобы под дверью зажегся triangle. Не тут то было - аж два раза. И так и сяк - не зажигается хоть тресни, думаю, давайка тестовый ребьюлд в отдельный плаг (как пример выше), а потом посмотрю - может что изменилось в навмеше, захожу, гляжу, ничего не изменилось, кроме добавление одного параметра как можете увидеть в NVGD NAVM 2D1E1. Сделал правку на fallout3.esm, прогружаюсь и опять на finalize в этой ячейке - с первого раза прошло. Возможно совпадение - возможно нет, это так инфа к размышлению, лично подобные изменения всегда вношу, по результатам многочисленных экспериментов за NVGD хаотической флуктуации не замечал, они не бессистемны и строго повторяются (насколько я наблюдал).
В другой области еще есть одна флуктуация: rotation z (на величину +-0.001) на placed object на все файлах, причем чем количество record в плагине больше, тем больше подобных корректировок, но вот они не верны и внесению не подлежат.
-
Однако, чтобы не морочить себе голову - просто пользуюсь 2.53 и всех делов (у этой версии вроде только один миникосячек, на quest правит иногда подпараметр object на quest, но ничего страшного - гекк это автоправит).
-
PS Доп. пояснение: при финализации ячейки гекк ВСЕГДА еще автоматом производит перерасчет соседних ячеек минимум, левее, правее, выше, ниже. Но если в соседних косяка не будет (а вероятность есть), то в них как раз и произойдет холостая перетасовка connection, о которой идет речь в посте. То есть на wasteland при finalize одной CELL будет приходиться по 4 минимум ячейки потенциально с флуктуацией в навмешах.