ArtemSH

Перевод статьи Wrye, посвященной терминологии моддинг-сцены Обливиона и той путаннице, которая возникает в речи об объектах, референсах и записях. Модули, Записи, FormID Моддинг с помощью CS означает создание и редактирование модульных файлов (т.е. esp\esm файлов). Есть и другие пути заниматься моддингом (создавать\редактировать ресурсы – меши, текстуры, звуки, речь; редактировать INI и файлы XML, и т.д.), но сейчас речь идет именно о модулях. Модульные файлы (Module files) — это коллекции записей (records). Разные типы записей относятся к различным типам вещей: звукам, расам, помещенным объектам («референсам»), уровневым спискам (leveled lists) и т.п. Хотя различные типы записей соответствуют различным аспектам игры (к примеру, весу стрелы, позиции Х у помещенного на локацию объекта, ID у звука открытия двери), на базовом уровне они все равно относятся к одной и той же категории – запись. Все записи имеют уникальный FormID. Многие (но не все) записи также имеют и EditorID. FormID – это 8 цифр в 16-ричной системе счета (к примеру, 00030FDC). Editor ID – это короткие текстовые строки (состоят только из букв и цифр, без пробелов или особых знаков). Записи помещаются в Окно Объектов в CS, их EditorID находится в первом столбце, а formID во втором столбце (по умолчанию этот столбец очень узок, так что его и не увидишь, просто нужно расширить его, зажав левой кнопкой шапку и перетащив вправо). Точно также они расположены и в окне Просмотра Ячейки (Cell View): левое окно содержит список ячеек, ранжированный по их EditorID, а FormID – чуть правее. А в правом окне располагаются помещенные в выбранную ячейку объекты. Именно здесь есть один нюанс: если у референса не было EditorID, то вместо него будет автоматически помещен EditorID не референса, а базового объекта этого референса. Объект Vs. Объект Эта секция может сбивать с толку. Возможно, её стоило бы пропустить при чтении. Посыл её в том, что, когда мы говорим о моддинге, мы говорим о «записях», а не об «объектах». По крайней мере в большинстве случаев. Ладно, поехали… Есть большая проблема с тем, как пользуется слово «объект» в дискурсе моддинга. Проблема в том, что есть целый спектр одинаково очевидных применений этого слова, при этом взаимоисключающих. Я рассмотрю все из них и попытаюсь разрешить эту проблему, отбросив часть стандартной терминологии. Играя, мы воспринимаем слово «объекты», как относящееся к тому, что мы встречаем в игровом мире: будь то камни, стены, существа, ножи или предметы в сундуке. Работая в окне рендера в CS, мы воспринимаем «объекты» в почти том же самом духе, просто к ним добавляются зоны коллизии, помещенный туман, и тому подобное, но для нас все они тоже «объекты». Но в CS эти вещи называются «референсами», а «объектами» он называет предметы, размещенные в Окне Обьектов (Objects Window). А вот для программиста объекты – дискретные куски информации, то есть лишь умственные концептуализации (internal representations) любых записей (классы, фракции, базовые объекты и референсы), которые и будут восприниматься как «объекты». Поэтому я собираюсь применять слово «объект» как можно реже. Когда я использую его, я имею ввиду то, что игроки видят в игре, то есть вещи в игровом мире. Для моддинга, когда я хочу сказать о той или иной сгруппированной информации (data chunks) в целом, я буду использовать слово «записи». И еще, когда я говорю о том или ином типе записи (будь то «ячейка», «фракция», «оружие», «референс» и т.п.), будем считать, что я использую сокращение от «ячейковая запись» (cell record), «фракционная запись» (faction record), «оружейная запись» (weapon record), «референтная запись» (reference record), и т.п. Держа всё это в голове, я попытаюсь разложить всю терминологию CS несколькими способами: - вместо «базового объекта» я скажу «базовая запись». - вместо «переменной референса» я скажу «переменная записи» (record variable). Референсы Референсы основаны на базовых записях (они же «Базовые объекты» в CS). Базовые записи – прототип референса. Базовые записи могут иметь тысячи референсов (например, стандартные контейнеры), некоторые – только один референс (большая часть мирных и уникальных НИПов). Большая часть записей в игре – это референсы. (просто представьте: сотни ячеек, со стенами, камнями, деревьями, существами – всё это считается). Хоть теоретически каждому референсу можно придумать EditorID, никто этого не делал. Поэтому в Oblivion.esm у большей части записей нет своего EditorID. К тому же, кроме референсов, есть и другая группа записей без EditorID – это базовые записи, создающиеся в процессе игры. EditorID нужны только моддерам, а не CS или игровому движку, оба из них работают с FormID. Так что все алхимические зелья, заклинания, зачарованные броня и оружие, созданные в игре игроком, не нуждаются в том, чтобы их вручную правил человек и потому не имеют EditorID. Референсы еще и могут иметь референса «родителя». Родительские референсы используются для двух целей: 1) создание цепочки включенных\выключенных состояний референсов (так, появление Врат Обливиона контролируется именно таким способом), 2) связывание референсов, чтобы взаимодействие между ними регулировали скрипты (ловушки триггерятся через натянутые веревки, чей скрипт вызывает ловушку). Замечу, что для ситуаций с включением\выключением родительский референс действительно действует как «родитель», а вот в случае с ситуациями, подобной устройству ловушек, всё имеет обратный смысл: «дочерний» референс контролирует референс «родительский». Базовые Записи Базовые Записи выступают и «основой» (“base”) для предметов в контейнерах. Есть некоторая сложность в описании таких предметов – у них то есть, то нет референсов, они либо сами ими являются, то не являются, но большую часть времени они НЕ референсы. Чуть ниже будет об этом. К тому же, замечу, что не все записи, отображающиеся в Окне Объектов, базовые. Например, текстуры, звуки, вода – их записи используются другими записями, но сами они никогда не выступают в качестве базовых. Между ними и другими типами записей (ячейками, регионами, расами и т.п.), редактируемых только в меню, нет особого различия. Почему же они тогда расположились в Окне Объектов? Не знаю. Возможно, это наследие предыдущих игр серии или просто своевольное решение программистов Бесезды. Vs. Программистская Терминология Интерлюдия для сбитых с толку программистов… Программисты воспримут терминологию CS как какую-то мешанину. CS использует термины «объект», «родитель» и «референс» в своем собственном ключе, отделенном от программистского понимания этих слов. - в программировании «референс» - по сути указатель (pointer) на другую структуру данных (data structure), но в CS «референс» это комплексная структура данных (complex data structure), больше «Объект», чем «референс». Ближайший аналог для программистского значения референса в CS это FormID. - в программировании объект –это обычно экземпляр класса (instantiated class). Ближайший аналог для него в CS – это… «референс»! - в программировании класс – определение типа структуры данных (definition of a type of data structure), экземпляр которого можно создать. Ближайший аналог для него в CS – это базовый «объект»! - в программировании «родитель» экземпляра ("parent" of an instance) — это класс для экземпляра. А вот в CS родитель референса (parent of a reference) – это другой референс, скорее «предыдущее» звено в цепочке взаимосвязей. Так что, программисты, забудьте всему, чему вас учили, когда дело идет о CS! А теперь возвращаемся к нашей дискуссии.. Динамический Контент Динамические записи и предметы – это записи и предметы, сгенерированные в ходе игры. В оригинальном Обливионе большая часть этой категории – динамические референсы (спавнящиеся существа) и динамические предметы (объекты из контейнеров и инвентарей акторов). Вдобавок, игрок может создавать такие предметы, например зелья, заклинания, зачарованные предметы. Плюс к этому, есть парочка особых записей, таких как статуя игрока в Кватче. Кроме этого, OBSE может генерировать широкий спектр динамических базовых записей. Пример: когда актор спавниться на точке спавна, каждый из таких акторов – динамический референс. Их броня, оружие, инвентарь и предметы в инвентаре после их смерти – динамические объекты. Пример: когда игрок создает зачарованную брони на алтаре зачарования, две динамических записи создаются – одна для зачарования, другая базовая запись – для брони. Вдобавок, экземпляр такой базовой записи (и зачарования, и брони) добавляются в инвентарь игрока. Динамические записи (референсы, зачарования, заклинания,т.п.) «принадлежат» к файлу сохранения, а не к моду (esp\esm), поэтому их formID всегда начинаются с FF. Другими словами, если видите formID записи в игре, начинающейся с FF, то перед вами динамическая запись. Динамические Предметы Как было сказано, динамические предметы (dynamic items) не всегда ассоциируются с референсами, они не имеют референса, пока находятся в инвентаре, и всегда динамически присваивают новую запись каждый раз, когда вынимаются из инвентаря и выбрасываются в мире игры. В пику не-динамическим предметам, то есть предметам, которые были прямо помещены в игровой мир. Не-динамические предметы всегда отсылают к базовому, созданному модом, референсу, независимо от их перемещений по инвентарям, контейнерам и ячейкам. Так что же происходит со временным референсов динамического предмета после того, как его подобрали? В большинстве случаев он незамедлительно удаляется из файла сохранения. В действительности (после последнего патча игры) formID для этого динамического референса используются снова (recycled). То есть, будь вы в изолированной ячейке, выбросьте вы клинок, а затем подберите его и бросьте теперь щит, вы обнаружите, что динамический референс щита будет иметь тот же formID, что и у выброшенного, но подобранного клинка. Однако иногда референс не удаляется из файла сохранения. (неудаляющееся, кажется, связано с переменной в скрипте, который либо указывает на референс, либо привязан к референсу). В таких случаях, референс продолжает существовать в файле сохранения, но не виден в игровом мире, и больше не связан с предметом в инвентаре. Если же предмет снова выброшен из инвентаря, этот старый референс не будет связан с новым референсом, но вместо этого выброшенный предмет автоматически получит новый динамический референс, страдающий той же болезнью, то есть, остающийся в сохранении. То есть, эти остающиеся не у дел референсы не очищаются из файла сохранения, как это обычно бывает в течении цикла в три дня, когда весь мусор убирается, а противники респавнятся. В итоге, если в игре много (тысячи) таких референсов, они кратно увеличивают размеры сохранения. Такой феномен получил название референсы разбухания (bloat references). Понимание того, как динамические предметы путешествуют между ячейками и контейнерами и просто между различными контейнерами, заключается в том, что они и не движутся вовсе – они копируются. То есть, оригинальный обьект копируется в новый контейнер или ячейку со всей своей информацией (здоровьем предмета, зачарованием, локальными переменными скриптов), а оригинальный предмет удаляется (референсы разбухания же просто маркируются как уничтоженные (marked as destroyed)). Копирование наиболее очевидно, когда выбрасывается множество копий идентичных предметов (стрелы, клинки со 100% здоровьем). Если сбросить множество идентичных предметов (10 железных стрел), они не упадут как десять отдельных стрел, но будут собраны в единую стрелу с отображением количества стрел в одном референсе. В этом случае игра действительно будет считать 10 стрел как один предмет, а не как 10 штук отдельных референсов. (Но это происходит только для простых динамических предметов). Так что в каком-то смысле длительное существование предметов – просто враки. То, что игрок видит как один и тот же клинок, вытянутый из сундука, помещенный в другой и т.п., это всего лишь последовательность копий объекта. Однако, коль скоро этот процесс копирования\удаления точно копирует состояние объекта, мы можем говорить о предметах как о длительно существующих сущностях, даже если их реальное существование приходит и уходит. Скриптовая Терминология Для скриптинга это имеет два важных значения: - понимание того, какие типы записей требуют функции скриптов. - понимание переменных записей и того, что в них можно хранить. Переменные записи (Record variables) хранят записи или точнее, они хранят formID записей. Если formID идентифицируют записи, то краткое цифровое formID может выступать от лица собственно записи в вызовах функции. Это легко проверяется скриптом, если в нем вызвать «message "targetRef value: %X" targetRef».  Эта строчка напечатает formID хранящееся в targetRef. Однако в функциях мы часто опускаем эту деталь и не говорим «getSelf возвращает formID актуального референса». Вместо этого мы говорим «getSelf возвращает актуальный референс». Этот вариант сказать проще, и он в общем-то отражает и суть первого варианта. Часто можно увидеть, как переменные записи называют «переменными референса». Так сложилось, поскольку без OBSE, оригинальные функции, возвращающие записи, возвращают только записи референсов. Хотя переменные записи прекрасно могут хранить не-референсы, в них ничего кроме референсов хранить нельзя. (поэтому и переменные записей объявляются с ключевым словом ref вместо rec). Поскольку же OBSE позволяет переменным хранить целый спектр типов записей, с этого момента лучше называть их «переменными записи». (К сожалению, мы до сих пор привязаны к синтаксису с ключевым словом ref при объявлении переменных). При присвоении записей в скриптах, нужно использовать либо переменную записи либо EditorID. Когда скрипт скомпилирован, EditorID сконвертируется в соответствующую formID, которую уже будет использовать игровой движок при работе со скриптом. Замечу, хоть и можно использовать в скриптах formID напрямую, избегая EditorID, это крайне нежелательно, поскольку: а) это труднее понять при чтении б) если к моду добавят еще один мастер-файл, конкретное formID, на которое мы ссылаемся, поменяется, а в скрипте останется старый formID. (А вот скомпилированный formID будет автоматически подтянут к своему новому значению, если будет добавлен новый мастер-файл).  Теперь снова о терминологии. В UESP Wiki в разных статьях одни и те же вещи называются по-разному. По мере понимания и наращивания знаний в области OBSE меняется и представление о том, что такое записи и как они могут быть использованы в скриптах. В соответствии с этим лучше всего было бы применять такую терминологию: - в скриптах, переменные записей должны именоваться так, чтобы отображать их использование в скрипте и не использовать ID. Референс и\или базовая запись должны использоваться по необходимости для прояснения сущности переменной. Однако описания функций должны всегда специфицировать, чего именно требует аргумент, референса или базового объекта. - если функция принимает либо базовый объект, либо референс, используем bor (Я, правда, не уверен есть ли вообще такие функции, в кратких пометках документации OBSE сказано, что если указан базовый объект, то его следует указывать в другом месте, чем аргумент референса). - Контейнер (Container) как имя переменной референса (всегда\обычно?) понимается, как референс контейнера, непися или существа. (Я не знаю ни одной функции, связанной с инвентарями, чтобы она работала только на референсах контейнеров, но не работала на существах или неписях). Примеры скриптов: для функций «реф» («референс») и «базовый» объект должны использоваться чаще, чтобы прояснить природу аргумента. Другой подход – специфицировать возвращающееся значение и тип всех аргументов: Заметки о Скриптинге Кое-какие пояснения по этой теме. - getSelf примененная к отмодифицированному базовому предмету всегда возвращает оригинальной formID предмета. - getSelf примененная к динамическому предмету всегда возвращает 0, даже если предмет находится в ячейке и имеет референс. Хоть вы и ожидаете, что она вернет formID своей динамической записи, находящейся в ячейке, функция явно создана так, чтобы возвращать 0 в таких ситуациях в целях безопасности. - placeAtMe создает динамический референс и возвращает корректное formID. (прямо противоположное поведение команде getSelf). Итоги Запись: Основополагающая структура данных модуля файлов. Поле: Параметры Записи (вес стрелы, дальность лука). FormID: Основополагающий идентификатор для вех записей в виде 8 цифр 16-ричной системы счета. EditorID: Строковый идентификатора, используемый многими (но не всеми) записями. Референс: Любой объект в игровом мире – все объекты, помещённые в мир, и (иногда) объекты в контейнерах. (Большая часть референсов лишена EditorID, но все имеют FormID). Базовый Объект: Запись, на основании которой создан тот или иной референс (к примеру, BarrelFoodLow). Предметы (Items): это переносимые объекты, которые игрок воспринимает в игровом мире. Они имеют воспринимаемое время существования, которое обычно больше, чем время существования их базовых представлений данных (data representations). Устаревшие Термины Объект: сбивающий с толку термин. Лучше его не использовать. К сожалению, оно настолько в ходу, что избежать его практически невозможно. Настоящий Референс (True Reference): лишний. Не используйте его. HexID: Вместо этого FormID.

