ArtemSH

Этот гайд сфокусируется на создании HUD элемента в моде, копирующем механики "Primary Needs", как в oHUD и IMCNNV. Метод данной статьи заключается в поэтапном создании мода "Гигиена", выступающем в роли примера,  так что осмыслять эту тему мы будем шаг за шагом. Чтобы научиться читать синтакисис XML, смотрите предыдущую статью. Данный гайд предназначен для Fallout 3\New Vegas, но принцип работает и для других игр Бесезды, включая TES IV: Oblivion. Введение Идя от простого к сложному, добавляя все более сложные функции, вы научитесь отображать наши переменные, как текстом, в виде процентов на экране, так и визуальным хелсбаром (visual bar).   По мере обучения вы узнаете, как добавлять элементы интерфейса в UIO, отправляя информацию из ГЕКК-скрипта в XML, и создадите скрипт, позволяющий игрокам вручную изменять положение нашего элемента интерфейса на экране. 1. ПЕРвые шаги: немного текста 1.1. Цель: HUD для Гигиены (Hygiene.esp) Давайте предположим, что у вас есть мод "Гигиена", который отслеживает уровень гигиены игрока во время игры. Ну, я уже написал этот мод, чтобы было нагляднее. Вот главный скрипт, высчитывающий значение, которое я хочу отобразить на экране: В старых добрых фоллаутовских традициях мы зовем эту характеристику «Гигиена», но чем выше ее значение, тем хуже "гигиена" игрока. То же характерно и для характеристики «Вода», маркирующей "Жажду" при верхних значениях. Вот и наша полоска гигиены будет становиться красной при достижении верхней отметки. Скрипт выше просто суммирует значение с течением времени, в зависимости от того, что делает игрок и сколько времени ему нужно, чтобы достичь 100 пунктов по дефолту, — все эти переменные можно будет настроить в MCM. То есть на экране я отображу просто процент и небольшой текст, поясняющий, что этот процент означает. Например: HYG: 10% 1.2. Привязываем к UIO Начнем. Сперва, если вы не знали, когда дело доходит до добавления элемента интерфейса, нельзя просто положить новый файл в некую папку. Существует только один файл XML, который отвечает за интерфейс игрока: hud_main_menu.xml, расположенный по адресу menus\main. Раньше, добавляя нечто в этот файл с помощью мода, мы создавали конфликт с другими модами, изменявшими этот же файл. Костыль в виде использования элемента  <include>  имел много недостатков и этим был крайне неудобен для модеров, затем появился uHUD, автоматизировавший весь этот процесс, но он требовал от автора обновлять себя каждый раз, когда новый мод, привязанный к нему, публиковался. Оба решения уже в прошлом благодаря UIO, разрешившему все конфликты и автоматически распознающему добавленные элементы интерфейса. Мы создаем файл XML по адресу menus\prefabs. Создаем текстовый файл в папке uio\public, оповещающий UIO, что мы загрузили новый XML, который следует добавить в интерфейс. Впишем в файл следующий код: 1.3. Добавляем Текстовые Элементы Разобравшись с этим, открываем XML файл. Теперь разобьем "HYG: 10%» на три части: лейбл (label), значение (value) и знак процента. В этой строке лейбл и знак процента – части текста, которые не будут меняться, а вот значение будет обновляться из скрипта мода. К тому же самое время сгруппировать эти три элемента в один, поскольку в последующих главах мы слегка двинемся на теме изменения их положения и подключения к другим модам интерфейса. И мы всё еще нуждаемся в корневом элементе, содержащем всё, что будет в нашем XML. Общая структура файла на данный момент будет следующей: корень с нашим HUD в виде сгруппированных элементов в нем. Если вы прочли гайд по чтению XML, то уже заметили, что эта главная структура содержит лишь объектные элементы, добавив 3 текстовых компонента, сгруппированных под одним невидимым прямоугольником. Только отсутствует текст, который они должны отображать, и неясно положение на экране, где они будут отображаться. Так что, добавим свойства и сперва введем строки (strings). Нединамические строки ставятся между тегами <string>. Значение, которое мы хотим отобразить, будет вызвано главным скриптом из esp, где будет такая строчка кода: Она присваивает значению пользовательское свойство элемента, _DSHygValue. Нам остается только сделать так, чтобы в XML файле код считывал это свойство из элемента, используя оператор <copy> с "io()" src атрибутом: 2. Местоположение Теперь наш XML выглядит так: В игре уже появятся все три текстовых компонента, только они наслаиваются друг на друга в левом верхнем углу, потому что мы еще не расписали их расположение. Чтобы это сделать сперва установим положение их родительского прямоугольника: Копируя широту экрана и вычитая (subtracting) некоторые пиксели, я кладу элемент в правую часть экрана и в середину по высоте. Поскольку мы собираемся позиционировать наши текстовые элементы, давайте еще включим элемент <locus>, который воспринимает положение дочернего элемента по осям X и Y по отношению к родительскому прямоугольнику, а не по отношению к экрану. Просто мне так удобнее. Со включенным <locus> я выбираю не специфицировать положение лейбла, поэтому  он копирует свое положение по осям родителя. Но я расположу его слева через элемент <justify>: Остальные два элемента будут отрисованы справа, поскольку я хочу, чтобы "Значение" было ближе к "Знаку процента", да и к тому же так проще. Остальные элементы имеют одну и ту же позицию по оси Y, но я смещаю знак процента вправо (+ 100 X относительно родительского элемента) и делаю то же самое для "Значения", копируя позицию "Знака процента" по оси X: минус ширина самого знака процента: Вот как это будет выглядеть в игре: Хорошее начало, но я мог бы достичь того же результата множеством других способов. Вы можете позиционировать компоненты относительно экрана или друг друга, используя самые различные формулы, а то, что взял за основу я, всего лишь самый простейший из методов. 3. Включение и выключение видимости Хоть мы и добавили наш элемент на экран в Gamemode, он также отображается и в Menumode. Нам этого не нужно, поэтому необходимо его убрать. Также неплохо бы, чтобы мы не видели такие элементы в других ситуациях и в Gamemode тоже – в бою, например. Решаем проблему тем же способом: включая видимость с помощью пользовательского свойства. Помните наш прямоугольник родительского элемента, который группирует три текстовых элемента? Сам по себе он невидим, но мы включим его видимость. Она включает и все три дочерних элемента. Так что давайте сделаем эту видимость зависимой от пользовательского свойства: А в нашем моде сделаем еще один маленький квестовый скрипт, который пока что  будет делать следующее: Можно легко добавить и больше условий в этот скрипт. Например, чтобы наш элемент интерфейса исчезал во время боя, сделаем так: Наконец, нам стоит отключать элемент в тех же ситуациях, когда отключается и ванильный интерфейс игры. В катсценах, к примеру… Обычно это делается привязкой видимости элемента к видимости «ActionPoints» компонентов интерфейса: (Учитывайте, что моды подобные iHUD, которые при определенных условиях заставляют элементы, типа ActionPoints, визуально исчезать, не трогают видимость этого компонента: он всё равно будет активен. Условия отключения таких компонентов, включают ситуации, где используется функция DisablePlayerControls.)   С другой стороны, мы хотим дать возможность заставить наш элемент интерфейса остаться на экране несмотря на то, что ванильный интерфейс будет выключен. Для этого мы включаем новое пользовательское свойство в esp: Включить элемент можно посредством скрипта, реагирующего на особые условия, или по желанию игрока через МСМ, связь с которым я собираюсь добавить в наш мод: через чекбокс (checkbox), который будет включать фукнцию iForceHUD. 4. Позволяем игроку подправлять позицию элементов В дополнение к тому, чтобы не переписывать оригинальные файлы интерфейса игры, мы очевидно хотим быть хорошими соседями другим подобным модам. Лучше всего дать игроку опцию самому установить положение нашего элемента интерфейса в случае конфликта. Некоторые моды дают такую опцию в настройках МСМ в Menumode, а мы сделаем её в Gamemode. 4.1. Добавляем Пользовательские Свойства для X и Y На самом деле нам повезло, ведь мы сгруппировали наши компоненты под одним прямоугольником, так что воздействовать нужно только на один элемент. Ну, конечно, всё это было задумано с самого начала! А как вы хотели? Мы добавим новые пользовательские свойства к существующим осям X и Y нашего прямоугольника, которые назовем _DSHygX и _DSHygY: Смысл в том чтобы оба пользовательские свойства отражали переменные, которые содержатся в нашем скрипте,  и эти переменные будут добавляться и удаляться в зависимости от клавиш, которые нажимает игрок. Чтобы адекватно распознавать нажатие клавиш нужен быстрый скрипт, так что сделаем его отдельным от остальных, включим его через MCM и выключим, когда закончим. 4.2. Определяем и Храним Нажатые Клавиши Есть два пути достижения нашей цели.   Перый – написать скрипт, который позволит игроку включать и выключать опцию через МСМ, но сам по себе он может наслаиваться на другие моды, так что понадобятся дополнительные манипуляции с его положением на экране.   Другой – сделать это в Gamemode. Проблема в том, что большинство клавиш уже зарезервированно, включая клавиши движения игрока, которые хотелось бы использовать. Однако второй путь все равно предпочтительнее – он вполне осуществим, если на время настройки ограничить передвижение игрока. Сначала весь квестовый скрипт надо включить через МСМ. Вот один из способов сделать это: в моем квестовом скрипте DSHygHud : Так как мы хотим позволить игроку менять положение с помощью клавиш движения, нам нужно: - ограничить движение игрока, чтобы он не крутился, пока мы меняем положение элемента интерфейса - сканировать нажатые клавиши и хранить их как смещения (offsets) в локальных переменных от обычных положений элементов нашего интерфейса в квестовом скрипте - прокинуть эти смещения в XML, где наши кастомные свойства _DSHygX и _DSHygY прочтут их.   Вот этот скрипт сделает всё это. Смотрите. На стадии 0 он останавливает игрока и заставляет интерфейс включиться, если тот был выключен по какой-то причине. Стадия 1 определяет нажаты ли клавиши и вносит изменения в соответствии с ними, повышая или понижая положение нашего элемента интерфейса, которые мы передаем в пользовательские свойства _DSHygX и DSHygY в нашем XML. Стадия 100 останавливает весь процесс (cleans up), освобождает игрока и останавливает скрипт внесения изменений. 4.3. Показываем текстовые подсказки на экране Но кое-что мы пропустили: удобство игрока. Откуда игрок узнает, какими клавишами ему менять положение элемента в настройках? Хорошо бы прописать это в README, но их же никто не читает! Так что давайте прямо в игре скажем о кнопках, добавив текста в наш XML. Сперва создадим новый прямоугольник, сиблинг по отношению к DSHygOwnHUD. Это сгруппирует наши новые текстовые элементы и включит видимость их всех с помощью пользовательского свойства: Мы добавим немного кода, чтобы включать подсказки, когда зажата кнопка в нашем скрипте HudConfig: Нам нужно пару текстовых элементов, чтобы описать какие клавиши нажимать. Так как игрок уже знает как у него назначены клавиши движения, их можно записать в виде статичной строки в XML: Создадим и другие строки в нашем квестовом скрипте для настройки интерфейса (HUD config), используя GetControl чтобы выявить какие клавиши каким элементам управления принадлежат, прокинем их через SetUIStringEx и через спецификатор формата %k, а затем включим видимость всего блока по умолчанию: И скопируем их в наш XML, поместив их друг под друга где-то посередине экрана: Получаем такой результат: 5. ИнтермеЦЦо 5.1.  Подправляем Шрифты Не удивлюсь, если стандартный шрифт покажется слишком маленьким, и вам захотелось интерфейс покрупнее. И вполне возможно, что в пику мне вы не используете мод Darn's UI, который делает шрифты меньше, да и я не проверял, адекватно ли помещены на экране наши элементы интерфейса с учетом использования оригинальных шрифтов. Возможность переключаться между шрифтами, которые есть у пользователя, поможет нам во всех случаях, когда возникают проблемы с читаемостью. На счастье, шрифты пронумерованы от 1 до 8, независимо от того, перезаписаны они или нет, так что нам просто нужно в XML добавить их как условия каждому текстовому компоненту, которое мы скопируем из мода, используя еще одно пользовательское свойство: В таком случае простое решение – прокинуть это в наш квестовый скрипт интерфейса, привязав к переменной: И позволив игрокам установить значение переменной через МСМ. Другая опция – добавить этот кусок кода в наш скрипт настройки позиционирования, чтобы игроки переключали его в реальном времени: и создав следующую строку: И вложив это в наш XML: 5.2. Подправляем Непрозрачность Пока что мы не добавили опцию отключить наш интерфейс. Ну там, для скриншотов или еще чего. Да и вполне возможно, что полная непрозрачность выглядит уж очень навязчивой. Убьем двух зайцев разом и создадим способ управлять непрозрачностью. И сделаем слайдер МСМ – это наиболее разумный выход. Непрозрачность варьируется от 0 до 255, так что этот диапазон будет и на нашем слайдере МСМ, привязанный к еще одной переменной, которую мы прокинем из нашего квестового скрипта в наш XML. В нашем XML: В главном квестовом скрипте: С такими положениями в нашем меню МСМ: 5.3. Подправляем цвет В Нью Вегасе царит приятный и щегольской янтарь (amber), но возможно наши игроки предпочтут яркий и болезненный зеленый (green), а, может, ярко розовый. А кто мы такие чтобы им запрещать, верно? У нас же есть  <red>, <green> и <blue> элементы свойств и четыре стандартных цвета интерфейса, соответствующие данным значениям RGB: amber - 255, 182, 66 blue - 46, 207, 255 green - 26, 255, 128 white - 197, 255, 255  Что-то подсказывает, что мы можем создать «список» в МСМ, который будет хранить эти имена, а так же пользовательскую опцию, привязанную к переменной в нашем квестовом скрипте: В нашем XML мы отделяем текстовые элементы от их обычной цветовой схемы, мы не хотим использовать регулярную схему цветов. Поэтому добавим <red>, <green> и <blue> элементы свойств каждому текстовому элементу: А МСМ расширим следующим списком: Который подарит мне болезненный зеленый оттенок, если выберу его в игре: А зачем, собственно,  останавливаться на этом? Можно добавить добавить в МСМ удобную опцию type-9 чтобы позволить людям вводить любое значение RGB, которое им нравится. Ну а когда еще вы этим воспользуетесь? Внимательнее к документации МСМ, так как она содержит ошибки, где говорят пользоваться SetUIStringEX там, где надо использовать SetUIFloat. Сделаем эту опцию зависимой от нашей пользовательской опции в списке: Это позволит выбрать клейкий розовый: 6. Добавляем измеритель (meter) или полоску (bar) Вместо сухих процентов, может, лучше предпочесть полоску, отображающую как мы грязны? Давайте снова добавим еще одну опцию в МСМ: и прокинем её в XML с другим пользовательским свойством: а после нужно остановить отображение "знака процента", если включена полоска: Затем добавляем 2 элемента изображения (image elements) под тем же прямоугольником, где мы поместили наши текстовые компоненты, один для задника, другой для его заполнения: Их видимость должна зависеть от опции «use bars». Мы будем использовать простую сплошную текстуру из игры для заполнения полоски: Вы могли заметить, что задник имеет максимальную ширину в 100 пикселей. (Можно и больше, но тогда значение гигиены надо тоже конвертировать.) Изображение, которое будет заполняться, DSHygBar, усвоит её ширину из значения fHyg из нашего квестового скрипта: Чтобы обеспечить контраст, я отключу обычный цвет интерфейса на фоне и нарисую его серым, устанавливая его непрозрачность на половину того значения непрозрачности, которое мы ранее подключили к переменной. Также обратите внимание, что фактически полоса имеет более высокое значение <depth >, чем значение фона, поэтому убедитесь, что она нарисована поверх нее. Что даст нам следующий результат: А давайте продолжим! Коль скоро мы знаем как менять цвет текста, давайте дадим возможность менять цвет полоски в те же цвета, которые мы выбрали для текста: А еще, почему бы не залить полоску красным, когда уровень гигиены пересекает порог в 90 пунктов? Ну а теперь-то вы уже сможете догадаться, как сделать его еще и ярким, используя блок видимости или другое пользовательское свойство элемента, которое можно настраивать в МСМ? Заключение, титры Всегда можно сделать ту же штуку разными средствами, и этот гайд дает лишь один способ реализации интерфейса. Так что поразминайте мышцы, играясь с этими новыми знаниями. Я был и остаюьс сторонником прямолинейного подхода, когда дело касается пользовательских свойств в подобных модах. Я же не эксперт во всем этом деле, и мне намного ближе скрипты из ГЕККа, чем XML от Бесезды. В заключение, скажу лишь, что в случае с такими скриптами всегда следует читать то, что написано до вас. Я основывался на ванильных скриптах игры, на том, что написано в Wiki Обливиона, модах Gopher’а, Impoftheperverse’а и JIP’а, чтобы затем на маленьком моде, который Fallout2AM однажды сделал для меня, обьяснить вам базовые вещи. от переводчика Для подготовки к этому гайду существует гайд по чтению XML, читайте его по ссылке.  Информация в этом гайде вполне подойдет и для других игр Бесезды, включая Обливион. Если где-то были допущены ошибки или описки, пишите, пожалуйста, в комментариях. Это обьемный гайд, так что переводчик вполне мог где-нибудь ошибиться.

