Условия: Как подарить себе уникальный игровой опыт с помощью xEdit

LivelyDismay обьясняет как на примере Условий (Conditions) работать с данными в xEdit и насколько удобнее создавать небольшие моды, ребалансы и патчи через xEdit, чем делать их "вручную" через редактор.

Условия великолепны. Они дают массу возможностей разнообразить контент и творить всё, что вздумается. И они, прямо как и ключевые слова, используются для всего. Загрузочные Экраны, перки, крафт…всё ими управляется.

Посмотрим на них. Поработаем сегодня с Fallout 4 и его DLC.

Запускаем xEdit.

Загружаем модули.

Ждем фразы Background Loader: finished.

Начнем с простого. Раскройте содержимое Fallout4.esm и найдите категорию Load Screen. Раскройте её. Найдите вторую запись: Vault111CharGen.

Удивительно, но здесь есть условие! Раскройте его, чтобы лучше его рассмотреть.

Всё просто.

Type: Equal to – определяет как использовать информацию прямо под этой линией.
Comparison value 1.00000 - 1 = true. 0 = false. Как говорит линия сверху, условие, чтобы работать, должно иметь значение 1. А что именно за условие? Смотрим дальше.
Function: GetInCell – проверяет, в какой именно ячейке вы находитесь. Так что кто-то или что-то должен быть в нужной локации, чтобы это условие было истинным. Какой именно?
Cell: PrewarVault111 – в этой ячейке!
None – это игнорируем, это просто мусорная информация.
Run On: Subject – «Субьект» это цель конкретного условия. В данном случае – игрок.
Другие две линии под этим тоже являются мусорной информацией.  Parameter всегда будет -1. Если поменять значение, то всё сломается. Не меняйте ничего.

Суммируем. Что мы имеем? Легко: Субьект должен быть в ячейке PrewarVault111, чтобы условие стало истинным. Как только оно таковым стало, этот загрузочный экран появится в вашей игре.

Без шуток. Это всё. Всё сводится к одному условию. И поскольку вы в этой ячейке окажетесь ровно один раз за всю игру, этот загрузочный экран вы увидите только один раз. Поскольку Субьект больше ни разу не посетит эту ячейку, и Условие всегда будет ложным (то есть не будет равно 1), загрузочный экран больше не будет появляться.

Вот так! Давайте еще смотреть. Напишите 46946 в строке поиска FormID (FormID search bar) вверху слева и нажмите Enter. Выделится следующая запись.

Это запись COBJ или Constructible Object. Опять же прочесть её очень легко: если у нас два Bloatfly Meat, можно скрафтить Baked Bloatfly, пищу под грифом ROAST, на верстаке приготовления. Но у нас здесь никаких условий, так чего мы тут забыли?

Ну так мы собираемся их добавить! Для практики.

Праывый клик по заголовку записи на правой панели и выбираем Copy as override into...

Выбираем опцию <new file> с флагом ESL (только для Skyrim\Fo4. В остальных играх это ESP. – прим. переводчика) в правой колоне. Такой тип плагинов вы будете делать 99% случаев.

Назовите мод как хотите.

Теперь у нас дубликат этой записи в нашем плагине. В нем-то и будем делать изменения, ну или патчи, если хотите.

Правый клик по пустому полю Conditions в нашей новой записи и выбираем Add.

Теперь у нас вот такой зеленый блок. Прогресс!

Раскройте его.

Давайте добавим для закрепления Перк, как условие. Это маленькое условие дает нам тонну информации. Нам нужно от игрока владение конкретным перком.

Стало быть, сперва введем условие True, подтверждающее, что, да, у игрока есть перк. Для этого поменяйте значение Comparison Value на 1.

Теперь игрок не может иметь больше 1 в этом поле, а значит и двух одинаковых перков (ранги перков в реальности устроены как совершенно новые перки взамен предыдущих), так что оставьте поле Equal to. Еще мы хотели, чтобы субьектом был игрок. Для этого есть два пути:

 1. Оставить его в субьектах. Поскольку условие будет проверять того, кто активировал верстак, оно и так будет знать, игрок это или нет, поскольку игрок указан в субьекте.