Это перевод статьи с NexusMods, описывающей нативную систему контроля версий в Construction Set. С её помощью можно автоматически делать резервные копии своих плагинов, обьединять плагины воедино и отслеживать изменения. Частично она устарела после появления xEdit, Wrye Bash и MO2, но мне она кажется любопытной сама по себе. Тем более, о ней действительно мало кто слышал в наших пенатах. Construction Set имеет встроенную и функционирующую систему контроля версий. При этом большинство даже не знает ни о том, что она есть, ни о том, что это такое и как работает. Чем больше людей создает моды, тем более полезным будет это знание. Есть статья на CS Wiki, уже малость подустаревшая, но в ней мало ссылок и она косноязычна. Так что изложим основы. Я сконцентрируюсь на том, чтобы сделать локальный репозиторий, а не на том, чтобы подключить наш контроллер версий к сети. Подготавливаем ConstructionSet.ini Начнем с того, что откроем ConstructionSet.ini по адресу C:\Documents and Settings\<username>\My Documents\My Games\Oblivion. Найдем файл и откроем его. Всё зависит от названия вашего компьютера в сети и пути установки игры. Просто не копируйте все отсюда буквально. Допустим, мой ПК зовется PathFinder, а Обливион установлен по адресу C:\Games\ElderScrolls\Oblivion. Знак доллара ($) следует прописать в пути. Далее, добавьте это к концу файла. Это нужно для открытия некоторых функций. Замените названием логина вашего ПК плашку <username>. Теперь создадим две папки. Следуя тому, что мы прописали выше, они должны быть на диске С: И прежде, чем двигатсья дальше, сделайте бекап Oblivion.esm. На всякий случай. Подготавливаем CS Теперь откроем CS и выберем Oblivion.esm. Увидим следующее: Если вылезет нечто другое, то у вас нет активного подключения к сети. Надо это исправить. Диал-апа вполне хватит. НЕ спрашиваете почему, просто примите как факт. Предположу, что вы получили правильный результат, нажму ДА и мы двинемся дальше. Как только всё загрузилось, вы увидите кнопку вверху слева на панели инструментов. Откройте Data Files. Oblivion.esm будет подсвечен. Нажмите на кнопку Details. Вылезут две плашки с подтвреждением. В обоих ставим ДА. Затем CS будет парсит мастер файл и после снова откроется окно Data Files. Введите комбинацию клавиш CTRL+SHIFT+B. И увидите следующее: Нам это нужно, поэтому выбираем ДА, чтобы их создать. Закройте окно File Detail и выбирайте ОК в окне Date Files для перезагрузки мастер-файла. Использование Вот теперь всё готово. Все функции доступны и могут быть найдены в окне Контроля Версий, доступ к которому мы получаем по кнопке вверху слева на панеил инструментов или в окне File Details, где мы создали файлы Oblivion.fid и Oblivion.fud. Окно Контроля Версий через кнопку на панели инструментов наиболее полезно. Функции в окне File Details могут быть опасны (и занимать уйму времени). Что наиболее полезно, так это слитие с мастер-файлом (merging to a master). Если создать плагины, работающие с Oblivion.esm, эта функция не имеет смысла. А вот если вы создаете свой собственный мастер-файл, то эта функция бесценна. Так что давайте потестим её на Oblivion.esm. Сперва сохраните плагин. Всегда сохраняйтесь. Теперь найдите персонажа игрока в списке НПС и удалите все из его инвентаря. Вы же начинаете игру с определенным сетом вещей. Добавьте что-угодно и удалите что было, а затем сохранитесь. Я добавил мифриловые вещи. Смысл в том, чтобы сразу заметить изменения в игре. Если посмотреть на строку персонажа в окне обьектов, вы увидите, что она стала зеленой, то есть вы её поменяли. Нажмите кнопку Контроля Врсий и получите ту же запись об изменениях. Нажмите на неё и кликните Check In. Как только это сделано, закрываем окно Контроля Версий, открываем окно Data Files и перезагружаем мастер-файл. Теперь начинаем новую игру с включенным Oblivion.esm (ну и Дрожащими Островами, если они есть) и смотрим на одежду игрока. Весомо, да? В папке VersionBackup созданной нами ранее вы найдете копию до-слитой (merged) версии мастер-файла и плагина. В папке CheckInBackup тоже созданной нами вы найдете вторую копию плагина до слития воедино. Ваш плагин существует в папке Data и все еще может быть загружен в CS, но теперь он пуст. Так что можно использовать систему Контроля Версий еще и для создания независимых мастер-файлов с нуля. Доступные Функции Функции из секции Подробности Файла (File Details window) таковы. Некоторые могут отключать (render your master file un-usable) ваш мастер файл. Некоторые потребуют выбора конкретных форм или групп в окне File Details. Я подозреваю, что часть функций осталась со времен, когда сама концепция мастер-файла только-только была реализована, а игровой мир находился в активной стадии разработки.