XML – Расширяемый Язык Разметки, или же мета-язык, описывающий информацию, разбивая её на маленькие элементы и используя теги <>. Сам по себе он ничего не делает, лишь помогает организовать данные. Продолжение данного гайда смотрите по ссылке. В нем вы узнаете, как создать свой компонент интерфейса на примере мода в духе Primary Needs. 1. Основы XML XML часто противопоставляется HTML, в конце концов у них много общего в применении. В то время как HTML показывает данные, фокусируясь на том, как это должно выглядеть, XML описывает информацию, говоря нам из чего она состоит. … В этом языке важно то, что базовые его элементы являются универсальными, поэтому структура написанного на данном языке может быть отражена совершенно непохожими друг на друга программами, даже если эти программы изначально не заточены воспринимать такой язык или добавляют к нему новые элементы и данные. Поэтому этот язык и назван «расширяемым». 2. Правила XML В XML мы используем теги (tags), чтобы вставлять в них всё что-угодно. Другими словами, значение тега определяется автором кода (или в нашем случае Бесездой). Лишь немного элементов уже пред-определены заранее, то бишь, у которых уже есть предписанное значение, поскольку некоторые символы (certain characters), такие как <and >, уже зарезервированы языком, то есть, они уже используются для обозначения тегов. Если бы у них не было зарезервированного значения, они бы означали < (меньше чем), > (больше чем), &quote; (цитата) и & (амперсанд).   Такие штуки называются сущностями (entities) или ярлыками (shortcuts), и Бесезда использует разработанные ей сущности чтобы ссылаться на элементы, которые, судя по всему, зашиты в код (hardcoded). Напр. булевы элементы (bool) имеют значения &true; или &false. Поскольку это не язык сам по себе, не так много нужно запоминать при чтении кода, созданного не Бесездой. Поэтому…  А) все элементы следует закрывать закрывающим тегом  Или быть само-закрывающим пустым-элементом тегом:  Последнее обычно используется в комбинации с атрибутами, смотри ниже.    Б) теги чувствительны к регистру (case-sensitive) и должны быть правильно вложены (properly nested):   В) все документы должны иметь корневой тег (root tag), структура документа начинается с одного тега, который держит все остальные: Неверно, потому что два элемента А и С оба являются корневыми. Верно.   Отношения между разными элементами документа XML часто описывается как семейное древо (family tree). Элементы на одном и том же уровне иерархии названы сиблингами\брат-сестра (siblings). Элемент, содержащий другой, является «родителем» (parent) ему, а тот – ребенком (child) или дочерним элементом. Внуки и деды прилагаются.   Г) некоторая информация об элементах может содержаться в самом теге (parked inside the tag), а не в под-элементе. Такой способ размещения информации называется атрибутом (attribute). К примеру, элемент, обозначенный ниже, атрибуирован именем через атрибут: Информация, содержащаяся в атрибуте, представляет собой мета-данные такого типа, которым благодаря своей уникальности незачем содержаться в под-элементах.   Д) комментарии в коде добавляются следующим образом: 3. XML в играх Бесезды: Схематизм До-скайримовские игры Бесезды на Gamebryo свои меню и компоненты интерфейса (HUD components) организуют в элементы внутри документа XML. Элементы и их иерархия переводятся в то, что игрок видит на экране с помощью собственного XML-парсера игры. Для этого парсер присваивает значение элементам, тегам и тому, что между ними. XML поддерживает обширный синтаксис, а Бесезда наполняет его словарем. Но словарь этот она нигде особо не публиковала, так что для моддинга это проблема. Такой тип словаря, говорящий нам какие теги в структуре XML  валидны и значимы, называется схемой XML. К счастью для нас некоторые умные люди на КС Вики (CS Wiki) выяснили большую часть этой схемы в Обливионе. Конечно, надо с осторожностью подходить к тому, чтобы автоматически полагать, будто работающие вещи в Обливионе по определению будут работать в F3 или New Vegas, но тем не менее я опишу именно схему Обливиона. У Бесезды элементы XML в целом делятся на три больших типа: обьектные элементы (object elements), элементы свойств (property elements), оперантные элементы (operator elements). Вот все они в отрывке из stats_menu.xml, линии 1415-1420: В этом коде главный элемент декларирует появление нового компонента изображения, которое добавлено в меню статов. Такие вещи называются обьектными элементами, которые вводят новые обьекты в меню или интерфейс. Само собой разумеется, они немедленно получают имя с помощью именного атрибута (name attribute), чтобы оперантные элементы и функции расширителя скриптов могли ссылаться на них. Уровнем ниже мы можем видеть, что кое-что следует разъяснить в этом новом компоненте, а именно какую текстуру он использует (тег <filename>) и его процент масштабирования. Другие свойства включают размеры и положение элемента объекта. Элементы, обозначающие свойства обьектных элементов, именуются элементами свойств (property elements). Также они известны как характеристики (traits). Во множестве случаев содержимое элементов свойств может быть абсолютной величиной, либо числом, либо строкой (string). Путь файла (filepath), к примеру. Однако скопированные из свойств других обьектных элементов эти значения могут также высчитываться в течение игровой сессии  и\или подвергаться воздействию математических и обуславливающих (conditional) элементов. В приведенном выше примере процент масштабирования изображения копируется из процента масштабирования его собственного родительского элемента. Элементы, которые создают такие «живые» операции на элементах свойств, называются оперантными элементами (operator elements). Они часто включают использование src и trait атрибутов, чтобы ссылаться на другие свойства.  Src будет в большинстве случает ссылаться на обьектный элемент или на нечто глобальное, когда как trait ссылается на свойства. Вот примеры элементов, которые выпадают из описанной выше типизации. К примеру, элемент <include>, который вы можете обнаружить в ванильных файлах повсюду, включает код из других документов, очевидное преимущество которого в том, что один и тот же код с ним можно использовать везде, а не печатать каждый раз заново: Хотя сейчас я перечислю самые общераспространенные обьектные, и оперантные элементы, и элементы свойств, я должен отметить, что многие документы XML могут содержать пользовательские элементы свойств. Они маркированы тем, что начинаются с подчеркивания. Оригинальный парсер их не понимает, но на них можно ссылаться по имени с помощью операторов и функционала расширителя скриптов, а так же они могут обладать операторами как дочерними элементами, поэтому они хорошо умеют хранить значения и выполнять промежуточные вычисления, чтобы избежать длинных формул, а так же хороши во взаимодействии со скриптами вашего мода. Снова пример из stats_menu: 3.1 Обьектные Элементы <rect> определяет прямоугольную область на экране. Сам по себе элемент невидим, но его свойства влияют на любые дочерние элементы, которые он имеет. В примере ниже текстовый элемент, являющийся дочерним элементом к прямоугольному элементу, наследует свойство <systemcolor>. <text> как вы можете представить, определяет текстовую компоненту. <image> определяет прямоугольную область, которая заполняется текстурой. <nif> определяет анимацию; используется в loading_menu.xml, а так же в полоске дыхания в интерфейсе: <menu>  - корневой элемент файлов XML, связанных с меню.  Другие обьектные элементы, встречающиеся в ваниле, включают  <hotrect> и <template>. Как обьектный элемент, <template> скорее всего служит той же функции, которую выполняет пользовательский элемент свойства: хранит информацию, которая может быть использована в любом другом месте. Имеет смысл. Но в различиях между <rect> и <hotrect> я не уверен (см. stats_menu.xml). 3.2 Элементы Свойств Элементы свойств или характеристики определяют свойства их родительских элементов. Они могут иметь буквальные значения (числа, строки, булевы значения &true; или &false;) или состоять из формул, которые используют оперантные элементы. Если элемент содержит два или более свойства того же типа, последний побеждает. Если никакое свойство не присвоено в параметре, где его можно указывать, будет использовано стандартное значение, обычно 0 или пустая строка. В игре свойства обновляются, если любое из этих свойств меняется в результате вычислений движка или по команде скрипта. К примеру, изменение свойства с помощью SetUIFloat или SetUIString сразу же обновит все свойства, использующие его. А) размер и позиция <x> и <y> определяют позицию родительского элемента на оси X & Y на экране <width> и <height> самоочевидны: широта и высота соответственно. <locus> булев элемент. Если &true; позиционирование X/Y дочернего элемента будет зависеть относительно родительского элемента, если же значение локуса ложно, то позиция дочернего элемента будет абсолютной.  Б) отрисовка (rendering) <visible> булев элемент, включает или выключает отображение элемента, а также его дочерние элементы. На скрытый элемент нельзя нажать мышью, но можно активировать через скрипт. <alpha> числовой элемент, определяющий прозрачность родительского элемента, значение установлено в периоде от 0 до 255 (нормальная, полная видимость) <depth> числовой элемент, определяющий приоритет перекрывающих элементов. Элемент с более высоким значением будет отрисован поверх остальных. Изначально, дочерние элементы имеют более высокую глубину, чем родительские. <clips> булев элемент, гарантирующий скрытие элемента, если родительское свойство <clipwindow> истино, при условии что элемент находится за пределами размеров родительского элемента. <systemcolor> берет сущности (обычно &hudmain;), которые определяют цвет главного интерфейса, например пипбоя.   В) клики и наведение мышью <target> булев элемент, определяющий будет ли элемент (rect или изображение) реагировать на ввод игроком (player input). Если истино, то свойство наведения мышью будет соответствующе установлено движком, и если элемент имеет свойство <id>, клик по нему установит его свойство на «кликнуто» и воспроизведет специфицированный звук нажатия мышью (clicksound). <clicked> числовой элемент, чье значение меняется на 1 на один фрейм после того, как на элемент кликнули мышью. <clicksound> числовой элемент, определяющий какой именно звук будет сыгран, когда на элемент кликнули мышью. <mouseover> другой числовой элемент, который автоматически меняет значение на 1 игровым движком, когда на элемент навели мышью. В противном случае приобретает значение 0.   Г) уникальные свойства элементов-изображений <filename> определяет путь файла для текстуры, которую будет отображать элемент, находящийся в папке Data\Textures. <zoom> числовой элемент, определяющий процент масштабирования. Если больше 100, увеличит источник текстуры, если 0, то спрячет изображение. Если -1, то изображение будет изменено таким образом, чтобы втиснуться в ширину и высоту элемента без обрезания краёв. <filewidth>, <fileheight> это элементы только для чтения. Их значение устанавливается игровым движком под актуальные ширину и высоту загруженной текстуры (в пикселях), после того как было применено масштабирование. Если масштабирование равно -1, значение этого элемента равно 0. <tile> булев элемент, если истинно, а широта или высота элемента больше текстуры, 2 или более текстур будут собраны в одном изображении. <cropx>, <cropy> определяет точку текстуры, которая будет помещена в верхний левый угол изображения. Пример смотрите здесь. <texatlas> судя по всему ссылается на файл с расширением .tai, который, очевидно, содержит атласную текстуру, файл, хранящий несколько текстур.   Д) уникальные свойства текстовых элементов <string> содержит текст, который должен быть отображен. <red>, <green> и <blue> числовые элементы, которые можно использовать чтобы определить цвет текста. Ранжируется от 0 до 255 (также работает на изображениях!) <font> числовой элемент, определяющий, какой шрифт следует использовать в соответствии со шрифтами, перечисленными в  ini-файле игры. Если он отсутствует или недействителен, по умолчанию будет использоваться шрифт 1. <justify> элемент, определяющий, где будет начинаться текст относительно х-кординаты элемента. Значения "&left;", "&center;" и "&right;". <wrapwidth> обозначает максимальную широту элемента в пикселях. Если текст превышает эту широту, он раздваивается в несколько множественных линий. <wraplines> максимальное число отображаемых линий. Вот здесь пример более продвинутого использования элементов <IsHTML>, <PageNum> и <PageCount>, которые должны позволить отобразить текст, разделенный на страницы.   Е) уникальные свойства элементов меню <class> определяет какой класс внутренного меню использовать для обработки ввода и вывода в меню. Значения могут быть числовыми и соответствовать кодам, использованным в MenuMode, но обычно они определены как сущности, соответствующие названиям меню, такие как HUDMainMenu; или &StatsMenu; . Если введенное значение не соответствует классу меню, меню откроется, но не будет обновляться или принимать вводные значения. <stackingtype> определяет, блокирует ли меню использование других меню или элементов управления игровым процессом, когда оно открыто. Большая часть блокирует такие взаимодействия и маркирована как "&no_click_past;". <menufade> определяет длительность эффекта постепенного появления/исчезновения (fade in/out) в секундах, когда меню открывается и закрывается. Меню не обновляет и не принимает ввод, когда активен эффект.   Ж) общие и разные свойства <id> по идее связано с меню тегом <class>, в котором определяет, какой части собственной классовой системы этого меню соответствует элемент, чтобы принять и обновить то, что вводит туда игрок (updating and accepting player input).  Примеры схемы Обливиона ограничены типами меню, характерными для этой игры, так что не очень ясно как этот элемент работает в контексте меню Фоллаутов. <user#> : типы элементов, начинающиеся с пользователя, обычно не являются частью схемы XML, но могут распознаваться определенными классами меню. Как и <id>, кажется, что их значение во многом зависит от меню, в котором они находятся. Если верить странице обсуждения, они, похоже, предназначены для использования в качестве своего рода заполнителей (placeholders), а не как ссылки на структуру меню на несколько уровней ниже, так что это может быть полезным при моддинге. Другие незатронутые элементы свойств можно найти здесь.   3.3 Оперантные элементы   А) как они работают Операторы производят конкретные операции на элементах свойств, используя либо буквенные значения...   ...Либо другие свойства как их второй операнд, с атрибутами  'src' и 'trait' в самозакрывающемся теге:   Множественные операции возможны на одном и том же свойстве, и они осуществляются сверху вниз. Если необходим другой порядок их активации, их можно вложить друг в друга:    Б) возможные значения 'src' Наиболее прямой способ сослаться на другое свойство, с которым будет работать оператор, заключается во всего лишь в создании ему имени.   Однако присутствуют и «относительные» способы ссылаться на другие свойства, используя значения 'src', которые включают me, parent, sibling(name), и child(name): Устанавливает позицию Y (игрек) у элемента такой же как его позиция X (икс).   Устанавливает позицию X (икс) у элемента такой же как у его родителя.   Устанавливает ширину элемента такой же как у конкретного сиблинга. Если имя сиблинга опущено, то в таком случае по дефолту значение берется у сиблинга, созданного прямо перед оператором. Дочерний элемент следует тому же синтаксису: вам нужно указать имя, но он также найдет еще более нижние элементы и далее. Если множество дочерних элементов, «внучатых» элементов и тд. существуют с тем же именем, будет выбрано последнее записанное в документ XML.   И еще кое-что. Src так же может ссылаться на конкретные глобальные свойства, в большинстве случаев используя "screen()" и "io()". В примере ниже элемент интерфейса позиционируется в крайне правой части экрана, устанавливая его позицию X (икс) к ширине "screen()", вычитая из неё элемент своей собственной ширины: io() возможно аббревиатура для ввода\вывода (input/output), так как, судя по всему, служит как средство коммуникации между XML-парсером и скриптами игры. Свойства, скопированные из io, могут быть установлены через скрипт с помощью SetUIFloat и SetUIString. Довольно важный элемент, если планируется включать или позиционировать элементы с помощью скрипта и\или настроек МСМ (для Fallout). Этот скрипт означает, что элемент интерфейса, описываемый этим элементом, будет виден, если пользовательское свойство "_MyModVisible" будет включено с помощью функции SetUIFloat  в скрипте:   Г) общие операторы Математические операторы: <add>, <sub>, <mul> и <div> должны быть самоочевидными. Также доступны <mod> (модуль) и <rand> (случайное число между 0 и содержимым <rand> </rand>). Логические операторы, все возвращающие сущности со значением &true; (то есть число 2), или &false; (1, или любое другое число): <onlyif> и <onlyifnot> элементы условия перед ними. <and>, <or>, <not> самоочевидны: и, или, не. Для сравнения чисел и значений у нас есть  <lt> (lesser than, меньше чем), <lte> (lesser than or equal to, меньше чем или равно), <gt> (greater than, больше чем), <gte>, <eq> (equals, равно) и <neq> (not equal, не равно). <min> и <max> устанавливает значение элемента свойства, соответственно минимуму или максимуму самого себя и тому, что находится между тегом. 4. Выводы Всё это можно считать гайдом по тому, как читать связанные с HUD файлы XML. Даже при понимании синтаксиса XML и большей части вокабуляра Бесезды, все равно потребуется стальное упорство для того, чтобы понять более сложные меню, но этот гайд хотя бы даст базу. Чтение – очевидное условие для любого желающего написать что-то своё, а написание элемента интерфейса станет уже темой другого туториала. Пс. Замечания переводчика К сожалению ссылки, ведшие на CS Wiki, уже мертвы и не имеют смысла. Тем не менее, я оставил их в тексте на случай, если сайт когда-нибудь будет активен снова, или если неофициальная копия сайта (cs.uesp) перенесет эти страницы к себе. Некоторые неважные или неуместные здесь пассажи (см. на каком именно сайте был опубликован оригинальный туториал) я опустил. Я придерживался стиля и разметки оригинала, а в скобках оставлял оригинальные термины на случай, если мой перевод не отображает общепринятых в IT переводов данных понятий или пассажей.   ППС. Вообще слово Bethesda обозначает...Вифезду, город в Иудее, который посещал Господь Иисус Христос в эпизоде с исцелением расслабленного. Возникает оторопь: зачем надо было брать это название, если суть всех игр компании ничего общего не имеет с иерофаническим смыслом, закрепившемся за этим названием города?