2. Изменить Run On на Reference и выбрать PlayerRef в выползающем меню выбора.

В этом случае, и субьект и PlayerRef делают ровно одно и то же, поскольку из значения совпадают – оба подразумевают игрока. Но знать разницу важно.

Дальше. GetWantBlocking – это не то условие, которое мы хотим. Мы хотим перк, да? Ну давайте менять эту линию.

Выползет очередное поле заполнения. Там выбирайте перк! После этого выползет еше одно и там выбирайте конкретный перк, который хотите.

Посмотрите, сколько там разнообразия. Я выберу что-нибудь безумное прикола ради, как пример, что перков на деле намного больше того, что показано в меню прокачки.

Так что теперь нужно быть «Хорошо отдохнувшим» (Well Rested) чтобы скрафтить предмет. Почему нет? Моя игра, ворочу, что хочу. И вы тоже!

 Добавим еще кое-что.

Для этого условия (Condition) сделаем условием (requirement) наличие хотя бы одной Сковороды (Cooking Pan) в инвентаре Субьекта.

Но, увы, такое условие будет сломано! Это неочевидно, но надо быть крайне внимательным в Условиях. Посмотрите на две линии. Equal to 1. Она говорит, что Субьект должен иметь именно ОДНУ сковородку. Не две, не ноль, не 14. Только одну. Так что, имей игрок две сковородки в инвентаре, и условие сразу будет ложным, и предмет крафтить запретят. Поэтому условие надо поменять. Двойной клик по Equal To, и в выпадающем меню выбираем то, что нам нужно.

Выбираем чекбокс Greater.

Теперь тип будет Greater than or equal to. Отлично! Теперь нам НУЖНО 1 сковородка или больше!

Уже заметили чекбокс с надписью Or? Все Условия имеют по умолчанию свойство AND, то есть они сочетаются с другими Условиями, чтобы позволить что-то сделать (Быть Отдохнувшим И иметь сковородку). Но мы пока что оставим условие OR.

Еще условий!

В него тоже бросаем условие со сковородкой. Чтобы всё сделать побыстрее. Помните: надо переносить (drag) условия со слота родителя (top (parent) slot) в раздел Условия нового.

Теперь наши Условия дублируют друг друга!

Поменяем Сковороду на котелок (Cooking Pot).

Добавьте тип условия OR (condition Type) и сковороде и котелку в свойства (requirements).

Теперь сверните все наши условия, чтобы видеть их в линию.

Видно, как первая кончается с AND, а другие две с OR? Это значит именно то, о чем вы думаете: игрок должен быть Отдохнувшим (это работает как перк), И ЛИБО хотя бы с одной сковородой, ЛИБО хотя бы с одним котелком.

Теперь добавим эти условия всей еде в игре. Это довольно времязатратно, да? Да! И это отстой! Поэтому все сделаем за пять секунд!

Выберите все записи, которым хотите добавить наши Условия, затем правый клик и Copy as override into...

Выберите патч, сделанный нами пять минут назад.

Кликните по любой записи, которую мы только что скопировали, не важно по какй. Затем правый клик по верхушке названия плагина в правой панели и выбираем Jump to.

Наша правая панель не поменялась, но левая панель расширилась. Теперь посмотрим на наши записи с перспективы нашего патча.

Выберите все эти записи на левой панели, правый клик и выбираем Compare Selected.

Теперь у нас целая куча записей в правой панели. Листаем прямо вниз, где покоятся наши Условия.

Правый клик по шапке Условия (Conditions) и выбираем Copy to selected records.

Хотим ли мы применить условия ко всем этим записям? Да, кликните ОК.

И вот таким макаром все эти COBJ записи имеют те же условия, заданные нами до этого. Вот так вот быстро! И эффективно!

Таких опций для Условий УЙМА. Парочка моих любимых: GetQuestCompleted, GetLevel, GetIsSex (для создания особых условий в зависимости от пола героя), GetIsRace и GetLocationCleared – просто парочка примеров того, как разнообразны ваши возможности в области обуславливания. И вам стоит их попробовать! За ними лежит абсолютная свобода.