В этом гайде Arthmoor расскажет, как правильно сделать патч совместимости для разрешения конфликта между двумя модами. Вы наслаждаетесь времяпрепровождением в игре, красотами нового свежеустановленного мода. Всё идет хорошо, пока вы не натыкаетесь на вещь, совершенно лишнюю на том месте, где она стоит. И после этого, ошарашенный, вы поворачиваете за угол и видите эту сцену: Вы думаете: «что-то здесь явно не так», и вы правы. У вас коттедж прямо посреди нового Unique Landscapes. Вы пытаетесь понять, в чем и дело, и тут все сходится: «Это же Bravil Bridge Cottage от Emma! Но он ведь никогда не был усыпан растениями…» И вы снова правы. Коттедж Эммы был построен на лужайке, где ничего не росло. Пока Bravil Barrowfields не пришел на эту поляну. Не говоря уже о том, что рекогносцировка местности обнаружит огромные камни, закрывающие добавленные Эммой доки. Стало быть, нужен патч. Такие случаи – обычное дело, когда в сборке много модов. Внимательный ценитель Unique Landscapes наизусть задекламирует целый ворох патчей, уже созданных для UL. В этот туотриале, я расскажу основы патчинга и о примерах проблем, с которыми сталкивались я и Vorians. Этот патч для коттеджа Эммы – прекрасный пример наименее сложных патчей. Планирование Сперва надо оценить фронт работ (the scope of the project). Лучший способ – прийти в игре в то место, где нужен патч, и сделать скриншоты. Вот один сверху, показывающий все конфликты двух модификаций. Чтобы было понятнее, я обвел нужное красным: Используя команду tcl, я поднялся над коттеджем, и осмотрел всё, что нуждается в патче. Пара обьектов ввалились в дом, и если войти внутрь внешнего меша дома, можно увидеть, что другие обьекты оказались вообще «внутри» дома. Узнав необходимое, я еще раз заскриншотил дом сверху, но уже в CS. Как вы догадались, Bravil Barrowfields добавил в эту область много всякого добра. Заметьте, что в моде Эммы ни стен, ни виноградника, ни руин, ни деревьев, ни камней, ни даже особенностей увиденного ранее ландшафта нет. Теперь-то, возьмем следующие инструменты: The TES Construction Set TES4Edit (xEdit – примечание переводчика) Wrye Bash Если вы не знакомы с ними, то патчинг – последнее для вас дело, поскольку он требует продвинутых знаний в ландшафте и манипуляции с обьектами, а также де-изоляции модов и использовании флагов ESM. Начинаем Откройте Wrye Bash и найдите те моды. Лучше всего сортировать по Порядку Загрузки, чтобы наши моды шли в правильном порядке. Удерживая ctrl, кликните левой по обоим. Затем правый клик, и выбираем ESMify Self. После этого, если убрать выделение, буквы обоих модов будут синими. Это означает, что в CS они будут значиться мастер-файлами. Construction Set Откройте CS и загрузите оба мода. Не активируйте их. Хотя обоих и нельзя активировать, когда они в состоянии ESM. Если возникнут ошибки при загрузке, жмите «Да для всех». Ошибки в случаях конфликтов – норма. (это актуально для оригинального CS, но не для CSE. Серьезно, лучше используйте CSE – прим. Переводчика). Перейдите в нужную ячейку. В нашем случае это ячейка 13,-9 в Мире Тамриэль. У вас будет нечто такое: Вспомните всё, о чем мы говорили. Некоторые добавленные обьекты можно переосмыслить и оставить. Другие – удалить. Держите в уме центральную задумку: менять что-либо надо по минимуму. Главная цель не разрушать задумку и не менять слишком много кроме самого необходимого. Итак, приступим. Сперва, что очевидно, уберем обьекты, упирающиеся в коттедж, такие как некоторые виноградные лозы, растения, бочки и другие мелкие предметы. Периодически сохраняйте работу. CS нестабилен даже с нормальными модами, а с патчами он особенно чудной, так что крашей бывает больше, чем обычно. Не стоит терять часы работы из-за того, что вы забыли сохраниться. Пока патчите, обращайте внимание на двери, Xmarkers, Маркеры Карты, Врата Обливиона и всё в тако мдухе. Это постоянные обьекты и их нельзя двигать, если игрок уже посетил локации с ними. Они навсегда остаются в файле сохранения с того момента. Так что любые патчи никогда не должны трогать постоянные обьекты. Если это невозможно, то нужно найти того, кто найдет другой способ решить вопрос. Любой ценой избегаем скриптов, меняющих расположение таких обьектов в нашем патче, поскольку ЛЮБЫЕ скриптовые изменения ТАКЖЕ становятся частью файла сохранения. Но можно безопасно двигать сами маркеры дверей (полупрозрачный желтый прямоугольник с розоватой стрелкой сверху), если нужно. НИКОГДА НЕ УДАЛЯЙТЕ ПОСТОЯННЫЙ ОБЬЕКТ! Это приведет к несказанным последствиям для игры! Обливион не терпит удаления постоянных обьектов ни под каким соусом, даже с нормальными модами. Игра станет нестабильной и будет крашится, если таких обьектов не будет на месте. Есть методы обхода проблемы, но лучше приберечь их для более продвинутого туториала, включающего знание TES4Edit для таких манипуляций. Возвращаясь к рутине, думаю, вам будет полезно отключить отображение листьев и включить границы ячеек. Когда работа завершена, сразу виден результат: Я удалил множество растений вокруг, кусок руин, впадавший в коттедж, а также обьекты в стенах и некоторые бочки и кирпичи. Два больших валуна, закрывавших собою доки, я тоже удалил. Дерево, прораставшее из колодца, я переместил. Сам коттедж я предусмотрительно не трогал, а также садовую кормушку напротив. И маркер двери не тронул. К сожалению, постоянные обьекты в этой области надо сдвинуть, так что головной боли прибавилось. Однако кое-что я не проверил. Под коттеджем ничего нет? В этом случае кое-что было: коттедж закрывал пару растений и кирпичные изгороди. Их тоже удаляем. В целом, всё, что рендерится, но не видно глазу, удаляем оптимизации ради. Оно в любом случае рендерится игровым движком. Следующий шаг: проверка обьектов, критичных для вида локации, но оказавшихся под ландшафтом. У Эммы камни в районе доков частично закрыты поднявшимся уровнем ландшафта. Используя как можно меньший радиус ландшафта, я осторожно опускаю землю, пока доки снова не показываются на глаза. В процессе всплыла и лодка. Если поверхность земли недостаточно опущена, опускаем пока всё не проявится, или двигаем сам обьект. Теперь чиним весь ландшафт в целом. На границах ячеек могут быть разрывы, но у нас их нет. Можно сразу поднять или опустить большой массив земли, чтобы отразить изначальный замысел Эммы. Поскольку в случае ландшафта, его высоту, текстуры и теней побеждает последний мод, то ландшафт отражает задумку Bravil Barrowfields. Так что придется возвращать вдиение Эммы. Убедившись, что высота земли достаточная, кругом нет резких или кривых перепадов высот, обьекты не под землей, идем дальше. Теперь исправим бросающиеся в глаза ошибки текстурирования ландшафта. В нашем случае: - у Эммы вокруг коттеджа зеленая трава, которую нужно вернуть. - от дороги до двери дома шла каменная тропинка, её тоже возвращаем. При текстурировании не следует истерить, если вы выбрали траву, рисуете её, а вместо этого видите уродливую грязь. CS имеетбаг, когда 9 текстур используются в одной ячейке разом. Отобразит он неправильную текстуру при работе в CS, а вот в самой ире всё будет как надо (актуально и для CSE, к сожалению – прим. Переводчика). Поскольку текстуру надо менять и под домом, я выбрал текстуру без генерации травы. После этого нужно исправить затенение текстуры ландшафта. В нашем случае это почти ненужно, только домик поправить. Вот результаты: Теперь финальная фаза. Сетки путей. Они наследуются последним модом. Поскольку последним является Bravil Barrowfields, то и сетки путей – от него. Исправим это. Не так уж и плохо! Единственное, что исправить точно: точку внутри дома. Удаляем её и добавляем новые точки, чтобы соединть сетку, но уже вокруг коттеджа. Сделали и теперь всё как надо. Уходим из CS, не забываем сохраниться. Нам же не охота терять такую красотень? Очистка мода в TES4Edit CS – взбалмошный зверь. Он осталяет нежеланые правки (unwanted edits) в простейших модах, где их даже не ожидаешь увидеть. Эти изменения, не удали их, приведут к проблемам с другими модами. Это особенно плохо, если вы допустили в моде тотальный атас, вроде нажатия кнопки compile all в скриптовом окне, думая, что это компиляция скриптов только вашего мода. Результаты плачевные, поскольку ваш мод в таком случае сохраняет в себя копию всех скриптов оригинальной игры. Еще хуже, что удаленные обьекты в одном моде, могут подвергнуться изменениям во втором, что ведет к печально известному «крашу при выходе из игры». Или Обливион просто зависнет навеки при выходе из него. Надо понимать, что почти все моды нуждаются в том или ином очищении в рамках защиты от подобного исхода. Это проблема характерна не только для Обливиона. В Морровинде она тоже часто встречается, так что для него создали серию инстурментов. TES4Edit и TES Gecko – два основных. Но первый надежнее в этом деле. К сожалению, проблема касается и Fallout 3, но там нужен FO3edit. Патчи добавляют фрустрации тем, что CS никогда не задумывался для работы с такими файлами, которые редактируют файлы других esp. Так что проблема нежелательных правок (грязных) (unwanted (dirty) edits) серьезна. Ч теперь нам стоит исправить ошибку CS, чтобы наш патч не привел к еще большим проблемам для конечного пользователя. Есть две школы очистки патча. Те, кто пользуются TES4Edit и его автоматической встроенной функцией отчистки, и те, кто еще и сами заглядывают под капот грязных правок. Таких правок, которые автоматике не сможет удалить. Их еще называют «дикими» (wild) правками. Для обучения я пойду вторым путем. Это послужит уроком, показав для чего очистка вообще нужна, а вы увидете, как выглядят грязные правки. Открываем TES4Edit. Выбираем наш патч и дважды кликаем на него. TES4Edit автоматически подхватит и наши мастер-файлы. Раскройте древо в левой панели. Примерно так это будет выглядеть: Помним, в какой ячейке происходило дело. Ячейка 13, -9 и 13, -8. Что-то сразу должно бросаться в глаза. Это изменения в ячейках 13,-12; 20,-17 и 20,-14. В этих ячейках нет никаких ветвей, они помечены зеленым, показывающим, что они идентичны информации их мастер-файлов мода. Если кликнуть по каждому, обратите внимания на правую часть экрана. Эти записи следует удалить. Правый клик по ним в левом окне и жмем удалить. После этого вы заметите, что "Sub-Block 2, -3" и "Sub-Block 2, -2" теперь не имеют ничего в своем составе. Их тоже удаляем. Результат: Оставшиеся ветви раскрываем. Будет что-то подобное: Те, что с надписью "Placed Object" и больше ни с чем – это обьекты, удаленные еще в CS. У них зеленые буквы на желтом фоне. В нашем случае это камни и растения. Наконец, оранжевый на красном (очень плохо) – у ландшафта и сетки путей. Но в данном случае так и должно быть, так что ничего не меняем. Еще раз про удаленные обьекты – их следует обязательно удалять, иначе краши и нестабильности неизбежны. Единственный путь – через функцию "Undelete and Disable". Последуйте на CS Wiki в статью по очистке мода и прямо в Секцию 2. Четко следуйте инструкции по фильтрации процесса. Как только отфильтровали, удаляем и отключаем референсы и БОЛЬШЕ НИЧЕГО. Это пункт 13 в той статье. В нашем случае "Remove 'Identical to Master' records" уже была проведена. Вообще следует почаще перечитывать все гайды по очистке, где всё разжевано, зачем и почему это надо. Не стоит верить тем, кто отрицает необходимость очистки, поскольку эти люди не знают, что говорят. Как только вы всё сделали, закройте TES4Edit и сохраните результаты. Завершая Патч Опять включаем Wrye Bash. Выбираем два мода. Но вместо ESMификации выбираем ESPификацию. Если этого не сделать, то ландшафт пропадет и на месте модов будут визуальные баги. Активируйте патч и пересоздайте Bashed Patch, если он есть, перезапустите TES4LODGen для дальней отрисовки местности и вперед. Наслаждаемся Результатами Труда Теперь посмотрим на плоды нашей работы. Загрузим игру и вперед к Эмме. Походите по месту. Убедитесь, что ничего не пропустили. Видите, теперь всё выглдяит намного лучше без этого хаоса. Еще пара Мыслей Этот гайд оказался полезным для многих моддеров. Именно этот патч с Эммой – один из простейших. Он почти не включает удаление обьектов, в нем мало работы с ландшафтом и сеткой путей. Многие патчи на голову выше в плане сложности, чем то, что мы делали. Наиболее неприятные – те, кто требуют целые комюинации модов, в духе Cloudtop Mountains, Ravenview Village, и мода Mimics. Или вот какой зверь: патч для Let the People Drink, UL: Imperial Isle, New Roads & Bridges и Open Cities. Ага, патч для четырех модов одновременно, который, как нетрудно догадаться, был той задачкой в реализации. Практика – критерий совершенства. Чем больше патчей создаете, тем проще процесс и быстрее результат. Патчи совместимости улучшают игру в своем особом духе. Внимательные читатели заметят лишнее бревно на скриншотах. Оно из TIE и совершенно случайно попало в кадр на самом краю. Но нам повезло: это бревно вполне вписалось в кадр и тем показало, насколько пространство Сиродиила заполнено самыми разными модами.

