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