Гайд от Arthmoor, посвященный работе с постоянными референсами при создании патча. Этот гайд – продолжение гайда Создание Патча Совместимости. Если не прочли, то прочтите, чтобы знать базу. В какой-то момент при создании патча совместимости вырастает проблема того, что делать с постоянными референсами (persistent objects).  Обычно все проблемы – из-за перемещения дверей из изначальной позиции в другую, чтобы встроить их в сделанные изменения. В рамках гайда мы будем работать именно с дверями. Но держите в уме, что всё, что мы сделаем, актуально для всех постоянных референсов (persistent references), видимых игроку. Первое правило: НИКОГДА не сдвигать двери в новое место! Постоянные рефернсы навсегда вписываются в файл сохранения, едва игрок посетил область, где они расположены. Второй правило: НИКОГДА не использовать скрипт, делающий ЛЮБЫЕ изменения с постоянными обьектами. Даже с целью их отключить (to disable). Каждый раз, когда скрипт вносит изменения, эти изменения навсегда записываются в файл сохранения. Включая и включение обьектов через включение родителя (enable parenting). Важно это запомнить, поскольку эти вещи не самоочевидны. Любые изменения с состоянием обьекта (to an enable state), сделанные скриптом, становятся постоянными. Поскольку два наиболее удобных метода – вне списка, то остается изобретать велосипед. Сперва отключите телепорт у двери. Главное, не забудьте куда именно она вела, какой был formID той двери прежде, чем вы её отсоедините от нашей. Первый и наименее опасный метод: просто установить малюсенькие размеры двери. Наименьший размер в CS – 0,01. В основном этого хватит, чтобы рендерить её незаметно для наблюдателя, если двери не большие, как городские врата, к примеру.  Если после уменьшения двери не видно, то всё готово. Велик шанс, что её скроют другие обьекты вокруг, например, обьекты из мода, конфликтовавшего с модом двери. Это идеальная ситуация,поскольку вместо старой двери мы просто поставим новую, и дело с концом. Второй метод: поставить флажок "initially disabled" оригинальной двери. В целом это рабочий вариант, но с нюансом. Если игрок перезагрузится, а не выйдет из игры, дверь может отрендериться, несмотря на опцию, из-за бага движка, возвращающего референсы к базовому, до-модовскому состоянию. Это особенно опасно, когда дело идет о дверях из оригинальной игры. Хотя в остальном этот метод гарантирует, что двери мы не увидим. Так что, если уменьшение размеров в пролете, можно попробовать этот метод. Последний фокус изворотлив, но полезен в некоторых ситуациях, когда размеры не помогут, а отключение по каким-то причинам не работает. Поэтому если первые два – в пролете, попробуйте этот метод, как последнее прибежище.  Отключите флажок persistence у двери. Поставьте флажок "initially disabled". Установите координату Z на -30000. Как только игра загрузится, и игрок войдет в ячейку обьекта, игра поймет, что дверь больше не постоянный референс и его координата Z уберет обьект из поля зрения. Но у этого подхода есть недостаток. Если игрок перезагрузит игру без выхода из неё, то со сто процентной вероятностью дверь сбросит все изменения и вернется к первоначальному состоянию. Действие всё того же бага движка. Без применения OBSE обойти эту проблему нельзя. Если ничего из вышеизложенного не помогает, то есть железный способ убрать дверь с глаз долой: удалить её. Надо быть ТОЧНО уверенным, что у двери отключен телепорт перед тем как делать это, иначе CS крашнется. Сохранитесь перед этим. Хоть метод поможет, но у него есть другая опасность в виде удаленного референса (deleted reference), запись о котором сохранится в файле нашего патча. Это может крашнуть игру, даже если другие моды не пытаются воздействовать на удаленный обьект. Обливион очень плохо воспринимает удаление постоянных обьектов, любых обьектов такого рода. Особенно дверей с телепортом. Риск краша довольно низок для дверей из модов, но НИКОГДА не нужно удалять двери из оригинальной игры – это приведет к ошибкам, вылетам и нестабильности при любом раскладе. Если дверь помечена как цель в квесте, если к ней привязан пакет ИИ, если скрипт на неё ссылается, то при попытке удалить эту дверь вылезет предупреждение. Если оно выскачило, остановитесь, выключите CS и НЕ сохраняйтесь, поскольку у CS есть баг: если отменить предупрждения любого рода, у двери, вызвавшей предупреждение, отключится телепорт. Мда-а-а, Бесезда. Как только с дверью покончено, теперь самое легкое. Нужно поставить новую в отпатченной локации, и эта дверь будет вести к той же двери, к которой вела старая. Расположите новую дверь на нужном месте, убедитесь, что подключили её к правильной двери с правильным formID. Поправьте маркер телепорта, и затем проследуйте через телепорт к той двери, чтобы сделать то же самое с её маркером. Если нужно, убедитесь, что поменяли референсы в скриптах, которые ссылались на старую дверь – просто замените старую дверь новой в строчках скрипта. То же самое надо сделать и с пакетами ИИ, и с целями квеста, если это актуально. Редко бывает так, что нужно поправить диалог, в результирующем скрипте которого фигурировал референс на отключенную нами дверь. А теперь самое веселое. Сохраните патч, загрузите игру, убедитесь, что всё работает, как надо. Если всё хорошо, то релоцированная дверь покажется на локальной карте игрока и впишется в новое, отпатченное окружение. Надеюсь, этот гайд пролил свет на проблему загрузочных дверей в патчах совместимости.