SOEdit v0.7m5 - справка 3.0

Блог - TonaTor / Программы / Разное / Редакторы


Версия программы/плагина: v0.7m5*
Автор(ы): TonaTor
Опубликовал: TonaTor
Загружено: 08 июн 2026, 13:52
306	3	0

Скачать

233 МБ

Ура! Ну наконец-то у вас появилась возможность почитать многа букавов в интернете!

Предисловие:

SOEdit — Это некомерческая программа для скелетного редактирования MDL-файлов
моделей техники для игр на базе движков GEM1/GEM2.
(Версии GEM~2,5 от «BW», начиная с «БИ» и включая «MOW II», не поддерживаются.)

Программа не является и не будет являться заменой для «3D Max» или «Blender».
Она является лишь вспомогательным инструментом для редактирования уже существующих
моделей техники. Категорически не рекомендуется с её помощью редактировать: пехотные
скины, объекты инвентаря, здания и конструкции, а также специальные служебные объекты.
Редактирование анимации живых существ рекомендовано только для фанатов пути боли.

Основные возможности программы на момент версии «v0.7m5*»:
1) Просмотр моделей техники;
2) Скелетное редактирование моделей техники;
3) Создание новых моделей техники из готовых частей;
4) Беглое автоматическое тестирование моделей техники;
5) Воспроизведение / редактирование / создание скелетной анимации
(версий: 0.3.0.0; 0.4.0.0; 0.5.0.0; 0.6.0.0; 0.6.0.1);
6) Настройка некоторых внутренних параметров PLY-файлов 3D-моделей (мэшей);
7) Конвертирование PLY-файлов в OBJ-формат (текстовая версия).

Рекомендуемые системные требования:
1) CPU: не ниже Pentium 4;
2) ОЗУ: от 2Gb;
3) Видеокарта, поддерживающая графический режим не ниже 1440x900,
поддерживающая OpenGL 1.1 и имеющая от 512Mb видеопамяти.
(Т.ж. нужны соответствующие драйвера);
4) Операционная система Windows 7 или новее;
5) Клавиатура, мышь.

Примечания:
1) Это не исчерпывающий документ, а просто выжимка некоторых основных вещей.
2) Документ создавался с основным расчётом на DMS`овскую версию движка GEM2
и игру GoH. Совместимость с другими играми серии лишь частична.
(*Примеры в документе, приводимые на других играх серии, также применимы к GoH.)
3) По своей сути документ является лишь «лоскутным одеялом» из некоторых
разрозненных данных разной актуальности и качества.
4) Я не гарантирую абсолютную и вечную достоверность описанного.
5) Программа доделывалась и переделывалась походу написания документа.

Программа, справочная документация и дополнительные материалы к ним предоставляются
«как есть», без каких-либо явных или подразумеваемых гарантий.
Автор не несёт ответственности за лулзы, анархию и любые убытки, возникшие в результате
использования всего этого.

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

Оглавление.

«Теория — это когда все известно, но ничего не работает.
Практика — это когда все работает, но никто не знает почему.
Мы же объединяем теорию и практику: ничего не работает... и никто не знает почему!»
(Высказывание одного проницательного человека.)

Общие положения, организация работы в программе.

Программа не требует установки.
Но рядом с ней всегда должны находиться файлы:
1) «FreeImage.dll» — Модуль для чтения файлов PNG, JPG, JPEG, BMP.
2) «lamp.ply» «lamp.mtl» «lamp.bmp» — файлы для визуализации лампочки. (Источник освещения.)

При первом запуске программы нужно установить путь к РАСПАКОВАННЫМ ресурсам
игры/мода (зависит от того, с чем будет взаимодействие).
Установить путь можно через «Главное меню -> Файл -> Преференции».

(В версии «v0.7m5*» программа ещё не может работать с игровыми архивами.
Будет переделано в следующих версиях.)

После этого нужно зайти в «Главное меню -> Файл -> Свойства».
И указать свой никнейм в этом поле:

(Он будет использоваться при записи программой файла с моделью.)

Программа рассчитывает, что все файлы модели (кроме текстур) хранятся в папке с MDL-файлом модели.
Конечно.
Программа умеет считывать и расширения путей, и некоторые виды путевых рекурсий.
Таким образом можно в некотором роде «прототипировать» модели.
Но, так-как программа не может создавать рекурсивные относительные пути,
а абсолютные пути не будут работать на чужом компьютере, то, создавая модель из частей
других моделей, вы сами вручную должны собирать все задействованные файлы в одной папке модели.

В случае конфликтов имён файлов (то есть если содержимое разное, а названия одинаковые),
таким файлам нужно прописывать уникальные имена и заново перевыбирать их там,
где они использовались (кости, волюмы, блоки анимаций).
Переименованные имена текстур нужно искать и переписывать в соответствующих файлах материалов.
Переименованные файлы материалов нужно перепрописывать в
соответствующих PLY-файлах через встроенный в программу твикер.

Создавая/модифицирую модель, крайне желательно, чтобы все задаваемые вами названия
были мнемоническим. Т.е. название должно соответствовать содержанию, чтобы по
названию можно было понять, что это такое.
Все названия должны быть выполненными латинскими (английскими) буквами.
(Иные после завершения ввода строки удаляются программой автоматически.)
Должны быть уникальными в пределах модели и ограничиваться не более чем 30 символами.
Рекомендуется не использовать знаки препинания и системные имена Windows
(типа таких: "con", "prn", "com1", "com2", "com3", "com4", "com5", "com6", "com7", "com8", "com9", "aux", "nul", "lpt1", "lpt2", "lpt3", "lpt4", "lpt5", "lpt6", "lpt7", "lpt8", "lpt9") в каких-либо названиях.
Объекты, относящиеся к одной группе, должны иметь названия
начинающееся с одного и того же префикса: box_front, box_left, box_right, box_rear.
Нумерация костей, волюмов и т.п. объектов начинается с 0.
Причем в номерах некоторых объектов, в силу сложившихся особенностей,
не допускается ведущий ноль. Т.е. можно написать emit2, но нельзя emit02.
Формат нумерации таких объектов будет указан как имя#, при этом нумерация всегда начинается с 0.
Формат нумерации объектов, допускающих произвольную нумерацию, – имя##.
Формат не требующий обязательной нумерации обозначается звёздочкой «*».
(«#», «##» и «*» будет использоваться в дальнейшем описании.)
В каждом конкретном случае на количество объектов может накладываться ограничение.

Программа рассчитывает, что в пути модели и её частей есть папка «resource», вроде этого:
D:\Games\Men of War Assault Squad 2\mods\LTP\resource\entity\test\2\ba27m_2\

Если её нет.
(Допустим, если модель создается/обрабатывается за пределами мода),
то это может вести к нестабильной работе недоделанного механизма поддержки доп. модов.
(Чревато вылетом программы.)

Программа ещё не умеет работать с директивами «extension», «include», «define» и «mod».
Не поддерживается и вынос костей и скелетов в отдельные файлы с их подгрузкой по их названиям.
Не поддерживается и наличие более одного скелета в MDL-файле.
Поэтому скелет не должен быть разделён на отдельные файлы.

Создавая модель, вы должны понимать, что локальные файлы у вас — это файлы у вас.
На другом компьютере набор ресурсов может отличаться.
Важен самоконтроль по завершению работы над моделью.
Проверяйте корректность работы настроенной модели.
Следите за зависимостями и возможностью их подгрузки на других компьютерах.

Также не стоит совсем уж забивать на стилистическое однообразие модели,
создаваемой из разных частей других моделей.
Для того чтобы объект был целостным, необходима цветовая гармония его частей
друг с другом, а также соблюдение пропорций цветовых отношений: соотношение
яркости и насыщенности элементов должно быть обратно пропорционально их площади.

Для того чтобы ваша модель как надо работала в игре, вы должны знать и задавать
определенные параметры в пользовательских полях и блоках свойств объектов,
чьё предназначение, устройство и расположение вы также должны знать.
Некоторые параметры являются необязательными, некоторые — обязательными.
Это зависит от типа и функции объекта.
Некоторые задаваемые вами свойства могут:
— перезаписываться свойствами, заданными в другом месте
(допустим, в папке «properties» или *.INC / *.DEF — файлах. Следите за очерёдностью
расположения блоков данных);
— не применяться из-за необходимости иной конфигурации свойств;
— приводить к вылету игры, причём сообщения о настоящей причине вылета вы не получите;
— не работать потому, что такова воля Ктулху.

Ваша задача — научиться осознанно использовать имеющиеся возможности.
А ваше обучение должно начинаться с создания моделей по аналогии с моделями из GoH
(предварительно изучив их устройство).

В процессе создания моделей нужно иногда делать бэкапы в виде новых файлов через:
«Главное меню -> Файл -> Сохранить как...».

Теперь о самой программе.

SOEdit v0.7m5*

Основные блоки интерфейса программы:

1) Главное меню с глобальными функциями;
2) Тул-бар с некоторыми вынесенными в него функциями из главного меню;
3) Дерево компонентов модели;
4) Блок воспроизведения и быстрого редактирования скелетной анимации;
5) Окна просмотра и редактирования модели.

Главное меню.

Главное меню — Файл.

1) Кнопка создания нового документа.
Очищает сцену.
Если в программе есть не сохранённая модель, то запрашивает подтверждение.

2) Кнопка открытия модели.
Открывает окно выбора mdl-файла модели.
Если в программе есть не сохранённая модель, то запрашивает подтверждение.
(Открывать mdl-файлы можно и простым их перетаскиванием в окно программы.)

3) Кнопка сохранения текущего файла модели.
Предварительно запрашивает подтверждение сохранения.

4) Кнопка сохранения файла модели под новым именем.

5) Кнопка совместимости со старым плагином GEM Import.
В этом режиме при сохранении данных программа записывает матрицы в полном объёме —
«Matrix34», а т.ж. отключает оптимизацию данных анимации, заставляя программу
записывать полный объём данных.

6) Кнопка скрытия ошибок чтения данных.
В этом режиме программа не отображает сообщения об ошибках чтения данных, которые не
ведут к нарушению стабильности её работы. (По крайней мере так предполагается.)
(Не стоит привыкать пользоваться этим режимом на постоянной основе, т. к. скрываются
в т.ч. те ошибки, которые могут ронять игру.)

7) Кнопка вызова окна настройки преференций.
Позволяет выбирать каталоги игры и модов.
(Об этом будет рассказано позже.)

8) Кнопка вызова окна «Свойств».
Вызывает окно со всяким хламом, для которого просто не нашлось более подходящего места.
(Об этом будет рассказано позже.)

9) Десять кнопок-слотов, по которым можно заново открыть 10 последних просмотренных моделей.
Эти данные сохраняются в реестр при закрытии программы и загружаются в программу при её запуске.

10) Кнопка очистки списка последних просмотренных моделей.
Не позволит агентам FBI быстро определить список из 10 последних просмотренных моделей.

11) Кнопка выхода из программы.
Завершает работу программы. При наличии потенциально не сохранённых данных
запрашивает подтверждение действия.

Примечание:
После загрузки, а т.ж. перед сохранением выполняется беглое тестирование модели
на предмет ошибок и странностей. Подробно, об этом будет расписано ближе к концу описания программы.

Главное меню — Редактирование.

1) Кнопка вырезания объекта/ветви объектов из дерева компонентов модели в буфер обмена виндовс.

2) Кнопка копирования объекта/ветви объектов из дерева компонентов модели в буфер обмена виндовс.

3) Кнопка вставки объекта/списка/ветви объектов из буфера обмена виндовс в дерево компонентов.

Примечания:
1) Файлы, прикреплённые и подразумеваемые за объектами, через буфер обмена виндовс не переносятся.
2) Эти кнопки правильно работаю только на выбранных объектах из дерева компонентов.
3) Не надо вставлять объекты в несвойственные им места. Программе будет больно!
Вы будете знатно обруганы сообщениями об ошибках! (Если не включите режим скрытия ошибок чтения.)

4) Для костей копирование выполняется по принципу копирования ветви,
а вставка — как последующей после выбранной.

5) Увы. Но пока-что без кнопки отмены.
6) ЛОДы и суб. мэши сами по себе не вырезаются и не копируются — только вместе
с костями, к которым они прикреплены. (И вместе с их содержимым.)

Главное меню — Мэши.

1) Кнопка обновления мэшей костей.
Перезагружает PLY-файлы, задействованные программой на данный момент.

2) Кнопка обновления мэшей волюмов.
Перезагружает VOL-файлы, задействованные программой на данный момент.

3) Кнопка обновления всех мэшей.
Перезагружает PLY и VOL-файлы, задействованные программой на данный момент.

Примечание:
Обновление мэшей костей также заново ищет и загружает материалы и текстуры.

Главное меню — Анимация.

1) Кнопка создания анимации.
Создаёт пустую анимацию с единственным плейсхолдером кости «empty_node» и
единственным кадром. После добавления своих костей плейсхолдер можете удалить.

2) Кнопка загрузки файла анимации.
Открывает окно выбора ANM-файла возле текущего файла модели.

3) Кнопка сохранения текущего файла анимации.
Перезаписывает текущий открытый ANM-файл.
(Предварительно запрашивает подтверждение.)
Если файл создаётся с нуля, то открывает окно сохранения ANM-файла.

4) Кнопка редактирования анимации.
Вызывает окно редактора анимации.
(Об этом будет рассказано позже.)

5) Кнопка закрытия анимации.
Закрывает текущую анимацию.
(Предварительно запрашивает подтверждение.)

6) Кнопка обнуления статуса скрытия костей относительно предыдущих анимаций.
В игре параметры отображения костей не привязываются к определённой анимации.
Кость может отображаться по умолчанию. Первая запущенная анимация её может скрыть.
А вторая запущенная анимация для своей визуально корректной работы может предполагать
необходимость предварительного скрытия этой кости. В игре корректность отображения
может обеспечиваться запуском анимаций в определённой последовательности.
Но в программе эту последовательность определяет сам пользователь.
Чтобы не возникало ситуаций, когда анимации, запускаемые пользователем в случайном
порядке, мешают друг другу, кнопка обнуления статуса активна по умолчанию.

7) Кнопка разрешения редактирования первого кадра для анимированных костей.
Отключает запрет на редактирование первого кадра.
(Ваша синхронизация — ваша проблема.)

8) Кнопка обновления путей файлов анимаций из списка ниже.
Обновляет список путей анимаций из списка файлов анимаций в меню с учётом
подключенных модов, а также проверяет их доступность.
(Для срабатывания требует закрытия открытого файла анимации.)

9) Список файлов анимаций, подключенных к модели. (Быстрый доступ.)

Примечаниия:
1) Чтобы анимацию можно было Создать/Загрузить/Отредактировать, в программе должен
быть открыт файл модели. Если модель делается с нуля, то её нужно сохранить в MDL-файл.

2) Новосозданные и стащенные с других моделей файлы анимации не прикрепляются к
модели автоматически. Вы сами должны их прикреплять к скелету или костям в дереве компонентов.

3) Программа поддерживает сохранение ANM-файлов только в матричную версию 0.4.0.0,
даже если изначально была открыта кватернионная 0.6.0.0+.

Главное меню — Текстуры.

Кнопка перезагрузки текстур и материалов.
Выполняет повторный поиск и перезагрузку материалов и текстур модели с учётом модов.

Примечание:
При этой перезагрузке сбрасывается режим отображения в 3D-окне.

Главное меню — Взаимодействие.

1) Кнопка выбора режима перемещения.
Переводит 2D-окна в режим взаимодействия с курсором мыши для перемещения объектов,
выбранных в дереве компонентов.

2) Кнопка выбора режима вращения.
Переводит 2D-окна в режим взаимодействия с курсором мыши для вращения объектов,
выбранных в дереве компонентов.

3) Кнопка выбора режима масштабирования.
Переводит 2D-окна в режим взаимодействия с курсором мыши для масштабирования
объектов, выбранных в дереве компонентов.

4) Кнопка выбора режима выбора (отсутствие взаимодействия).
Переводит 2D-окна в режим отсутствия взаимодействия с курсором мыши.

Примечания:
1) Увы. Но в этой версии программы так и не удалось доделать режим выбора объекта в 3D-окне по курсору мыши.

2) Из-за несовершенства подсистемы матричного анализа, от работы которой зависит
синхронизация действий курсора с воздействием на объект, работоспособность функций
перемещения, вращения и масштабирования сильно зависит от прямоты результирующей дообъектной матрицы.
Сопряжение работает только с более-менее прямой цепью нескалированных матриц — от
базиса и до объекта перемещения (но не включая его).
А это значит, что матрицы должны быть под прямыми или развёрнутыми углами (в независимости от их инверсности).
И все векторы проекций во всех матрицах (до матрицы выделенного объекта) должны быть единичной длины!
Никаких поворотов и масштабирований в цепи перед перемещаемым объектом быть не должно!

Главное меню — Отображение.

1) Кнопка переключения режима фокусировки на выбранном объекте.
В этом режиме рендерится только выбранный объект своего класса, если ему это позволяют
другие настройки. (Индивидуальная настройка отображения; Отображение всего класса объектов; Режим просмотра.)

2) Кнопка отображения сущностей.
В активном состоянии позволяет окнам рендерить кости.
(Но 3D-окно дополнительно управляется своим режимом просмотра.)

3) Кнопка отображения волюмов.
В активном состоянии позволяет окнам рендерить волюмы.
(Но 3D-окно дополнительно управляется своим режимом просмотра.)

4) Кнопка отображения препятствий.
В активном состоянии позволяет окнам рендерить препятствия.

5) Кнопка отображения областей.
В активном состоянии позволяет окнам рендерить области.

6) Кнопка просмотра сторон коллизии.
В активном состоянии заставляет все мэшевые волюмы рендериться с отображением
своих сторон. (Возможность рендера и просмотра волюмов при этом должна быть включена.)

7) Кнопка глобального режима закраски всех мэшей.
Во включенном состоянии отображает все мэши, закрашенными цветами своих костей.
(Отключает глобальные режимы закраски выделенной кости и выделенной ветви костей.)

8) Кнопка режима закраски действительно подкрашенных мэшей.
Закраска мэшей цветами костей, где активен параметр цвета.

9) Кнопка глобального режима отображения всех векторов мэшей.
Позволяет просматривать расположение и направление пивотов всех мэшей.

10) Кнопка прозрачного рендера волюмов в 3D-окне.
Во включенном состоянии отображает волюмы прозрачными.
(При этом должен быть включен режим просмотра, предусматривающий просмотр волюмов.)

11) Кнопка вызова окна настройки цветов.
Вызывает соответствующее окно.
(Об этом будет рассказано позже.)

12) Подменю настройки фоновой сетки.

А) Кнопка включения фоновой сетки в 2D-окнах.
Б) Кнопка выключения фоновой сетки в 2D-окнах.
В) Кнопка увеличения размера фоновой сетки во всех окнах.
Г) Кнопка уменьшения размера фоновой сетки во всех окнах.

13) Подменю настройки отображения Лодов.

А) Кнопка отображения мэшей лодов всех уровней.
Лоды наслаиваются друг на друга и могут создавать визуальную мешанину.

Б) Кнопки отображения соответствующих уровней лодирования там, где это возможно.
Если лода, соответствующего уровню нет, то отображаться будет более ранний
(вплоть до главного мэша), если не включена кнопка «Г».

В) Кнопка скрытия лодов.
Г) Кнопка запрета отображения лодов, не относящихся к выбранному уровню.

14) Подменю камер.

А) Кнопка сброса положения всех камер.
Б) Кнопка копирования положения 3D-камеры в буфер обмена виндовс в виде нескольких цифр.
В) Кнопка вставки положения 3D-камеры из буфера обмена виндовс.

Примечания:
1) Кнопка просмотра сторон коллизии.
Так отображаются волюмы при неактивной функции:

А так — при активной:

2) Кнопка глобального режима закраски всех мэшей.
Так отображаются мэши в не закрашенном виде:

А так — в закрашенном:

3) Мэши редко имеют окраску в своих костях. Поэтому там, где её нет, программа
генерирует её после загрузки модели. Эти цвета не портируются в модель,
если это не установлено в настройках костей.

4) Закраска помогает взаимодействовать с объектами на контрасте.

5) Закраска цветами костей не отменяет и не меняет ни настройки закраски вертексов
своими цветами, ни работу режимов смешивания.

6) В некоторых моделях предусмотрена необходимость подкраски некоторых костей.
(Бездумно отключать эту галочку не стоит.)

7) Демонстрация работы глобального режима отображения всех векторов мэшей.

7.1) Красный — X, зелёный — Z, синий — Y.
7.2) На отрисовку оказывают влияние цепи матриц.

8) Кнопка прозрачного рендера волюмов в 3D-окне.
Так отображаются волюмы при активной функции:

А так — при неактивной:

В сочетании со включенным режимом просмотра сторон коллизии и режимом просмотра
коллизии позволяет дотошно просматривать модель коллизии.

9) В 3D-окне фоновая сетка включается/выключается кнопкой в своём собственном меню.

10) Подменю настройки отображения Лодов.
Пример со всеми включенными лодами:

Пример с запретом отображения мэшэй не из первого уровня лодов:

(Главные мэши костей — это нулевой уровень лодов.)

11) Подменю камер — кнопка копирования положения 3D-камеры в буфер обмена виндовс в виде нескольких цифр.
Выглядеть эти цифры могут, например, так:

Главное меню — Справка.

1) Кнопка вызова окна «О программе».
(Об этом будет рассказано позже.)

2) Кнопка справки в интернете.
Открывает эту справку в интернете.

Тулъ-бар.

В тулбар просто вынесены некоторые функции из главного меню.

Дерево компонентов (модель).

1) Строка поиска элемента по названия в дереве компонентов.
Сначала ищет полное совпадение, затем — частичные.
При нахождении полного совпадения выделяет элемент в дереве компонентов и переводит туда фокус.
Если полных совпадений несколько (одноимённые кость и волюм),
то можно несколько раз нажать «Enter» в поисковике.
При частичных совпадениях — выделяет элемент в дереве компонентов, но не переводит туда фокус.

2) Заголовок костей. (Основание скелета.)
3) Кости модели.
4) Заголовок волюмов.
5) Волюмы.
6) Заголовок препятствий. (Обстаклов.)
7) Препятствия.
8) Заголовок областей. (Арей.)

У всех вышеперечисленных объектов модели (кроме первого)
есть меню, вызываемые по нажатию на них ПКМ (правой кнопки мыши).

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

Примечание:
Открытие меню во время воспроизведения анимации невозможно.

Общая информация по дереву компонентов:

Весь выбор элементов в SOEdit выполняется при помощи дерева компонентов.

Выделять элементы можно нажатием на них ЛКМ (левой кнопки мыши)
или ПКМ (но это приводит к вызову соответствующего меню).

Для раскрытия/сворачивания вложенных элементов в основном можно либо нажимать
ЛКМ на значках «+» и «-» перед названием элементов, либо нажимать
Ц(С)КМ (центральную/среднюю кнопку мыши) на элементе.

Выключение/включение птички перед названием элемента приводит к соответствующему
запрету/разрешению рендера этого конкретного элемента.
(Но для реального рендера нужно, чтобы и всему классу объектов выл разрешён рендер,
и чтобы был включен режим просмотра, позволяющий отображение таких объектов.)

Выключение/включение заголовочных птичек — выключает/включает рендер
соответствующих классов объектов.
Эти переключатели синхронизированы с аналогичными в «Главное меню -> Отображение».

(Выключать/включать эти галочки можно и по кнопке «пробел».)

Двойной клик ЛКМ по заголовкам приводит к их открытию/закрытию.
Двойной клик ЛКМ по элементам вызывает соответствующие окна для их редактирования.

Нажатие кнопки «Del» удаляет выбранный элемент.
(Предварительно запрашивается подтверждение.)

Нажатие кнопки «Enter» на элементе вызывает соответствующее окно редактирования.

Дерево компонентов — Меню заголовка костей (Скелета).

1) Кнопка добавления вложенной кости.
Добавляет кость в основание скелета.
Предлагает на выбор: добавить мэш-файл или вообще отказаться от добавления.

Примечания:
1.1) При добавлении из мэш-файла кость автоматически получает имя мэш-файла.
1.2) При добавлении первой кости без меша она автоматически именуется «basis».
1.3) Почти всегда первая в иерархии кость должна быть инверсной и иметь матрицу:
1 0 0 | 0 -1 0 | 0 0 1.

2) Кнопка разворачивания всего скелета.
Разворачивает все ветви дерева костей.

3) Кнопка вызова окна редактирования глобальных анимаций.
(Об этом будет рассказано позже.)

Дерево компонентов — Меню кости.

1) Кнопка добавления вложенной кости.
Добавляет кость в выбранную кость.
Предлагает на выбор: добавить мэш-файл или вообще отказаться от добавления.

При добавлении мэш-файла кость автоматически получает имя мэш-файла.

2) Кнопка удаления кости/ветви костей.
Удаляет выбранную кость/ветвь костей.
Запрашивает подтверждение.

Если в кости/ветви есть волюмная привязка, то дополнительно
предлагает на выбор: удалить волюмы из модели или вообще отказаться от удаления.

3) Кнопка перехода к родительской кости.
Выбирает родительскую кость выбранной кости.

4) Кнопка редактирования кости.
Открывает окно редактирования выбранной кости.
(Об этом будет рассказано позже.)

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

5) Подменю копирования.
6) Кнопка копирования кости.
Копирует выбранную кость в буфер обмена виндовс.

7) Кнопка копирования ветви кости.
Копирует ветвь выбранной кости в буфер обмена виндовс.

8) Кнопка копирования матрицы кости.
Копирует матрицу выбранной кости во внутреннюю память программы.

9) Кнопка копирования параметров кости.
Копирует параметры кости во внутреннюю память программы.

10) Подменю вставки.
11) Кнопка вставки кости/ветви костей как следующей.
Вставляет ранее скопированную кость/ветвь костей как следующую после выбранной кости.

12) Кнопка вставки кости/ветви костей как вложенной.
Вставляет ранее скопированную кость/ветвь костей как вложенную в выбранную кость.

13) Кнопка вставки матрицы в кость.
Вставляет ранее скопированную матрицу в выбранную кость.

14) Кнопка вставки параметров.
Вставляет ранее скопированные параметры кости в в выбранную кость.

15) Кнопка вырезания кости/ветви костей.
Вырезает ветвь выбранной кости в буфер обмена виндовс.

16) Кнопка разворачивания ветви.
Разворачивает ветвь выбранной кости.

17) Кнопка сворачивания ветви.
Сворачивает ветвь выбранной кости.

18) Подменю отображения.
19) Подменю скрытия.
(Содержат одинаковый набор обратных по смыслу функций.)

20) Кнопка скрытия/показа ветви костей.
В зависимости от подменю скрывает/отображает кости выбранной ветви.

21) Кнопка скрытия/показа коллизии ветви костей.
В зависимости от подменю скрывает/отображает волюмы выбранной ветви.

22) Кнопка скрытия/показа коллизии ветви костей и самой ветви костей.
В зависимости от подменю скрывает/отображает кости и волюмы выбранной ветви.

23) Кнопка добавления волюма к кости.
Предлагает на выбор варианты добавления волюма в выбранную кость,
а т.ж. возможность отказа от действия.

При добавлении из мэш-файла волюм автоматически получает имя мэш-файла.

24) Кнопка обновления мэша в мэшевой кости.
Перезагружает PLY-файл в выбранной кости с учётом модов.

25) Кнопка удаления мэша из мэшевой кости.
Удаляет мэш из выбранной кости.
(Мэш заменяется плейсхолдером.)

26) Кнопка добавления лода.
Предлагает выбор мэш-файла лода кости.
(Нельзя добавить лод к безмэшевой кости.)

27) Подменю анимации.
28) Кнопка добавления кости в анимацию.
Добавляет выбранную кость в текущую открытую/созданную анимацию.

29) Кнопка удаления кости из анимации.
Удаляет кость из текущей открытой/созданной анимации.
(Но в анимации не может быть ноль костей.)

30) Кнопка принудительного закрашивания.
Принудительно заставляет кость отображаться в закрашенном виде.
(Повторное нажатие кнопки отменяет принудительную закраску.)

31) Кнопка выбора нового случайного цвета кости.
Выбирает новый случайный цвет для выбранной кости.

32) Подменю типа закраски.
33) Кнопка перевода закраски в режим по умолчанию.

34) Кнопка принудительного отображения кости в виде сетки.

35) Кнопка принудительного отображения кости заливкой.

Примечания:
1) Файлы выбранной кости/ветви костей никуда не вырезаются и не копируются.
Вырезаются/копируются только текстовые записи скелета.

2) Чтобы объекты отображались, должен быть активен режим отображения
соответствующих объектов, а т.ж. выбран режим визуализации, позволяющий это.

3) Принудительное отображение кости в виде сетки или заливкой помогает лучше
ориентироваться в интерьере и экстерьере модели.

Дерево компонентов — Меню заголовка волюмов.

1) Кнопка добавления нового волюма.
Предлагает на выбор варианты добавления волюма,
а т.ж. возможность отказа от действия.

При добавлении из мэш-файла волюм автоматически получает имя мэш-файла.

2) Кнопка вставки волюмов.
Вставляет ранее скопированные волюмы из буфера обмена виндовс в конец списка волюмов.

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

Дерево компонентов — Меню волюма.

1) Кнопка удаления волюма.
Удаляет выбранный волюм.
Запрашивает подтверждение.

2) Кнопка редактирования волюма.
Открывает окно редактирования выбранного волюма.
(Об этом будет рассказано позже.)

3) Кнопка копирования волюма.
Копирует выбранный волюм в буфер обмена виндовс.

4) Кнопка вставки волюма.
Вставляет ранее скопированные волюмы из буфера обмена виндовс в конец списка волюмов.

5) Кнопка копирования матрицы волюма.
Копирует матрицу выбранного волюма во внутреннюю память программы.

6) Кнопка вставки матрицы в волюм.
Вставляет ранее скопированную матрицу в выбранный волюм.

7) Кнопка перехода к кости.
Выбирает кость, к которой привязан выбранный волюм.

8) Кнопка обновления мэша волюма.
Перезагружает VOL-файл выбранного волюма с учётом модов.

9) Кнопка принудительного закрашивания волюмов.
В режиме просмотра коллизии и при отключенной опции прозрачности выделенного
волюма (из меню 3D-окна) позволяет демонстрировать множество модулей (включая внутренние).
Просмотр сторон коллизии работает только для реально выбранного волюма.
(Но можно и включить глобальный режим просмотра коллизии.)

Дерево компонентов — Меню заголовка препятствий/областей.

1) Кнопка добавления новой зоны.

2) Кнопка вставки зон.
Вставляет ранее скопированные зоны из буфера обмена виндовс в конец списка зон.

Дерево компонентов — Меню препятствия/области.

1) Кнопка удаления зоны.
Удаляет выбранную зону.
Запрашивает подтверждение.

2) Кнопка редактирования зоны.
Открывает окно редактирования выбранной зоны.
(Об этом будет рассказано позже.)

3) Кнопка копирования зоны.
Копирует выбранную зону в буфер обмена виндовс.

4) Кнопка вставки зоны.
Вставляет ранее скопированные зоны из буфера обмена виндовс в конец списка зон.

5) Кнопка добавления вертекса к полигональной зоне.
Добавляет новый вертекс с координатами X=0, Y=0 в конец списка вертексов.

Примечания:
1) Изначально планировалось, что отдельные вертексы можно будет перетаскивать
мышкой в 2D-окне. Но в этой версии это не было реализовано.

2) Напрямую копипастить препятствия/области между собой нельзя.
Для этого нужно скопировать зону в блокнот изаменить заголовок на требуемый:

{Area "example" — Область.
[бла-бла-бла]
}
{Obstacle "example" — Препятствие.
[бла-бла-бла]
}
Затем скопировать полученную зону в требуемый раздел.

Блок воспроизведения и быстрого редактирования скелетной анимации.

1) Ползунок перемотки анимации.
2) Индикатор текущего и общего количества кадров.
3) Текстовое поле для отображения пути используемой анимации.
4) Кнопка выбора анимации из папки открытого MDL-файла.
5) Кнопка перемотки анимации на один кадр назад.
6) Кнопка старта воспроизведения аниации.
7) Кнопка перемотки анимации на один кадр вперёд.
8) Кнопка приостановки/продолжения воспроизведения аниации.
9) Кнопка остановки воспроизведения аниации.
(Переводит ползунок анимации на первый кадр.)

10) Блок управления скоростью воспроизведения анимации.
11) Кнопка переключения режима воспроизведения «Повторять/Без повторов»
(Текущий режим равен противоположному от надписи на кнопке.)

12) Индикатор режима редактирования.
В режиме редактирования скелета при перемещении костей в 2D-окнах меняется
координата кости в самом скелете.
В режиме редактирования анимации при перемещении костей в 2D-окнах меняется
координата кости в текущем кадре анимации.

13) Индикатор-переключатель режима копирования матрицы в следующие кадры.
Во включенном состоянии при изменении положения анимированной кости
копирует это положение во все последующие кадры для этой кости.
(Повышает удобство покадрового создания анимации. Главное — не менять
предыдущие кадры, когда этот режим включен.)

14) Кнопка вставки кадра.
Клонирует текущий кадр, вставляет его следующим после
текущего и смещает ползунок текущего кадра вперёд на один кадр.

15) Кнопка удаления текущего кадра.
16) Кнопка назначения кадра для копирования.
Сообщает программе, что текущий кадр назначен для копирования.

17) Кнопка вставки назначенного кадра.
Вставляет ранее назначенный кадр после текущего и смещает ползунок текущего кадра вперёд на один кадр.

18) Кнопка добавления инверсии анимации в конец анимации.
(Помогает анимировать некоторые лючки и прочие объекты, имеющие обратное движение.)

19) Кнопка инвертирования всей анимации.
Разворачивает всю последовательность кадров задом-наперёд,
чтобы анимация воспроизводилась в обратную сторону.

Примечания:
1) В блоке скорости (Пункт 10), программа сама старается выставить ту
скорость, что будет у анимации в игре.
Но вы можете сами прописать нужную скорость в текстовом поле или перемотать её кнопками. (Шаг кнопок = 0.1.)

2) Значения скорости (Пункт 10) ограничены [-10; 10].

3) Режим редактирования анимации (Пункт 12) активируется только для анимированных костей.
(То есть тех, которые есть в текущей анимации.)

4) Перемещение анимированной кости на первом кадре по умолчанию запрещено,
чтобы случайно не испортить модель и не сломать синхронизацию.

Окна просмотра и редактирования модели.

Программа располагает тремя (ортогональными) 2D-окнами для редактирования
и одним 3D-окном (с видом по перспективе) для просмотра готового результата.

2D-окна. Отображение.

По умолчанию 2D-окна настроены на отображение трёх ракурсов:
Верхнее-левое — Вид спереди;
Верхнее-правое — Вид справа;
Нижнее-левое — Вид сверху.
(Текущий ракурс отображается в верхнем-левом углу.)

Модели отображаются в виде безтекстурных сеток с отображаемыми задними гранями.
Отображение плейсхолдеров безмэшевых костей выполняется вместе с мэшевыми костями.

Отображение в 2D-окнах в основном подчиняются глобальным настройкам
отображения из вкладки «Главного меню -> Отображение».
Но также эти окна обладают как собственными локальными настройками отображения,
так и имеют возможность влиять на некоторые глобальные настройки через вызываемое по ПКМ меню:

1) Кнопки выбора ракурсов.
2) Кнопка включения/выключения задних граней.
3) Кнопки выбора режима отрисовки.
4) Кнопки выбора режима закраски.
5) Кнопка включения/выключения фокусировки на выбранном.

Примечания:
1) Касаемо кнопки задних граней (Пункт 2):
Изначальный автор писал, что переключение этой кнопки помогает определить
правильность построения мэша (правильность расположения порядка вершин).
Но сейчас эта функция фактически рудиментарна. Отключение этой кнопки может
иметь смысл разве что в том, чтобы немного разгрузить визуал. Но фактически
удобнее особо не становится, а правильность мэша удобнее определять в 3D-окне.

2) По-умолчанию в качестве режима отрисовки (Пункт 3) выбрана сетка.
Но включение сплошной закраски позволяет лучше сконцентрироваться на выбранном объекте.

3) Кнопки выбора режима закраски (Пункт 4) влияют на глобальный режим закраски мэшей
и позволяют включать/переключать/выключать выбранные режимы.
(Нажатие на кнопке с включенным флажком отключает глобальный режим закраски.)
Кнопка закраски всех мэшей копирует эту же функцию из вкладки «Главное меню -> Отображение».
(Смотри описание оттуда.)

Включение режима закраски ветви костей позволяет удобнее манипулировать полноценным модулем (ветвью костей).

4) Кнопка фокусировки на выбранном (Пункт 5) копирует эту же функцию
из вкладки «Главное меню -> Отображение».
(Смотри описание оттуда.)

2D-окна. Управление камерой.

Управление камерой выполняется при помощи мыши с зажатой Ц(С)КМ.
(При этом создаётся эффект перемещения всей сцены в этом 2D-окне.)
Масштабировать сцену можно при помощи колеса мыши.

2D-окна. Редактирование.

Редактирование в 2D-окнах выполняется с помощью манипуляторов типа «мышь» и «клавиатура».
С их помощью вы можете манипулировать будущим мнением игроков о созданном вами моде.

Редактировать (перемещать, вращать, масштабировать) возможно только объекты, выбранные в дереве компонентов.

Редактирование только с помощью клавиатуры перманентно работает в режиме
перемещения и выполняется кнопками WASD и кнопками «стрелок» (дублируют WASD).
(Выбор режима взаимодействия тут не требуется и ни на что не влияет.)
При этом перемещение возможно только в одну из четырёх сторон.

Редактирование с помощью мыши и клавиатуры требует выбора режима взаимодействия.
Например: Сначала можно выбрать режим взаимодействия (он останется активен до
переключения на другой режим) затем нужно выбрать объект в дереве компонентов,
и после этого им можно будет манипулировать в 2D-окне.

При редактировании с помощью мыши воздействие одновременно идёт по осям X и Y относительно экрана.
(Точнее, оно должно было так работать, но не всегда это работает так. Но об этом позже).

Для блокирования воздействия по оси X — нужно удерживать нажатой кнопку «Shift» на клавиатуре.
Для блокирования воздействия по оси Y — нужно удерживать нажатой кнопку «Ctrl» на клавиатуре.

Примечания:
1) Одновременно можно воздействовать на объект при помощи мыши и перемещать его
при помощи кнопок на клавиатуре, но это не вполне удобно.

2) Редактирование положения костей в 2D-окне во время воспроизведения анимации невозможно.

3) Программа сильно недоработана. Это важное примечание. Поэтому повторю:
«Из-за несовершенства подсистемы матричного анализа, от работы которой зависит
синхронизация действий курсора с воздействием на объект, работоспособность функций
перемещения, вращения и масштабирования сильно зависит от прямоты результирующей дообъектной матрицы.
Сопряжение работает только с более-менее прямой цепью нескалированных матриц от
базиса и до объекта перемещения (но не включая его).
А это значит, что матрицы должны быть под прямыми или развёрнутыми углами
(в независимости от их инверсности).
И все векторы проекций во всех матрицах (до матрицы выделенного объекта) должны быть единичной длины!
Никаких поворотов и масштабирований в цепи перед перемещаемым объектом быть не должно!»
Волюмы также опираются на кости, поэтому тоже подвержены этой проблеме.
Если цепи матриц будут сильно искажены то, либо будут паразитные боковые движения,
либо движение будет блокироваться вообще.
Касаемо зон. Их сначала нужно масштабировать, и только после вращать.
Программа капризна — это придётся принять.

3D-окно. Отображение.

По умолчанию камера как бы «лежит» на земле, смотря в сторону «лица» модели.

При загрузке модели программа сбрасывает режим отображения на «Затенённый»,
сбрасывает локальный и глобальный режим закраски и сразу старается найти и загрузить текстуры.
(Пока что каждый отдельный запрос на текстуру или материал выполняется отдельно.)

Хоть отображение в 3D-окне в основном и подчиняются глобальным настройкам
отображения из вкладки «Главное меню -> Отображение», но 3D-окно имеет немало локальных настроек,
некоторые из которых могут дублировать или вовсе замещать глобальные.
Также, по аналогии с 2D-окнами, 3D-окно само имеет возможность влиять и на некоторые
глобальные настройки отображения.
За настройки отображения также отвечает меню окна, вызываемое через ПКМ.

Хоть в расположении кнопок есть некоторый хаос, который, вероятно,
будет ещё перетасован, но для версии «v0.7m5*» расположение таково:

1) Кнопки выбора режима отображения.
(Эти режимы влияют и на отображение суб. режимов.)

1.1) Затенённый режим:

Это нормальный вид модели
Модель отображается в цельном затенённом текстурированном виде.
Затенение работает по принципу реакции вертексных нормалей на расположение источника освещения сцены.

1.2) Текстурированный режим:

Всё тоже самое, что и в затенённом режиме, но отключается реакция нормалей на источник освещения.
Геометрия теряет тени, картинка становится равномерно светлой.
Этот режим бывает полезен при работе в тёмных, труднодоступных местах.

1.3) Режим сетки:

Сцена принудительно рендерится в виде сетки.
Это бывает полезно для просмотра скрытой геометрии и оценки общей детализации модели.

1.4) Режим без текстур:

Сцена рендерится в цельном затенённом виде.
Дополнительно включается локальный режим закраски мэшей нескучными цветами.
Вместо буфера индексов текстур видеодрайверу начинают подсовываться нули, но сами
текстуры остаются в памяти видеокарты для их дальнейшего использования.
Режим позволяет определить корректность реакции геометрии на освещение.

Закраску можно по желанию или отключить полностью:

Или принудительную включить закраску какой-нибудь кости через меню в дереве компонентов.

Или включить какой-нибудь глобальный режим закраски.

1.5) Режим сетки без текстур:

Сцена принудительно рендерится в виде сетки.
Дополнительно включается локальный режим закраски мэшей.
Тут почти всё тоже самое, что и в предыдущем варианте.
Помогает оценить детализацию конкретных мэшей и ветвей мэшей.

2) Кнопка включения/выключения локального режима закраски мэшей.

При включении закрашивает все мэши в 3D-окне.
При выключении — убирает закраску.
(Если при этом был включен глобальный режим закраски всех мэшей, то отключается и он.)

3) Кнопка включения/выключения локального режима отображения безмэшевых костей.

Отображает/скрывает плейсхолдеры безмэшевых костей в 3D-окне.

Плейсхолдеры представлены в виде фигуры типа «клин».

Здесь стороны обозначают оси:
Красный — X;
Зелёный — Z;
Синий — Y.

Не выделенные плейсхолдеры по умолчанию просто закрашиваются зелёным цветом:

Выделенные плейсхолдеры по умолчанию закрашиваются в разовый.
Но правая сторона красится в зелёный, а левая — в синий.

4) Кнопка включения/выключения фокусировки на выбранном.
Эта кнопка копирует ту же функцию из вкладки «Главное меню -> Отображение».
(Смотри описание оттуда.)

5) Кнопка отрисовки цветной сетки поверх мэшей.

Включает/выключает цветную сетку поверх мэшей костей.
Бывает полезно при необходимости точного редактирования тёмных поверхностей.
(Но роняет FPS программы вдвое из-за дублирования геометрии в рендере.)

6) Кнопка локального режима отображения фоновой сетки.

Выключает/включает фоновую сетку по центру сцены.

7) Подменю со свалкой менее нужных кнопок.
(Свалка кнопочек, которые мне бы не хотелось видеть при первоначальном открытии меню.)

8) Кнопки выбора режима просмотра.
8.1) Режим просмотра внешнего вида.

Это режим по умолчанию.

8.2) Режим просмотра коллизии.

Позволяет просматривать только коллизию.
Прозрачность можно отключить во вкладке «Главное меню -> Отображение».

Выделенные волюмы подсвечиваются.

Если волюм мэшевый, то его стороны раскрашиваются в цвета назначенных им сторон.

Примечание:
Рендер в программе сверхпримитивен.
Для корректного отображения геометрии требуется корректное определение глубины полигонов.
Так как никакого вертексного шейдера в программе нет, и так-как данные, поступающие
на отрисовку представляют из себя кучу мусора, то и определение глубины
работает некорректно. (Частично исправлено.)
Из-за этого выделенные волюмы визуально могут быть невидны.
(Возможно, вам придётся включать функцию фокусировки на выбранном.)

8.3) Гибридный режим.

Позволяет просматривать визуальную модель вместе с коллизией.

9) Кнопки включения/выключения суб. режима «сетки» для разных типов сущностей.
9.1) Отображение коллизии как сетки.

(Этот суб. режим имеет смысл только при отображении коллизии.)

9.2) Отображение сущностей без мэшей (плейсхлодеров) как сетки.

(Этот суб. режим имеет смысл только при отображении плейсхлодеров.)

9.3) Отображение сущностей (мэшей) как сетки.

(Этот суб. режим имеет смысл только при отображении костей с мэшами.)

10) Кнопки выбора глобального режима закраски.
10.1) Закрашивать выделенный мэш.

Мэш выделенной кости красится цветом своей кости.
Это работает только в 3D-окне.
В 2D-окне такой мэш по-умолчанию будет краситься просто в красный.

10.2) Кнопки закраски ветви выделенной кости и всех мэшей копируют эти же функции из меню 2D-окна.
(Смотри описание оттуда.)

11) Кнопка включения/выключения отображения вектора выделенного мэша.

Копирует ту же функцию из вкладки «Главное меню -> Отображение».
(Смотри описание оттуда.)
Но работает только для мэша выделенной кости.

12) Кнопка включения/выключения прозрачности выделенного волюма.

Копирует эту же функцию из вкладки «Главное меню -> Отображение».
(Смотри описание оттуда.)
Но работает только для выделенного волюма.

3D-окно. Визуализация параметров.

В верхнем левом углу отображается строка с именем и некоторыми параметрами выбранного объекта.

Жёлтым цветом на чёрном фоне обозначаются кости.
Голубым цветом на чёрном фоне обозначаются волюмы.
Зелёным цветом на чёрном фоне обозначаются препятствия.
Розовым цветом на чёрном фоне обозначаются области.

Первым словом идёт имя объекта.
Если у объекта нет имени, то вместо него пять раз пишется сообщение «{NO NAME!!!}»,
сообщающее об отсутствии имени.
А вся строка меняет цветовую схему на красный текст на жёлтом фоне.

После этого могут идти следующие обозначения:
[M] — Кость/волюм имеет мэш.
[NM] — Кость/волюм не имеет мэша.
[H] — Объект выключен в дереве компонентов (скрыт).
[A] — Кость имеет собственный блок анимаций.
[K] — Кость имеет кинематику.
[INVIS] — Кость скрыта (в том числе в игре).
[FORCED COLORED] — Кость или волюм принудительно закрашены.
(Через кнопку в дереве компонентов.)
[S] — Кость имеет скиновую привязку.
[L/S] — Кость отмечена как (является)/имеет ЛОД/Суб. мэш.
[PARAM=""] — Параметры кости.
[RW] — Принудительный рендер в виде сетки.
[RP] — Принудительный рендер заливкой.
[BONE=""] — Кость привязки волюма.
Если кость привязки волюма не существует, то вместо неё пять раз
пишется сообщение «{NO BONE!!!}», сообщающее об отсутствии требуемой кости.
А вся строка меняет цветовую схему на красный текст на жёлтом фоне.
[TAGS=""] — Тэги зон.

3D-окно. Управление камерой.

Управление камерой выполняется при помощи мыши и клавиатуры.

Позицию камеры можно изменять перемещая мышь с нажатой Ц(С)КМ.
Камера перемещается вдоль визуальных осей окна в противоположную от курсора сторону.
(Камеру можно зуммировать, перемещая мышь с нажатой ЦКМ и нажатой на клавиатуре
кнопкой «Ctrl». Но этот режим не доделан и им лучше не пользоваться.)

Направлением камеры можно изменять перемещая мышь с нажатой ЛКМ.
Камера меняет направление, следуя за курсором.

Позицией камеры можно управлять прокручиванием колеса мыши.
Камера будет двигаться вперёд по курсу своего направления при прокрутке колеса вверх,
и реверсивным курсом при прокрутке колеса вниз.

У камеры также есть режим «полёта».
Для его активации нужно нажать ЛКМ и одну из кнопок направления движения на клавиатуре:
Кнопка «W» (или кнопка «стрелка вверх») перемещает камеру вперёд по курсу своего направления.
Кнопка «S» (или кнопка «стрелка вниз») перемещает камеру назад против курса своего направления.
Кнопка «A» (или кнопка «стрелка влево») перемещает камеру влево от курса своего направления.
Кнопка «D» (или кнопка «стрелка вправо») перемещает камеру вправо то курса своего направления.
Кнопка «Q» перемещает камеру вниз.
Кнопка «E» перемещает камеру вверх.

При дополнительном нажатии кнопки «Shift» скорость будет замедляться втрое.
А при нажатии «Ctrl» увеличиваться вдвое.

3D-окно. Управление источником освещения.

Условным источником глобального освещения в 3D-окне является моделька лампочки.
По умолчанию она находится на по-центру сцены, на некоторой высоте над моделью.

Перемещая её, можно «подсвечивать» модель с разных сторон:

Перемещать её в горизонтальной плоскости можно мышью с нажатой Ц(С)КМ и нажатой на клавиатуре кнопкой «Shift».
Для перемещения в вертикальной плоскости нужно дополнительно держать нажатой кнопку «Ctrl».

Примечания:
1) Источник освещения не настоящий. Никаких теней в привычном смысле он не создаёт.
(В программ даже шейдеров таких нет.)
Источник освещения просто заставляет полигоны самозатеняться согласно направлениям нормалей их вертексов.

2) Если какое-либо из окон становится белым (одноцветным) и перестаёт реагировать на
действия пользователя, то, вероятнее всего, случилась критическая ошибка (как правило в,
рендере) и окно ушло в режим защиты. Этот режим не снимается до перезапуска программы.

3) Если какая-либо текстура/материал не могут загрузиться, то вместо
них генерируется текстура «шахматной доски».

Окна программы — Окно настройки преференций.

Позволяет выбирать каталоги игры и модов.
Можно либо использовать окно выбора каталога (по кнопке троеточия), либо просто
скопипастить путь из проводника.
(Данные из этого окна сохраняются в реестре при закрытии программы,
а т.ж. загружаются в программу при её запуске.)

Окна программы — Окно свойств «Хламосборник».

А) Блок копирайтов.
Сюда выводится:
Информация о сборщике/экспортёре модели;
Информация о создателе PLY и VOL-файлов.
(Использовалось в некоторых древних моделях);
Дата и время экспорта и последней сборки модели.
(Время экспорта приоритетнее времени сборки);
Путь и название экспортированного файла.
Никнейм текущего пользователя программы.
(Никнейм, желательно, должен быть на латинице и не превышать сотни символов.)

Б) FOV – угол обзора камеры в 3D-окне.
(Диапазон от 20 до 120.)

В) Опция отображения RAM-волюма в 3D-окне без выделения.
Г) Опция отображения главных волюмов траков в 3D-окне без выделения.
(TrackLeft, TrackRight, TrackL, TrackR.)

Д) Опция отображения волюма выбора юнита (Select).

Е) Опция отображения модельки лампочки в 3D-окне.
(Условный индикатор источника освещения.)

Ё) Опция скрытия сообщений об отсутствующих ИД`шниках костей.
(Отсутствие идентификации не всегда является ошибкой.)

Ж) Кнопка подтверждения.
З) Кнопка отмены.

Примечания:
1) Данные из пунктов: «А:Ваш никнейм», «Б», «В», «Г», «Д», «Е» сохраняются в реестр
при закрытии программы и загружаются в программу при её запуске.

2) Не надо привыкать пользоваться пунктом «Ё».

Окна программы — Окно редактирования анимации.

А) Указатель текущего кадра.
Б) Индикатор общего кол-ва кадров.
В) Матрица для выбранной кости на текущем кадре.
Г) Кнопка копирования матрицы в общую память программы.
Д) Кнопка вставки матрицы из общей памяти программы.
Е) Список костей. Взаимодействие окна ведётся с костью, выбранной в этом списке.
Ё) Текстовое поле для переименования выбранной кости.
Ж) Переключатель значения видимости этой кости на текущем кадре.
З) Кнопка клонирования выбранной кости под новым именем.
(На случай необходимости одинаково анимировать несколько разных лючков.)

И) Кнопка экспорта анимации выбранной кости во внешний ANM-файл.
(Как правило, бывает нужно для экспорта кусочка анимации из одной модели в другую
при создании одной модели из кусочков других моделей.)

Й) Кнопка импорта скелетной анимации из внешнего ANM-файл.
(Как правило, нужна для импорта файла, недавно созданного по предыдущей кнопке.)

К) Текстовое поле, в котором отображается путь текущего файла анимации.
Л) Кнопка вставки клона текущего кадра после себя.
М) Кнопка удаления текущего кадра.
Н) Кнопка удаления текущей выбранной кости.
О) Индикатор версии анимации из текущего файла анимации.
П) Кнопка подтверждения и закрытия окна.
Р) Кнопка вставки позиции из текстового файла анимации.
С) Кнопка вставки кватерниона из текстового файла анимации.

Примечания:
1) Для текстового поля «Ё» допускается название состоящее из:
Латинских букв, цифр от 0 до 9 и символов в кавычках: «_-+*();[] .,=».
(Кол-во символов ограниченно 30.)

2) Увы, но и в этой версии — без автоматизации.
3) Кнопка импорта «Й» может импортировать только ANM-файл версии 0.4.0.0,
т.к. для этого окна не работает инверсно-кватернионный преобразователь из модуля рэндера.

4) Нельзя удалять последнюю кость из анимации.
5) У некоторых моделей могут отсутствовать файлы анимации (удалённые мододелом),
но могут присутствовать сопроводительные файлы анимации «anim.txt».
В этом случае, кнопками «Р» и «С» можно восстановить анимацию.
Смотри:
https://www.youtube.com/watch?v=93F0-Gi0yhA
https://rutube.ru/video/679062266a7d4308f0997ece9fe714ad/

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

Окна программы — Окно настройки цветов.

А) Перечень окрашиваемых параметров.
А.1) "2D Background" — Цвет фона в 2D-окнах.
А.2) "3D Background" — Цвет фона в 3D-окне.
А.3) "Grid" — Цвет сетки в 2D-окнах.
А.4) "Grid 3D" — Цвет сетки в 3D-окне.
А.5) "Axis" — Цвет оси сетки в 2D-окнах.
А.6) "Mesh (PLY)" — Цвет не выбранного мэша кости в 2D-окнах.
А.7) "Mesh (PLY) Selected" — Цвет выбранного мэша кости в 2D-окнах.
А.8) "Volume" — Цвет не выбранного волюма во всех окнах.
А.9) "Volume Selected" — Цвет выбранного безмэшевого волюма во всех окнах.
А.10) "Entity" — Цвет не выбранного плейсхолдера кости без мэша.
А.11) "Entity Selected" — Цвет выбранного плейсхолдера кости без мэша.
А.12) "Obstacle" — Цвет не выбранного обстакла.
А.13) "Obstacle Selected" — Цвет выбранного обстакла.
А.14) "Area" — Цвет не выбранной зоны.
А.15) "Area Selected" — Цвет выбранной зоны.
А.16) "Mesh (VOL) Front" — Цвет фронтальной стороны мжшэвого волюма.
А.17) "Mesh (VOL) Rear" — Цвет задней стороны мжшэвого волюма.
А.18) "Mesh (VOL) Right" — Цвет правой стороны мжшэвого волюма.
А.19) "Mesh (VOL) Left" — Цвет левой стороны мжшэвого волюма.
А.20) "Mesh (VOL) Top" — Цвет верхней стороны мжшэвого волюма.
А.21) "Mesh (VOL) Bottom" — Цвет нижней стороны мжшэвого волюма.

Б) Кнопка вызова окна выбора цвета для выбранного параметра.
(Вызывает стандартный цветовой диалог.)

В) Панель отображения цвета выбранного параметра.
Г) Кнопка подтверждения.
Д) Кнопка отмены.

Окна программы — Окно «О программе».

В этом окне отображается:
1) Версия программы.
2) Копирайты.
3) Ссылки.
4) Некоторая информация из рендера OpenGL.

Выражаю отдельную благодарность Man232 и GhostNT за некоторую помощь в создании программы.

Также:
Спасибо Jdoo за справочные материалы.
Спасибо Dgn за справочные материалы и помощь с переводом.

Окна программы — Окно редактирования костей.
Режим редактирования глобального блока анимаций.

А) Список анимаций.
Взаимодействие всего блока анимации выполняется с анимацией, выбранной в этом списке.

Б) Кнопка добавления новой плейсхолдер-записи об анимации «NewAnm».
Вы должны её переписать под себя. Нельзя оставлять незаполненных плейсхолдер-записей.

В) Кнопка удаления записи выбранной анимации.
(Сам файл она не удаляет.)

Г) Переключатель параметра «AutoStart».
Д) Переключатель параметра «Resume».
Е) Переключатель параметра «Store».
Ё) Переключатель параметра «Movement».
Ж) Текстовое поле названия анимации.
З) Текстовое поле коэффициента скорости воспроизведения анимации.
(0 означает отсутствие параметра и по сути = 1.)

И) Текстовое поле коэффициента сглаживания анимации.
Й) Текстовое поле названия файла анимации.
К) Кнопка выбора файла анимации.
(Если текущая анимация имеет плейсхолдерное название «NewAnm»,
то при выборе файла оно изменится на название файла.)

Л) Список событий анимации.
Взаимодействие всего блока событий анимации выполняется с событием, выбранным в этом списке.

М) Кнопка добавления новой плейсхолдер-записи о событии «NewEvent».
Н) Кнопка удаления записи выбранного события.
О) Текстовое поле названия события.
(Названия событий могут повторяться на разных кадрах.)

П) Текстовое поле кадра события.
Р) Кнопка подтверждения.
С) Кнопка отмены.

Примечания:
1) Для текстовых полей «Ж» и «О» допускается название, состоящее из:
латинских букв, цифр от 0 до 9 и символа нижнего подчёркивания.
Кол-во символов для поля «Ж» ограниченно 30.
Кол-во символов для поля «О» ограниченно 100.

2) По умолчанию считается, что имя файла анимации совпадает с его названием в модели.
Если по какой-то причине это невозможно (допустим, одинаковые служебные
названия «break/repair» на костях разных компонентов имеют разные анимации),
то для таких анимаций требуется отдельно выбирать соответствующий файл (пункты «Й/К»).

Окна программы — Окно редактирования костей.

(Блок анимаций кости был рассмотрен раньше, поэтому здесь рассматриваться не будет.)

А) Текстовое поле для переименования кости.
Б) Текстовое поле с названием родительской кости.
В) Текстовое поле для изменения пути файла мэша.
Г) Кнопка вызова окна для выбора файла мэша.
Д) Кнопка вызова окна встроенного PLY-твикера для файла текущей кости.
(Об окне твикера будет рассказано после описания этого окна.)

Е) Матрица кости.
Ё) Кнопка копирования матрицы в общую память программы.
Ж) Кнопка вставки матрицы из общей памяти программы.
З) Кнопка округления.
Округляет числа из матрицы к ближайшим целым.
(Не учитывает контекст матричного характера параметра. Ротация и скалярка сбрасываются.)

И) Переключатель параметра лодовости.
При включении переводит кость в режим лода.
Если этот параметр нельзя выключить, значит эта кость является не первой в цепи лодов или сама содержит лоды.

Й) Переключатель параметра отсечки лодирования.
При включении запрещает отображение лодов, если игра требует отображение ещё более упрощённого лода.
(Параметр сопряжён с отображением лодов в программе.)

К) Переключатель слоя рендера.
Устанавливает для не лодовых мэшей слой отображения.
(Возможен только «WaterScissor».)

Л) Переключатель параметра «NoCastShadows».
М) Переключатель параметра «NoGetShadows».
Н) Переключатель параметра «NoGroupMesh».
О) Переключатель параметра «DecalTarget».
П) Переключатель параметра «Ground».
Р) Переключатель параметра лимитов кинематики.
Активирует текстовые поля, соответствующие типу кинематики.
(Доступен только на типах кинематики, предусматривающих движение.)

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

Т) Переключатель параметра «Terminator».
У) Радио-переключатель типа параметра кинематики «Revolute».
Ф) Радио-переключатель типа параметра кинематики «Socket».
Х) Радио-переключатель типа параметра кинематики «Prizmatic».
Ц) Радио-переключатель типа параметра кинематики «None».
Выключает кинематику кости и зависимые параметры.

Ч) Блок подкраски мэша кости.
Имеет возможность выбора и отображения цвета кости через кнопку вызова стандартного цветового диалога.
При установке флажка в активное состояние цвет будет записываться в скелет модели.

Ш) Текстовое поле скорости кинематики кости.
При установке флажка в активное состояние используется второй тип скорости.
(Доступен только на типах кинематики, предусматривающих движение.)

Щ) Текстовое поле однопараметрического типа лимита кинематики.
(Доступен только при активном параметре лимита кинематики типа «Socket».)

Ъ) Текстовое поле двухпараметрического типа лимита кинематики.
(Доступен только при активном параметре лимита кинематики типа «Revolute» или «Prizmatic».)

Ы) Текстовое поле дополнительных параметров кости.
Ь) Кнопка подтверждения.
Э) Кнопка отмены.

Примечания:
1) Для текстовых полей «А» и «Ы» допускается название, состоящее из:
латинских букв, цифр от 0 до 9, и символов в кавычках: «_-+*();[] .,=».

2) Редактирования суб. мэшей и не ведущих лодов (с надписью «Лод») крайне ограничено,
так-как они по сути являются частью своей кости.
Хоть в самой программе, архитектурно являются отдельными костями.

Окна программы — Окно встроенного PLY-твикера.

А) Список скиновых привязок.
Б) Текстовое поле для изменения выбранной в списке (пункт «А») кости привязки.
В) Список материалов «мэшей» внутри PLY-файла.
Взаимодействие полей редактирования имён файлов текстур/материалов (пункт «Д»)
и блока флагов мэша (пункт «Г») ведётся с материалом, выбранным в этом списке.

Г) Перечень/редактор флагов выбранного мэша (опишу лишь нужные).

Г.1) Флаг «TWO SIDED» — Накладывать текстуру со внутренней стороны мэша.
Г.2) Флаг «MATERIAL» — Использовать файл материала (типа MTL), а не текстуру.
(Под текстурой может также пониматься файл EBM или TEX.
А сами MTL т.ж. могут ссылаться на т.ж. EBM или TEX.)

Д) Текстовые поля названия файлов (материалов).
Е) Кнопки открытия файлов (материалов) в блокноте для их редактирования.
Ё) Тип индексов.
«INDX» используется на PLY-файлах не карт; «IND4» используется на PLY-файлах карт.

Ж) Индикатор «MROR».
Используется глобальное отзеркаливание мэша.

З) Индикатор «SHDW».
Файл содержит информацию о создании теней.
(Устаревший блок из ВТВ-1.)

И) Индикатор «ADJA».
Файл содержит информацию об Adjacent (примыкании полигонов друг к другу).
(Устаревший блок из ВТВ-1.)

Й) Текстовые поля заявленного и вычисленного размера вертексов.
Для вас важно, что эти циферки должны совпадать.
Иное означает, что расшифровка и чтение файла были выполнены с ошибками.

К) Текстовое поле кол-ва полигонов в файле.
Л) Текстовое поле кол-ва вертексов в файле.
М) Текстовое поле кол-ва скиновых весов в файле.
Н) Текстовое поле кол-ва текстурных развёрток в файле.
О) Кнопка применения текущих параметров и перезаписи файла.
П) Кнопка применения текущих параметров, перезаписи файла и конвертирования его в OBJ-формат.
Р) Кнопка отмены.

Примечания:
1) Для текстового поля «Б» допускается название состоящее из:
латинских букв, цифр от 0 до 9, и символов в кавычках: «_-+*();[] .,=».

2) Если вы не программист, то большинство параметров этого окна вам вообще не нужны.
Не трогайте не оговоренные режимы и параметры, если не знаете принципов их работы.

3) Касаемо конвертирования:
3.1) Почти все специфические параметры теряются при конвертировании в OBJ-формат.
3.2) Цвета и прозрачности вертексов не портируются.
3.3) Скинование не портируется.
3.4) Вторая развёртка не портируется. (Почти нигде и не встречается.)
3.5) Специфические флаги вертексов и мэшей не портируется.
3.6) Все названия материалов заменяются на Material_[имя PLY-файла]_[№] во избежание возможных повторов.
После обратного экспорта в игру используемые файлы материалов нужно
заменить на оригинальные (если они были MTL-типа).
При этом нельзя заменять оригинальные файлы материалов ново-экспортированными,
т.к. OBJ-конвертер теряет часть данных исходного материала.

3.7) Вертексы, выходящие за рамки «Bound Box», обрезаются до его размера * 2.
(*2 — это стандартное масштабирование при экспорте.)
(Вообще, это функция для защиты от сбойных вертексов.
Но корректность данных из «Bound Box» — это тоже большой вопрос...)

3.8) Во время конвертирования в OBJ может появиться вопрос об ограничении вертексов
рамками «Bound Box». Встречается множество PLY как с некорректными вертексами,
так и с некорректными «Bound Box». Сами выбирайте, какой вариант вас устраивает.

3.9) Флажок Flip ZY-axis в окне импорта 3D Max`а нужно отключать.

3.10) Спекулярная текстура интерпретируется 3D Max`ом как "Specular color",
а не "Specular level". Требуется вручную это исправлять в редакторе материалов.

3.11) Флажок "TWO SIDED" в экспортированном файле тоже теряется.
Из-за этого текстуры могут выглядеть вывернутыми наизнанку.
(Включайте флажок самостоятельно если он был включен в PLY.)

Окна программы — Окно редактора волюмов (компактный вид).

А) Текстовое поле для переименования волюма.
Б) Вкладки типов волюмов.

В) Список костей, к которым можно привязать волюм.
Г) Матрица волюма.
Д) Кнопка копирования матрицы в общую память программы.
Е) Кнопка вставки матрицы из общей памяти программы.
Ё) Кнопка округления.
Округляет числа из матрицы к ближайшим целым.
(Не учитывает матричный характер параметра: ротация и скалярка сбрасываются.)

Ж) Текстовое поле для прописывания кости привязки.
Можно начать набирать название — программа сама будет искать и выбирать
ближайшую подходящую кость по названию.
(Хотя сразу в списке выбирать удобнее.)

З) Кнопка включения/выключения расширенного режима редактирования.
(Об этом будет рассказано позже.)

И) Текстовое поле для изменения пути файла мэша.
Й) Кнопка вызова окна для выбора файла мэша.
К) Текстовые поля длины волюма.
Л) Текстовое поле ширины волюма.
М) Текстовое поле высоты волюма.
Н) Текстовое поле диаметра волюма.
О) Блок переключателей осей определения размера.
П) Кнопка автоматического определения размеров волюма по размеру мэша кости.

Окна программы — Окно редактора волюмов (расширенный вид).

Р) Блок толщин волюма.
(Активируется при включенной галочке.)

С) Блок способностей волюма.
(Активируется при включенной галочке.)
Переключатели способностей трёхпозиционные.
Полностью активна птичка интерпретируется как 1 (вкл).
Серая полупрозрачная птичка интерпретируется «по умолчанию».
(Параметр не меняется.)
Полностью отключенная птичка интерпретируется как 0 (выкл).

Т) Переключатель предварительной очистки способностей,
назначенных волюму самим движком игры или иными предварительными настройками.
(Доступен только при активном блоке способностей волюма — пункт «С».)

У) Текстовое поле коэффициента «CastSteel».
(Активируется при включенной галочке.)

Ф) Текстовое поле коэффициента «Density».
(Активируется при включенной галочке.)

Х) Текстовое поле тэгов волюма.
Ц) Переключатель предварительной очистки тэгов.
Ч) Текстовое поле компонента.
Ш) Переключатель материала волюма.
Щ) Переключатель параметра «Quality».
Ъ) Переключатель параметра «Disabled».
Ы) Переключатель параметра «Hollow».
(Доступен только при активном блоке толщин волюма — пункт «Р».)

Ь) Переключатель параметра «Depend_On_Wind».
Э) Переключатель параметра «HighHardness».
Ю) Кнопка отмены.
Я) Кнопка подтверждения.

Примечания:
1) Для текстовых полей «А», «Х» и «Ч» допускаются названия состоящее из:
латинских букв, цифр от 0 до 9 и символов в кавычках: «_-+*();[] .,=».

2) Активная вкладка типа волюма (Пункт «Б») собой обозначает тип, которым станет волюм
после применения настроек окна.

3) Автоматическое определение размера волюма (Пункты «О» и «П») могло иметь
смысл в «ВТВ-1». Но так как и пивоты мэшей костей часто бывают перепутаны,
и данные «Bound Box» мэшей костей часто являются полнейшей хренью, и требования к
качеству волюмов за последние 20+ лет сильно выросли, и сами функции автоопределения
не доделаны, то пользоваться ими крайне не рекомендуется.

4) Не пользуйтесь расширенным режимом, если не являетесь опытным мододелом.
Эта часть окна нужна для удобной задачи специфических параметров волюма.
Но эти параметры сохраняются программой в MDL-файл, и их нужно вручную вырезать
и вставлять в DEF/INC/EXT (смотря где вы их обычно используете).
Оставлять эти параметры в MDL`е КАТЕГОРИЧЕСКИ НЕЖЕЛАТЕЛЬНО!

5) Если не указываете общую толщину в блоке толщин (Пункт «Р»), то указывайте все остальные толщины.

6) Так как матрица волюма, как и цепь матриц её кости, могут иметь не прямую ориентацию,
то и направления величин из пунктов «К, Л, М» могут визуально отличаться от ожидаемых.

Окна программы — Окно зон (препятствий/областей).

А) Текстовое поле для переименования.
Б) Блок радио-переключателий типа зоны.
В) Блок радио-переключателий типа перемещения.
Г) Текстовые поля оси вращения.
Д) Текстовые поля размерности (X,Y).
Е) Текстовые поля расположения (X,Y).
Ё) Текстовое поле радиуса.
Ж) Список вертексов.
З) Кнопка вставки нового вертекса.
Новый вертекс добавляется после текущего выбранного в списке.

И) Кнопка удаления выбранного вертекса.
Й) Текстовые поля координат выбранного вертекса (X,Y).
К) Текстовое поле тэгов.
Л) Индикатор-переключатель предварительной очистки тэгов.
М) Кнопка подтверждения.
Н) Кнопка отмены.

Примечания:
1) Для текстовых полей «А» и «К» допускаются названия состоящее из:
латинских букв, цифр от 0 до 9, и символов в кавычках: «_-+*();[] .,=».

2) Рекомендую всегда использовать тип перемещения «Rotate».
3) Не допускайте неконвексности полигональной зоны.
4) Координаты вертексов являются несколько условными.
Они перерассчитываются при масштабировании, а также в перерассчитаном виде
записываются как в буфер обмена виндовс (при копировании), так и в файл (при сохранении).

5) При указании радиуса вертексов полигональной зоны программа сейчас рисует несколько зон,
не объединяя их в одну. Это приводит к не совсем верному отображению в самой программе.

Тогда как в игре это выглядит так:

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

Автоматическое тестирование.

При каждом открытии/сохранении модели программа выполняет ряд тестов,
помогающих выявить некоторые ошибки или странности.
Программа бегло тестирует параметры компонентов и их взаимосвязи.

Тестируется:
Совпадение имён у однотипных объектов; Отсутствие имён у объектов;
Расположения и названия анимаций; Критические значения параметров зон;
Потенциально неправильное использование зон; Сбои привязки объектов;
Возможность потенциально неверной проекции зон; Запрещённые имена у объектов;
Наличие потенциально рискованных волюмов; Скиновые привязки;
Странное использование некоторых параметров; Строка параметров костей;

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

Допустим:
1) Технически, с точки зрения игрового движка, отсутствующее имя — это тоже имя.
2) Повторы имён могут просто вести к неверной позиции линковки.
3) Служебное имя «Root» всё равно не переопределяется.
4) Неверно расположенная/именованная анимация просто не работает, как правило не вызывая проблем.
5) Зоны могут нормально проецироваться и на немного кривых и отзеркаленых матрицах.
6) Идентификаторы не обязаны быть на костях, которые есть только на не-X моделях.
7) Отсутствие идентификаторов на мэшевых костях просто ведёт к отсутствию подмены мэша на X/XX версии.
8) Отсутствие или неуместное расположение параметра радиуса в костях колёс ведёт
к неверной видимой скорости их вращения, но не влияет на движение.
(Если на колёсных сборках «wheel*» зачем-то указанны неуместные параметры вроде
кинематики или радиуса, то это может вводить программу в замешательство.)

9) Неэкспортировавшиеся параметры кинематики, анимации, видимости (оставшиеся в
строке параметров) не опасны сами по себе.

10) Наличие параметра видимости у безмэшевой кости просто не имеет смысла.
11) Сбойные волюмы могут иметь и куда меньше полигонов.
Вы сами всегда должны их проверять и без подсказок программы.

Примечания к программе:
1) Некоторые задаваемые вами свойства могут или перезаписываться свойствам, заданными
в другом месте (допустим в папке «properties» — следите за очерёдностью расположения блоков данных).
Или не применяться из-за необходимости иной конфигурации свойств.
Или не работать, потому что такова воля Ктулху.

2) Программа требует аккуратного использования и не прощает ошибок.
Апеллировать вы можете только к своим собственным рукам.

Немного базовой информации о том, с чем работает программа...

Модель. Базовая информация. (ЭТО БАЗА1! ЭТО ЗНАТЬ НАДО!1!!один).

Модель — это общее название для цельного графического ресурса, состоящего из множества файлов,
представляющего интерактивный визуальный объект, с которым коммуницирует игрок.

Модель техники может состоять из файлов:
*.DEF — Текстовый файл дефиниции (Definition);
*.INC — Текстовый файл включений (Include);
*.MDL — Текстовый файл модели (Model);
*.PLY — Бинарный файл видимой геометрии модели (Polygon);
*.MTL — Текстовый файл материала (Material);
*.VOL — Бинарный файл геометрии коллизии (Volume);
*.ANM — Бинарный файл анимации (Animation);
*.EXT —Текстовый файл расширения (Extensions);
*.DDS — Бинарный файл со сжатой текстурой и MiP-Map`ами;
*.TEX — Текстовый файл материала (Устаревший тип);
*.EBM — Текстовый файл материала (Устаревший тип);
*.TGA — Бинарный файл с (как правило) сжатой текстурой;
*.PNG — Бинарный файл с картинкой;
*.JPG — Бинарный файл с картинкой;
*.JPEG — Бинарный файл с картинкой;
*.BMP — Бинарный файл с картинкой;

Небольшое лирическое отступление.
Большая часть текстовых файлов представлена в SDL-формате.
Система SDL представляет из себя относительно свободно компонуемую, делимую,
оптимизируемую, (до) и (пере)заполняемую, блочную иерархическую текстовую структуру
некоторых данных, указываемых в многоугольных скобках и двойных кавычках.
Файлы в этой системе имеют возможность использовать макросы и подгружать
данные из других SDL-файлов по ходу текста.

Макрос в самом простом случае (без аргументов) — это просто шаблонный кусок
текста, встраиваемый по месту вызова во время парсинга:

(define "Макрос"; — Это объявление простого макроса.
;*полезное действие* — Тут полезный встраиваемый текст.
)
("Макрос"); — Это вызов простого макроса.
Вызов не объявленных или недоступных макросов приводит к вылетам.

Символ точки с запятой « ; » комментирует всё, что находится после него до конца строки,
исключая текст до конца строки из парсинга.

Два символа решётки « ## » после открывающейся многоугольной скобки отключают блок,
но не исключают его из парсинга.

{##extender "smokescreen" ; — Этот блок отключен.
{cooldown 5}
{itemTags "grenade nbk39"}
}

Вообще, SDL-парсер серии игр «В тылу врага» — это вещь прям-таки былинная:
будучи сделанным из глюков и багов, он может спокойно переваривать очевидно бредовые
данные, не выдавая ошибок в одних местах, но крашить игру за небольшие ошибки в других местах.

Вот пример вполне работоспособного кода:

Результат — полностью рабочая модель.

Возвращаясь к внутриигровому парсеру:
Где-то он будет правильно работать, только если все ключевые слова написаны правильно;
Где-то — если хотя бы начальная часть слова написана правильно;
Где-то он будет игнорировать даже очевидно правильно написанные ключевые слова;
Где-то он будет правильно работать только с первым правильным ключевым словом,
а второе игнорировать, даже если оно правильное;
Где-то он будет правильно и одинаково понимать абсолютно по-разному записанные данные, а где-то — нет;
Где-то он будет добавлять новые значения к старым, а где-то — начисто их перезаписывать.

По своей сути парсер состоит из:
— первичной глобальной системы парсинга, для которой не важны данные, а важен только их синтаксис
(не без оговорок);
— и огромного множества мелких парсеров отдельных блоков (микросервисов), каждый из
которых работает в меру того настроения, с которым его в тот момент делал программист.
Поэтому никогда не знаешь, где и какой встретится баг.

Столь своеобразная обработка данных в купе с отсутствием вменяемых справочных
материалов по ним требует от мододела хорошей выучки её устройства.
А в савакупности с отсутствием вменяемых инструментов отладки данных
это нередко вводит в замешательство даже самих разработчиков игр серии.
(Чего только стоит Штурм-2, забагованный во все поля.)

Исторически так сложилось, что наиболее эффективным методом борьбы с потенцеальными
багами является использование унифицированых «микросервисных» макросов и общее повышение
дискретности файловых данных.
Но наряду с повышением удобства и отказоустойчивости это приводит к тому,
что и разработчики, и мододелы заучивают небольшое кол-во определённых
паттернов настройки и не вспоминают или вовсе не знают про многие возможности, которые есть в движке игры.
А ведь в движке игры закопано много чьих-то надежд, чьих-то талантов,
малоизвестных и недокументированных возможностей.

Даже самая актуальная документация по движку игры (ветки развития BW):
https://docs.bestway.com.ua/gem-rts-v1-ru
- местами содержит чушь и не актуальную (лет так 20) информацию.
Тоже самое касается Gates of Hell.
Его разрабы тоже используют не вполне актуальную документацию.
А нам, мододелам, — и вовсе ловить почти нечего. (Только писать собственную чушь.)
В основном решает личный опыт.

Теперь конкретнее о файлах.

Устройство DEF-файла на примере танка БТ-2 (но с небольшой отсебятиной).

{game_entity; — Тип объекта (по умолчанию: game_entity)

;game_entity — Это для пассивных объектов
;(пассивное взаимодействие с игровым миром, например, здание).
;actor - Это для активных объектов и т.п;
;Следующий заголовочный файл, как правило, перевыбирает тип на нужный.

(include "/properties/tank.ext") — Заголовочный файл.
;Определяет базовые характеристики модели и перечень доступных макросов.

(include "/properties/selection/vehicle.inc" scale(1.2))
;Задаёт декаль под юнитом.

{props "light" "vision_lev03" "muzzle_37mm_47mm" "detect_tank_light"}
;Перечень глобальных тегов/свойств модели.
;Какие-то из них могут быть жёстко запрограммированы в самом движке игры.
;Какие-то относятся к скриптам.
;Какие-то определяются во всяких разных файлах
;в папке resource\set или resource\interface

;Здесь:
;"light" — Обозначает лёгкий танк. Подтягивает соответствующие базовые скрипты
;из: set\interaction_entity\

;"vision_lev03" — Определяет заметность танка.
;Смотри файлы в папке: set\vision\

;"muzzle_37mm_47mm" — Определяет пыльность/шумность/дымность выстрела главного калибра.
;Смотри файл: set\interaction_entity\muzzle.inc

;"detect_tank_light" — Определяет видимость/слышимость танка в тумане войны.
;Смотри файл: set\detect.set

{extension "bt2.mdl"} ;Подтягивает данные из самостоятельного файла «bt2.mdl»
;Загружает скелет модели.

(include "bt2.ext") ;Подтягивает данные из не самостоятельного файла «bt2.ext».
;Тут обычно хранятся свойства брони.

{patherId "bt"} ;Определяет проходимость юнита.
;Смотри файл: set\pather.set

{collider "tank.light"} ;Определяет работу коллизии.
;Смотри файл: set\colliders.set

{targetclass "tank_light"} ;Определяет то, какой целью является юнит.
;Смотри файл: set\target\ammo.set

{targetSelector "tank_light"} ;Определяет то, с какими целями и какими средствами он должен бороться.
;Смотри файл: set\target\select.set

{extender "shield" {on}{no_blast}} ;Настройка навесной экранной брони.
;On — Включает. Off — Выключает.
;No_Blast – Невосприимчивость экранной брони к взрывной волне.

{extender "enumerator" ;Включение функции отображения бортового номера танка.
;{off} ;Эту функцию можно отключить, если надо.
{digit_folder "ru1"} ;Условный «шрифт» цифр.
;Смотри папку: texture\common\vehicle\enumerator
}
;Бортовой номер отображается на костях с именами, начинающимся на «enumerator».

("crew_3_human_2_extended") ;Вызов макроса конфигурации экипажа танка.
;Смотри файл: properties\tank_crew.ext

{boarder ;Перечень анимаций экипажа и пассажиров.
{anm "driver" ;Конфигурация анимации для условного водителя.
{forward ;Посадка
{begin "board_t26_driver"} ;Анимация посадки.
{end "pose_t26_driver"} ;Конечная поза посаженного.
{base "open_driver"} ;Анимация, принудительно воспроизводимая моделькой танка.
}

{reverse ;Высадка
{end "board_t26_driver" -1} ;Анимация высадки.
;Запущенная в обратную сторону на полной скорости.

{base "open_driver" -1} ;Анимация, принудительно воспроизводимая моделькой танка.
;Запущенная в обратную сторону на полной скорости.
}
}
{anm "left"
{forward {begin "board_kv"}} {reverse {end "emit_tank_1_hold"}}
}
{anm "right"
{forward {begin "board_tank_right"}} {reverse {end "emit_tank_1_hold"}}
}
{anm "armor"
{forward {begin "board_MiddleArmor"} {end "pose_seat_armor_1"}}
{reverse {end "emit_tank_1"}}
}
{anm "armor1"
{forward {begin "board_MiddleArmor"} {end "pose_seat_armor_2"}}
{reverse {end "emit_body"}}
}
}

;Вызовы макросов пассажиров.
;Смотри файл: properties\tank_crew.ext
("seat_human" place(seat1) bone(seat01) door(emit4) animation(armor))
("seat_human" place(seat2) bone(seat02) door(emit5) animation(armor1))
("seat_human" place(seat3) bone(seat03) door(emit6) animation(armor))
("seat_human" place(seat4) bone(seat04) door(emit7) animation(armor))
;seat1 — Название посадочного места.
;seat01 — Название скелетной кости для размещения бойца.
;emit4 — Название точки посадки/высадки бойца.
;armor — Название конфигурации анимации из блока «boarder».

{extender "inventory";Инвентарь юнита.
{box
;Снаряды к пушке.
{item "bulletrus_37 aphe" 45} ;92 rounds
{item "bulletrus_37 he" 46}

;Патроны к пулемёту.
{item "ammo mgun_rus dt" 2646} ;43 drums

;Шанцевый инструмент.
{item "satchel_charge_rus" 1}
}
}
{tag "it_a_tag"} ;Сюда можно прописать какой-нибудь тэг.
{mass 11000} ;Вес модели.

{Weaponry ;Вооружение юнита.
("restore_ik_time") ;Восстановление положения оружейных кинематик после
;начала движения вне боя. (Здесь — 2 секунды.)
;Смотри файл: properties\tank.ext
;Отсутствие этой настройки может мешать пользоваться вооружением.

{place "gun" ;Объявление наличия пушки.
{RestoreIKAfterAim} ;Возвращает орудие на место во время движения техники

{weapon "37mm_5k" filling "bulletrus_37 aphe" 1}
;Вооружение, заряженный боеприпас и его количество.
;Смотри файлы: set\stuff\

{gunner "gunner"} ;Посадочное место, отвечающее за стрельбу.
{charger "commander"} ;Посадочное место, отвечающее за перезарядку.
("abm_dymamic" ; Вызов макроса разброса орудия
zeroing(2.0) ;Время сведения кружка точности до максимума.
dispersion(0.20) ;Время увеличения кружка точности.
)
;Смотри файл: properties\abm.inc
}
{place "mgun" ;Объявление наличия пулемёта.
{type "coaxial"} ;Тип вооружения (надпись).
;Смотри файлы: localizations\default\interface\text\desc\desc_weapon_generic.pot
;И: localizations\ru\interface\text\desc\desc_weapon_generic.po

{weapon "dt" filling "ammo mgun_rus dt" 63} ;Вооружение, заряженный боеприпас и его количество.

{foresight "foresight3"} ;Кость, откуда ведётся огонь.
;Кости и объявления вооружений скриптово связанны друг с другом.
;Неправильное их указание ведёт к поломкам эффектов.

{gunner "commander gunner" minWorkers 1}
{charger "charger charger2" minWorkers 1}
;Ответственных посадочных мест может быть несколько.
;MinWorkers — (здесь) количество членов экипажа, минимально
;необходимое для выполнения этой работы.

("abm_mgun"); Вызов макроса разброса пулемёта.
{basic} ;На это вооружение можно переключаться при помощи правой кнопки мыши.
{ai_in_manual} ;Может использоваться ИИ при ручном управлении юнитом.
}
}
{extender "smokescreen" ;Возможность постановки дымовой завесы.
{cooldown 20} ;Время перезарядки (сек.).
{itemTags "grenade nbk39"} ;Расходуемые дымовые гранаты.
}
{Chassis ;Настройка шасси.
("tank_trace" fx("tracks_sm") step(0.3) len(1.15)) ;Вызов макроса следов,
;оставляемых во время движения, и настройки скорости вращения траков.
; fx — Декалька следа.
; step — Плотность следов.
; len — Длина трака (в метрах?).

; step можно оставлять стандартным для техники своего класса.
; (Меньше или равно нулю указывать нельзя).
; len — Подбирается для каждой конкретной модели экспериментально.
; Для вращения траков в обратную сторону можно использовать значения меньше нуля.

("mobility_tank" ;Макрос настройки ходовых характеристик.
;Смотри файл: properties\mobility.inc

speed(52) ;Максимальная скорость при полном разгоне на дороге, км/ч.
reverse(22); Максимальная скорость движения задним ходом по дороге, км/ч.
traverse(30) ;Время, необходимое для полного поворота на 360 градусов на максимальной скорости.
weight(11.0) ;Вес юнита.
power(400) ;Мощность двигателя, л.с.
track(4.5) ;Ходовые качества: (0,10], 10 = идеальные.
;Неповоротливые танки и транспортные средства с узкими и
;не цепляющимися гусеницами имеют более низкие ходовые качества.

fuel(400) ;Объем топлива в литрах.
type(fuel) ;Тип топлива. Дизель или бензин.
range(150) ;Дальность хода в километрах по бездорожью.
)
}
{bone "gun_rot" ;Донастройка кости из скелета.
{limits -8 25} ;Переопределение лимитов углов вращения.
{speed2 11} ;Определение скорости вращения в градусах в сек.
}
{bone "turret" ;Донастройка кости из скелета.
("turret_light" power_traverse(0)) ;// manual
;Вызов макроса настройки скорости вращения.
;Смотри файл: properties\mobility.inc
}
;Если кости нет — игра вылетит.
;Если для кости определяется параметр, неподходящий под заданный
;режим кинематики, настройки не применяться или игра вылетит.

{texmod "camo"} ;Установка текстурного модификатора (камуфляжа), с которым будет спавниться модель.
;(Такой камуфляж разумеется должен существовать.)
}

Устройство INC-файла.
INC-файл — это просто некий кусок текста, вынесенный в этот отдельный файл.
Эти файлы можно условно назвать несамостоятельными, так как они преимущественно
вызываются по директиве include
(include "m3a1_halftrack.inc")
И просто (в полном объёме своего содержимого) становятся неотъемлемой
частью модели, задействуя в том числе те данные, что уже подгружены в файл, откуда происходит вызов.

Устройство MDL-файла на сильно урезанном примере танка БТ-2.
;Exported by: guita ; Кто экспортировал модель.
;Date: 11.03.2022 22:34:29 ; Когда экспортировал модель.
;File: D:\Git\3D_Scenes\GoH_3D_vehicles_rus\vehicles\tank_light\bt2\bt-2_export.max
;Файл, из которого происходил экспорт модели.
{skeleton ;Объявление скелета.
{animation ;Объявление общего блока анимаций.
{sequence "open" {speed 0.1}{resume} {events {2 "hatch_light"}}}
;Объявление анимации «open» (такой файл должен быть в папке с моделью).
;Скорость/Стартовые характеристики и событие анимации,
;именуемое как «hatch_light», вызов которого происходит на втором кадре.
;...
}
{bone "basis" ;Базовая кость.
{parameters "wheelradius=0.4;"} ;Параметры базовой кости. (Размер катков.)
{orientation ;Ориентация в пространстве базовой кости. (Стандартная.)
1 0 0
0 -1 0
0 0 1
}
{bone "body" ;Кость корпуса.
{parameters "id=body;"} ;Идентификатор принадлежности мэша корпуса к компоненту корпуса.
{animation ;Анимация кости.
{sequence "repair" {file "body_r.anm"}{speed 0.6}} ;Анимация, вызываемая при починке корпуса.
}
{Position -0.4826 0 19.8218} ;Позиция в пространстве X/Y/Z относительно кости «basis».
{VolumeView "body.ply"} ;Вызов загрузки мэша корпуса.
{bone revolute "turret" ; Кость башни.
;...
{Position 13.77 0 9.5344} ;Позиция в пространстве X/Y/Z относительно кости «body».
;...
{VolumeView "turret.ply"} ;Вызов загрузки мэша башни.
;...
}
}
{bone "emit2" ;Кость места посадки/высадки кого-то из экипажа.
{matrix34 ; Ориентация и позиция в пространстве X/Y/Z относительно кости «basis».
0 1 0
-1 0 0
0 0 1
7.7762 -32.2272 0.3349
}
}
}
}
{volume "body1" ;Объявление волюма «body1».
{polyhedron "body1.vol"} ;Вызов загрузки мэша волюма.
{bone "body"} ;Привязка волюма к кости «body».
{Position 6.2724 0 -1.528} ;Позиция в пространстве X/Y/Z относительно кости «body».
}
{volume "fenderl1" ;Объявление волюма «fenderl1»
{box 62.894 0.707809 6.51984} ;Объявление размеров коробочного волюма.
{bone "body"}
{matrix34 ;Ориентация и позиция в пространстве X/Y/Z относительно кости «body».
-1 0 0
0 0 1
0 1 0
-6.8343 18.9242 3.8453
}
}

Устройство MTL-файла.
Если название текстуры в файле материала начинается со знака « $ »,
вроде такого: {diffuse "$/model/calliope"}
то путь такой текстуры автоматически пробрасывается по адресу:
"resource\texture\common", получая такой результат "resource\texture\common\model\calliope"
Можно указывать и прямой ресурсный адрес: {diffuse "/texture/common/model/calliope"}
Можно использовать и такие относительные пути:{diffuse "..\соседняя папка\текстура”}
« ..\ » — переход на папку выше. « соседняя папка\ » — название папки для перехода в неё.

{material bump ;Материал с дефьюз, бамп и спекулярой текстурой.
;Или только дефьюз + спекулярная текстура.

{diffuse "t34"} ;Загрузка дефьюз-текстуры.
{bump "$/model/t340_bp"} ;Загрузка бамп-текстуры.
{specular "$/model/t340_sp"} ;Загрузка спекулярой-текстуры.
{color "229 229 229 25"} ;Цвет спекулярного блика.
{blend test} ;Тип смешивания.
}

{material simple :Материал только с дефьюз-текстурой.
{diffuse "ford_wheels"}
{blend none}
}

{material envmap :Материал с собственной дефьюз-текстурой, дефьюз-текстурой отражения,
;и иногда — с маской альфа-канала для текстуры отражения.
{diffuse "$/model/glass1"}
{mask "$/model/glass1_mask"} ;Текстура маски (неравномерности степени отражения).
{envmap "$/environment/envmap_gold01"} ;Текстура отражения. (Как правило — кубическая.)
{amount 0.5} ;Общая степень отражения (используется редко и без текстурной маски).
;1.0 — только для зеркал. Для стёкол максимум — 0.8.

{blend blend}
}
При использовании маски коэффициент отражения игнорируется.

Bump-материалы используются для имитации рельефной поверхности и
металлического блеска на поверхности материала.
(Требуется поддержка BUMP внутри PLY-файла, на который будет накладываться материал).

Simple-материалы используются для очень простых вещей,
где не требуется хорошая графика.

Envmap-материалы используются для имитации отражения,
заданной кубической картой отражения «envmap».

В игре, материалы, использующие кубические карты окружения, могут использовать
«envmap» по умолчанию, указанную в настройках погоды. Это обычно верно
для воды и стекол в окнах. Для всех остальных поверхностей обычно степень блеска невелика, и приходится подбирать «envmap» вручную, чтобы наиболее качественно подчеркнуть эффект отражения. (Обычно это касается металлов.)
В таком случае нужно указать еще и «карту отражения».

Типы смешивания MTL:
None — Для непрозрачных материалов.
Test — Для материалов, в которых есть прозрачные места
(типа сеток, траков, невидимых частей шасси, вырезов текстур под лючки).
Если значение альфы в пикселе от 0 до 127, то такой пиксель будет полностью прозрачен.
Если значение альфы в пикселе от 128 до 255, то такой пиксель получает прозрачность, равную своему значению.
Blend — Для полностью полупрозрачных материалов (типа окон).
Смешивание выполняется по значению альфы пикселя.

Небольшой список MTL-параметров:
{glow 1.0} ;Коэффициент свечения (яркости) дефьюз текстуры.
{nolight} ;Не реагировать на освещение.
(Материал одинаково светится при любой погоде в любое время суток.)
{emitsheat} ;Излучает тепло для тепловизоров.

{no_outlines} ;Отключает обводку контура модели на этом материале.
{specular_intensity 5} ;Коэффициент интенсивности отражения спекулярной текстуры.
{gloss_scale 2.5} ;Коэффициент интенсивности деления яркости отблеска для стёкол.
{full_specular} ;Используется на материалах стёкол совместно с «gloss_scale».
;Но реальный смысл выявить не удалось...

{tile} ;Раньше рекомендовалось использовать эту команду для текстур с соотношением сторон не 1:1. Допустим 128x64.

Раньше ещё можно было встретить записи подобного рода:
{diffuse "necron_marck"
{Axis 256 256}
{AlphaChannel 1}
}
Но заставить эти команды работать в MTL у меня не получилось.

Текстуры, загружаемые MTL-материалами:
Игра и её MTL-файлы поддерживают следующий перечень текстур и материалов:
".TEX", ".EBM", ".PNG", ".JPG", ".JPEG", ".BMP", ".TGA", ".DDS"
Чем ближе к началу строки — тем выше приоритет.
(Получено в ходе тестирования GoH.)
Старые игры серии не поддерживают PNG.

Можно прямо указывать на формат файла, прописав его название так: {diffuse "t34.dds"}
Но обычно игра сама его ищет по списку форматов {diffuse "t34"}

Вообще файл может называться хоть “t34.85.dds”, и игра всё равно его найдёт
при вызове {diffuse "t34"} точно также, как находит файлы снарядов к пушкам.
Но уже SOEdit такую текстуру не найдёт.

Вместо текстуры MTL можно заставить ссылаться на TEX/EBM-файл.
Но об этих форматах будет сказано позже.
MTL-файл нельзя заставить ссылаться MTL-файл.

Устройство EXT-файла.
EXT-файл — это иногда простой (как inc-файл) кусок текста, вынесенный в отдельный файл,
вызываемый по директиве «include». А иногда — самодостаточный файл, вызываемый
по директиве «extension»

Пример extension-вызова:
{extension "crew.ext"} ;Вызов загрузки файла экипажа в def-файле.

Сам файл «crew.ext»:
;Начало файла.

{boarder
{anm "driver"
{forward {begin "board_HighArmor"} {end "seat_armor"}}
{reverse {end "emit_tank_1"}}
}
}

(define "crew_human" ;Объявление макроса (с именными аргументами).
{placer
{place "%place" {group "%group"} {visor "%visor"}}
}
{boarder
{door "%door"}
{door "%door2"}

{link "%door" "%place" {anm "%animation"} {forward putoff} {reverse puton}}
{link "%door2" "%place" {anm "%animation"} {forward putoff} {reverse puton}}
}
)

("crew_human" ;Вызов макроса с передачей значений через именные аргументы.
place(driver) ;Название посадочного места.
door(emit1) ;Название кости посадки/высадки.
door2(emit2) ;Название кости посадки/высадки.
group(crew) ;Название группы принадлежности посадочного места.
animation(driver) ;Название конфигурации пресета анимации.
visor(driver) ;Название пресета сенсора визора.
)
;Конец файла.

Group — Группа принадлежности посадочного места бойца, залазящего на/в технику.
Это может быть «crew» — экипаж или «passenger» — пассажир.
Но, по моим тестам, этот параметр применим только в некоторых скриптовых командах.
Если у посадочного места есть закреплённый пресет визора,
то игра маркирует его как «crew», иначе — это будет «passenger».

Visor — Пресет сенсора точки обзора.
Пресет может быть или объявлен где-то в файлах папки «properties»,
или можно создать свой сенсорный пресет так:
{sensor
{visor "top" ;Объявление названия пресета сенсора.
{vision "human"} ;Подгрузка пресета визирования.
;(Дальности / угла обзора визора.) Смотри файлы: set\vision

{bone "visor1"} ;Привязка пресета к кости «visor1» в скелете модели.
}
}

Door — Условная «дверь» посадки/высадки.
Здесь их две штуки: кости «emit1» и «emit2».

Link — Соединяет «двери» с посадочными местами.
Anm — Задействует указанную конфигурацию анимации.
Forward — Режим движения вперёд.
Reverse — Режим движения назад.
Putoff — «Запоминает» анимацию цепочки. (Возможно ошибаюсь.)
Puton — «Надевает» старую анимацю. (Возможно ошибаюсь.)

Про DDS-файлы.
DDS-файлы — это файлы текстур, поддерживающие высокую степень сжатия графических
данных, с которыми видеокарта может работать прямо в сжатом виде.
Этот формат настоятельно рекомендуется использовать для текстур моделей.
Формат также поддерживает MiP-уровни.
MIP`ы — цепочка текстур, каждая последующая из которых меньше предыдущей в два раза по X иY.
(Используется для оптимизации и уменьшения текстурной «ряби».)

Для DDS используются следующие форматы кодировки:
BC1/DXT1 (DXGI=71) (no alpha)
Сжатый формат без альфа канала.
Нужно использовать, если текстура вообще не содержит альфы.

BC1/DXT1a (DXGI=71) (1bit alpha)
Сжатый формат с одним битом альфы на пиксель.
Нужно использовать, если текстура содержит бинарную (однобитную) альфу.
Если в игре при удалении камеры от объекта появляются черные пиксели по краям альфы
(неудовлетворительное качество рендера), то стоит перекодировать в DXT3 или сразу DXT5.

BC2/DXT3 (DXGI=74)
Сжатый формат с маленькой градацией альфы.
Можно использовать для текстур с довольно резкими альфа-переходами.
Формат подразумевает всего 16 градаций альфа-канала и в принципе устарел.
Лучше сразу использовать DXT5.

BC3/DXT5 (DXGI=77)
Сжатый формат с полной градацией альфы. (Хоть и через интерполяцию.)
Нужно использовать, если текстура содержит градиенты прозрачности
(очень плавную альфу.)

BC4U/ATI1 (DXGI=80)
Сжатый монохромный формат без альфы.
В это разрабы MOW-II рекомендуют кодировать текстуры типов: roughness, ao, metallic.

BC5U/ATI2 (DXGI=83)
Сжатый двухцветный формат без альфы.
В это, разрабы MOW-II рекомендуют кодировать текстуры бампа.
Разрабы Gates of Hell иногда используют этот формат, но что примечательно,
много файлов откатили на DXT5.

BC7/DX10 (DXGI=98)
Сжатый формат с полной градацией альфы.
В это, разрабы MOW-II рекомендуют кодировать дефьюз текстуры.

DXGI_FORMAT_B8G8R8A8_UNORM (DXGI=87)
(Он же D3DFMT_A8R8G8B8 (D3DFORMAT=21).)
(Зависит от того, по какой системе детерминации выполняется классификация.)
Это не сжатый формат DDS. Используйте только в самом крайнем случае.
Допустим, на текстуре с хорошо просматриваемым градиентом.
(Таких почти не существует.)

По всем кодировкам я вам так скажу:
BC2/DXT3 — устарел. Не очень качественен. Не используйте его.

BC4U/ATI1/BC5U/ATI2/BC7 — даже не притрагивайтесь. Вам оно не надо.
Софта, который может корректно работать с этими форматами, мало.

Для текстур с альфа-каналом нужно использовать DXT5.
А для текстур без альфы DXT1.
Всё достаточно просто.

Устройство TEX- и EBM-файлов.
TEX- и EBM-файлы — это устаревшие, но ещё не бесполезные файлы материалов,
бывшие когда-то бинарными графическими файлами.

Их основными возможностями являются:
1) Редирекция расположения текстур.
(Эту же возможность можно использовать для создания фейковых текс-модов,
когда текс-мод является каким-нибудь EBM-файлом, ссылающимся на уже где-то применяемую текстуру.)
2) Анимирование текстур.
3) Визуализация эффектов.
(Об этом есть целый отдельный блок статей «FX editor (Встроенный редактор эффектов)».)
4) Управление настройками текстур интерфейса.
(Даже в новых играх серии кое-где TEX и EBM для этого ещё используются.)

Теперь более подробно.
0 — выключение; 1 — включение.

Пример типичного файла для текстуры модели:
{Bitmap
{Filtering 1}
{Mipmap 0}
{Blend none}
{AlphaChannel 0}
{Frame "fragments.dds"}
}

Пример типичного файла для анимированной текстуры модели или эффекта:
{bitmap
{Axis 15 15}
{Filtering 1}
{AlphaChannel 1}
{Blend None}
{TextureAnimation 1}
{Animation Play Loop}
{Frame "smokereal.tga/01.tga" 15}
{Frame "smokereal.tga/03.tga" 15}
{Frame "smokereal.tga/05.tga" 15}
}

Пример типичного файла для эффекта:
{bitmap
{Axis 256 256}
{Filtering 1}
{AlphaChannel 1}
{Blend Alpha }
{Frame "$/service/supply_zone_air.dds"}
}
Пример типичного редиректящего файла:
{reference "jagdpanther_armor_x"}

Синтаксис TEX и EBM:
Пути можно указывать почти также, как в MTL-файлах.
Это касается Frame и Reference.

Текстура в папке с материалом:
{Frame "carbine_sn.tga"}

Текстура в папке «censor_anim», которая находится в одной папке с материалом:
{Frame "censor_anim/cenz00.tga"}

Текстура со сложным относительным путём
(выход на три каталога назад и переход оттуда по указанному адресу):
{Frame "../../../inventory/mine_antitank/mine128.dds"}

Текстура в общей папке текстур
(переход в папку « /texture/common » с дальнейшим переходом по указанному адресу):
{Frame "$/service/supply_zone_air.dds"}

Текстура по абсолютному ресурсному пути:
{Frame "/texture/land/town/122b.dds"}

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

Filtering — Фильтрация.
Фильтрация используется для того, чтобы при рендере не возникало эффекта ряби на мелких деталях текстуры.
Но иногда из-за фильтрации в нестыкующихся участках геометрии могут проявляться границы текстурных переходов.
Этот параметр был сделан, чтобы управлять фильтрацией на конкретных текстурах.
(Добиться подтверждения работоспособности этого параметра в GoH не удалось.)

Mipmap — Автоматическая генерация MiP`ов при загрузке текстуры.
Про MiP`ы рассказывалось в блоке DDS.
Все современные версии движков GEM-2 (ветки развития DMS),
включая GoH, не поддерживают эту функцию, сообщая примерно следующее:
[00:00:29] Automatic MIP generation not supported. Bitmap: '/entity/dynamite/00112233' (/entity/dynamite/00112233.ebm, 3)

AlphaChannel — Допустимость работы с альфа-каналаом.
(Добиться подтверждения работоспособности этого параметра в GoH не удалось.)
По всей видимости, этот параметр всегда активирован и игнорирует вмешательство.

Axis — Смещение центра оси.
Смещает точку начала всей последовательности фреймов по X/Y на указанное кол-во пикселей.
(Допустимы отрицательные значения.)
(Имеет смысл только на эффектах и в интерфейсе.)
Этот параметр можно указывать и на отдельном фрейме:
{Frame "explosion.dds" {Axis 64 64}}
Делает тоже самое, но индивидуально для фрейма, игнорируя общий Axis.

Флаги «NoCompression» и «Cursor» используется только в интерфейсе.
(Если ещё используется на момент прочтения.)

Blend — Тип текстурного смешивания. (По умолчанию равен None.)

Blend None — Бинарная прозрачность.
Если значение альфы в пикселе от 0 до 127, то такой пиксель будет полностью прозрачен.
Если значение альфы в пикселе от 128 до 255, то такой пиксель будет
полностью не прозрачен.

Blend Alpha — Мягкая прозрачность с отсечкой.
Если значение альфы в пикселе от 0 до 127, то такой пиксель будет полностью прозрачен.
Если значение альфы в пикселе от 128 до 255, то такой пиксель получает прозрачность,
равную значению своей альфы.

Blend Light — Прозрачность по засвету.
Чем темнее общий цвет пикселя — тем он прозрачнее.
Альфа-канал включен всегда (кроме Light.)

Blend Shadow — Затенение по засвету.
Чем светлее общий цвет пикселя, тем он темнее.
Полностью белый и непрозрачный пиксель становится чёрным, почти непрозрачным и отбрасывает тень.
Полностью белый и прозрачный пиксель становится прозрачным и не отбрасывает тень.
Полностью чёрный и непрозрачный пиксель становится почти идеально прозрачным и отбрасывает тень.
Полностью чёрный и прозрачный пиксель становится прозрачным и не отбрасывает тень.
(Может понадобиться активировать флаг материала в мэше.)
(При использовании Shadow инвертируются цвета используемой текстуры.)

Текстурная анимация.
Текстурная анимация выполняется путём резкой (без морфинга) смены указанной
последовательности кадров через индивидуально указанное количество миллисекунд.
Для этого прописывается некоторое количество фреймов:
{Frame "all_left_to_right_00.tga" 100}
{Frame "all_left_to_right_01.tga" 100}
{Frame "all_left_to_right_02.tga" 100}

1000 миллисекунд = 1 секунда.

Указывается режим анимации:
{Animation Play Loop}

Play — Запускает анимацию. (Без этой команды ничего не работает.)
+ Reverse — Анимация идёт в обратную сторону.
+ Loop — Анимация зацикливается.
+ PingPong — Анимация доходит до конечной и возвращается назад
(в обозначенную сторону и сама по себе не зацикливаясь).
AsyncStart — Суть команды осталась неясна.
(Можно лишь предположить, что это для мультиплеера.)

{TextureAnimation 1}
Эта команда принудительно указывает, что анимация выполняется на
текстуре 3D-объекта модели, а не в интерфейсе или эффекте.
Без неё текстуры смешаются и забагаются.
Следует заметить, что анимированные текстуры могут занимать значительный объем
видеопамяти и заметно дольше загружаются.

Редирекция путей текстур.
Директива Reference одновременно заменяет собой директивы Bitmap и Frame.
{reference "k2_hull_diffuse2"}
В этом режиме TEX / EBM — файл не предполагает указание каких-либо иных параметров, кроме адреса.
Как показали тесты, для Reference, расширение указывать не обязательно.

Reference может ссылаться на файл с Reference.
Frame не может ссылаться на файл с Reference.
TEX / EBM — файлы в принципе не могут ссылаться на MTL.

В старых играх серии, Reference не умел работать с относительными путями «$/» и «../».

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

У использования TEX / EBM — файлов для моделей есть серьёзный недостаток:
Если они используется из под мэша, то это не предполагает использования
бампов и спекуляра. Графика у такого мэша будет картофельной.
Если TEX / EBM используются из под MTL, то значительная часть их функций
игнорируются и работают в режиме по умолчанию.
Особенно плохо это из-за параметра Blend, ведь прежде чем
дойти до MTL, эта текстура обработается как Blend None (смотри её описание).
В MTL попадает текстура, уже порезанная по альфе. У меня нет дельных идей,
что бы тут можно было с этим сделать.

TEX / EBM всё ещё можно использовать для эффектов и интерфейса.
Всё ещё можно использовать для анимирования отдельных мэшей.
Всё ещё можно использовать для переадресации текстур без альфа-канала
и текстур с весьма резким альфа-каналом.
(В самом MTL`е {blend test} прописывать все ровно придётся.)

Про TGA-файлы.
TGA-файлы — это файлы текстур, поддерживающие низкую степень сжатия графических данных
(с помощью RLE-алгоритма).
Не поддерживают MiP-уровни, не поддерживают кубические карты
и не поддерживаются аппаратно в «сыром» виде.
Формат пригоден только для элементов интерфейса.

Про PNG / JPG / JPEG / BMP - файлы.
Это просто популярные форматы картинок, которые, в принципе, может загружать игровой движок (GoH).
За использование этих форматов (включая TGA) в качестве текстур моделей
мододела нужно бить палкой по рукам.

Эти форматы не поддерживаются аппаратно. Для их использования видеокартой
игровой движок вынужден распаковывать их данные в несжатую форму.

Пример:
Текстура 2048x2048 сама по себе весит 16 MB в несжатом виде (BMP).
При её конвертировании в TGA она стала весить 10.8MB.
При её конвертировании в PNG она стала весить 6.15MB.
При её конвертировании в JPG/JPEG она стала весить 641KB.
При её конвертировании в DDS она стала весить 5.33MB.

Но так как аппаратно будет понято только сжатие DDS,
то внутри видеокарты формат DDS будет весить 5.33 MB.
А форматы PNG/ JPG/ JPEG/BMP/TGA будут весить 16 MB.
И это при том, что каждая из сотен моделей, использующихся на игровой сцене,
использует от нескольких текстур до нескольких десятков текстур.
Необходимость оптимизации касается каждого мододела!

Размеры и оптимизации текстур.
Поскольку рендер каждого кадра в игре производится аппаратно, нужно использовать
все доступные возможности для ускорения этого процесса.
Видеопамять организована таким образом, что быстрее всего происходит доступ к данным,
расположенным по быстро вычислимым адресам.
Такие адреса получаются операцией сдвига и соответствуют степеням двойки
(2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048...)
Исходя их этого, оптимально расположатся в памяти текстуры с размером стороны,
равным степени двойки. При этом текстура не обязательно должна быть квадратной.
Возможно использование и текстур других размеров, но при этом, если текстура
не объединяется с другими при загрузке в игре, будет нерационально расходоваться
видеопамять за счет дополнения текстуры до размеров степени двойки
(и в этом случае память будет расходоваться бесконтрольно!).
Нужно привести текстуру в любое возможное соответствие с размерами сторон 2n.
В крайнем случае можно немного пожертвовать пропорциями текстуры и учесть это
при наложении на модель (например, 256x280 лучше превратить в 256x256, чем доращивать до 256x512).
Или же оставить по краям небольшие пустые места, если текстура «не дотягивает» до нужных размеров.

Для текстур, сжимаемых в формат DXT#, важно, чтобы размер сторон был кратен 4,
так-как и данные в этих форматах хранятся блоками по 4x4 пикселя, и видеокарта
работает с данными 4x4 пикселя.

Тексмоды.
Игры серии поддерживают наличие у текстур нескольких версий (модов).
(А в GoH это работает ещё и для PLY-файлов.)

Тексмоды и тексмоды на тексмоды указываются после символа « # ».
«bt_7_body.dds» — Основная текстура.
«bt_7_body#camo.dds» — Первая тексмод-текстура камуфляжной версии.
«bt_7_body#camo#1.dds» — Первый тексмод на тексмод для первой камуфляжной текстуры.
«bt_7_body#camo#2.dds» — Второй тексмод на тексмод для первой камуфляжной текстуры.
«bt_7_body#camo2.dds» — Тексмод текстура второй камуфляжной версии.
«bt_7_body#winter.dds» — Тексмод текстура зимней версии.
«bt_7_body#winter2.ebm» — Фейковый тексмод EBM, переадресующий
на какую-нибудь другую текстуру.

Тексмоды на тексмоды желательно не использовать вовсе или использовать со знанием дела.
Перейдя на тексмод верхнего уровня — игра откажется переходить на тексмоды нижних уровней.
Многоуровневые тексмоды можно использовать для создания нескольких
разных наборов тексмодов для разных моделей, использующих часть одинаковых текстур.
«Name#1.ebm»
«Name#1#1.ebm»
«Name#1#2.ebm»
«Name#1#3.ebm»
«Name#2.ebm»
«Name#2#1.ebm»
«Name#2#2.ebm»
«Name#2#3.ebm»

Одна модель может ссылаться на {diffuse "$/model/Name#1"}
Другая может ссылаться на {diffuse "$/model/Name#2"}

Тексмод можно указать прямо в DEF-файле командой.
{texmod "camo"}
(Это можно делать только после подгрузки файла скелета MDL.)

Установленный тексмод можно проверять в скриптах интеракций:
{if tex_mod "bare" "bare1" "broken"
Сам вызов его изменения, вроде бы, можно отслеживать по {on "texmod_changed"

Тексмод можно менять по скрипту интеракций:
{tex_mod "1a"} ;Быстрая смена тексмода.
{tex_mod reset} ;Сброс тексмода.
{tex_morph "burned" 1} ;Плавная смена тексмода за указанное количество секунд.
{tex_morph "_burned0" 11 "_burned1" 11 "_burned3" 10}
(Но видел жалобы на нестабильную работу tex_morph, вызывающую краш игры).

Можно выбирать тексмод всех моделей при загрузке в мультиплеерную карту.
В INFO-файле мультиплеерной карты нужно прописать соответствующую команду:
{game
{maxPlayers 6}
{texMod camo} ; !!!
}

Модель. Конструкция и устройство.

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

Названия компонентов:
1) Engine — Двигатель.
2) Body — Корпус.
3) Turret — Башня.
4) Gun — Орудие (пушка).
5) Wheelright1 — Переднее правое колесо.
6) Wheelright2 — Правое колесо (второй ряд).
7) Wheelright3 — Правое колесо (третий ряд).
8) Wheelleft1 — Переднее левое колесо.
9) Wheelleft2 — Левое колесо (второй ряд).
10) Wheelleft3 — Левое колесо (третий ряд).
(Название волюма не обязано совпадать с названием компонента.)

Компонент может состоять из одной (как правило) или нескольких костей и/или волюмов.
В отдельных (специфических) случаях компонент может не иметь собственной кости.
Кроме того, модель может использовать специализированные зоны. Но обо всём по порядку.
Для вас важно изучить типичное устройство тех типов моделей из оригинальной игры,
которые вы собираетесь делать/переделывать. (Не меньше нескольких моделей одного типа.)

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

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

Скелет модели.

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

Чтобы было понятнее, что такое кость-родитель в иерархии костей, приведу в качестве примера танк.
У танка костью-родителем для кости башни является корпус танка.
Кость башни является костью-потомком корпуса.
В свою очередь, башня танка является костью-родителем люка на башне и т.д.

Скелет также содержит данные об анимации, относящиеся ко всей модели.

Блок общих анимаций модели.

Большинство моделей техники имеет блок общих анимаций, располагающийся в
заголовочной области скелета. Эти анимации могут быть вызваны как из под скриптов
интеракций, так и в скриптах редактора.

Внутренние же анимации костей можно вызывать либо только провоцируя их активацию
самим игровым движком (анимации поломки / ремонта компонентов),
либо вызывая их скриптовой командой Rt_function в редакторе, указывая название кости.

Большинство названий анимаций характерны определённым типам техники и определённым
стандартным возможностям, так как названия этих анимаций зашиты в стандартизированных
скриптах, общих для моделей схожих типов.

Некоторые анимации могут быть уникальны для конкретной модели и управляться
её собственным микро-скриптом интеракций.
{skeleton
{animation
{sequence "start"}
{sequence "stop"}
{sequence "fire" {file "recoil.anm"} {speed 1.2}}
{sequence "open"{resume} {events {2 "hatch_medium"} {83 "hatch_medium"}}}
{sequence "hit" {speed 0.7}}
{sequence "fire_mgun" {smooth 0.5}}
{sequence "drive_tank" {resume} {store}}
{sequence "fan" {autostart}}
{sequence "000_a_turn_180" {movement} {speed 0.5}}
}
; ...

Параметры:
Speed — Коэффициент скорости воспроизведения анимации.
(Относительно её кадровой скорости 30кадров/сек. из файла анимации.)
(По сути — это коэффициент скорости относительно 3D Max.)
(Нельзя указывать отрицательную скорость, иначе анимация работать не будет.)

File — Название файла анимации.
Если по каким-то причинам, название файла анимации не может совпадать с названием
самой анимации, то можно напрямую указать файл.

Resume — Возобновление.
В основном используется, если анимация должна быть возобновлена в случае прерывания её
воспроизведения. (Актуально для анимаций всяких лючков.)

Events — События анимации.
Во время своей работы на указанных кадрах анимация может генерировать события
с заданными названиями (которые могут и повторяться).
Эти события могут отлавливаться в скриптах интеракций как соответствующие названию
эффекты: {on animation_event "hatch_medium"
Однако генерация событий иногда может работать плохо:
https://www.youtube.com/watch?v=UhRRLqXoLgM
https://rutube.ru/video/1c0aaf7067c2851d461792b1e9548da1/

Smooth — Коэффициент сглаживания анимации.
Позволяет смешивать анимации для плавного перехода между ними.
Технического обоснования работы этого параметра у меня нет.
Но известно, что интервал его значений [0...1]. Иные значения бессмысленны.
Параметр управляет скоростью сглаживания. Его работа сильно зависит от параметра
скорости анимации.

Смотри видео:
https://www.youtube.com/watch?v=22M_AXYOjyM
https://rutube.ru/video/60a174848e87cd73a4062bcdbbeb9deb/

Store — Сохранение момента воспроизведения.
С этим параметром в файлы сохранений миссий записывается текущий кадр
анимации. При загрузке сохранения миссии анимация будет воспроизводится
с сохранённой позиции. (Параметр используется только совместно с «Resume».)

AutoStart — Автоматический старт воспроизведения.
Анимация начинает воспроизводиться в бесконечном цикле сразу после загрузки
модели в игре.

Movement — Анимация меняет положение объекта.
Используется на моделях с анимированным Placement.
(Читай документацию в дополнительных материалах.)

В скриптах интеракций анимациями можно управлять соответствующими командами:
{ani_wind "fire" begin} ;Перемотка анимации на первый кадр.
{ani_wind "fire" end} ;Перемотка анимации на последний кадр.
{ani_play "fire"} ;Воспроизведение анимации.
{ani_play "fire" 0.5} ;Воспроизведение анимации с замедлением до половинной скорости.
{ani_play "fire" -1} ;Воспроизведение анимации в обратную сторону.
{ani_play "fire" loop} ;Зацикленное воспроизведение.
{ani_play "fire" +1.0 resume} ;Воспроизведение анимации вперёд в режиме возобновления.
{ani_play "fire" -1.0 resume} ;Воспроизведение анимации назад в режиме возобновления.

;Воспроизведение анимации с генерацией события по завершению воспроизведения:
{ani_play "fire" callback}

;Отлов callback`ного события в виде эффекта.
{on animation_end "fire"

В самом редакторе игры, анимации можно вызывать через окно функций, которое
можно включить по клавише U (или W в старых реакторах).

В дальнейшем это понадобится при тестировании модели.

Кость.

Кость — это принятое в игре обозначение для узла иерархии модели,
которая используется для прикрепления к нему других костей (дочерних),
различных видов (полигональных, спрайтовых и т.п.), служебных объектов (волюмов и т.п.),
а также других сущностей посредством соответствующих инструкций в движке игры.

Существует формальное разделение костей на несколько типов:
1) Физические;
2) Логические;
3) Визуальные.
Но все эти свойства могут сочетаться в одной кости.

В качестве физических костей выступают основные кости (кости компонентов).
Физические кости в основном отображаются на экране и должны иметь возможность
быть повреждены как компоненты.

Логические кости в основном не имеют визуальных представлений.
Но зачастую они используются либо как прокси-кости с некоторым параметрами
позиции и кинематики, либо для отображения определенных в скриптах эффектов,
либо для размещения членов экипажа и точек крепления/захвата и т.д.

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

Кость обладает множеством характеристик:
1) Визуализация.
2) Позиция и ориентация.
3) Инверсная кинематика.
4) Внутренняя анимация.
5) Иные дополнительные параметры.

(Далее приведу в пример лишь некоторые параметры.)

Кость. (Визуализация).

К визуальным параметрам относятся: мэши, суб. мэши, лоды, цвет подкраски,
параметр разрешения визуализации, визуализационные настройки для рендера.

Выглядеть это может так:

;Просто стандартная визуализация:
{bone "name" ;Имя кости.
{VolumeView "mesh_name.ply"} ;Подтягивание файла с мэшем.
}

;Визуализация кости с дополнительным мэшем (суб. мэшем).
{bone "name"
{VolumeView "mesh_name.ply"}
{VolumeView "sub_mesh_name.ply"} ;Дополнительный мэш.
}

;Визуализация кости с ЛОДами.
;(О самих лодах сказано будет немного позже.)
{bone "name"
{LODView
{VolumeView "mesh_name.ply"} ;Основной мэш.
{VolumeView "mesh_name_lod1.ply"} ;Первый лод.
{VolumeView "mesh_name_lod2.ply"} ;Второй лод.
{Off} ;Полное отключение визуализации кости после второго лода.
}
}

;Визуализация кости с ЛОДами и неубираемым суб. мэшем.
{bone "name"
{VolumeView "sub_mesh_name.ply"}
{LODView
{VolumeView "mesh_name.ply"}
{VolumeView "mesh_name_lod1.ply"}
}
}

;Визуализация кости с подкрашиванием.
{bone "name"
{VolumeView "mesh_name.ply"}
{Color 0xfffdc0} ;Цвет подкрашивания кости в шестнадцатеричной кодировке.
}

;Отключение визуализация кости.
{bone "name"
{VolumeView "mesh_name.ply"}
{visibility 0} ;Управление отображением для конкретно этой кости.
;Может применяться для скрытия визуальных компонентов,
;которые не должны быть видны в этой версии модели.
}

(Использование суб. мэшей хоть и допустимо технически, но вместо этого лучше создавать полноценные кости.)

;Различные параметры визуализации.
{bone "name"
{VolumeView "mesh_name.ply"
{NoGetShadows}
{NoCastShadows}
{Ground}
{DecalTarget}
{Layer WaterScissor}
}
}

NoGetShadows — Мэш перестаёт принимать на себя тень.
NoCastShadows — Мэш перестаёт отбрасывать тень.

Ground — Заставляет игровой движок воспринимать мэш как поверхность земли.
(Влияет на рендер. Параметр не актуален для техники.)

DecalTarget — Мэш кости начинает принимать на себя декали.

(Параметр не актуален для техники.)

Layer — выбор слоя (очерёдности) рендера.
Игровой движок рендерит сцену во множество этапов, слой за слоем
(часть из которых специфичны для конкретных игр).
Это сделано как для удобства, так из-за технических особенностей рендера как такового.

Прорисовка слоев происходит в том порядке, в котором они указаны в списке слоев на
панели рендеринга в вашей версии игры.

В фул-версиях редактора вы можете вызвать окно «Render layer list» с помощью клавиши F11.

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

Одна и та же модель может понемногу рендериться в разных слоях.
Материалы с реальным задействованием альфа-каналом рендерятся тяжелее.

SOEdit позволяет выбрать только уровень «WaterScissor», который можно применять
в мэшевых костях «Scissor», очерчивающих собой область для «вырезания» воды
из внутренних объёмов техники с открытым верхом.
(Технически, любой мэшевой кости можно назначить этот уровень рендера, и это
будет работать. Но этот мэш обязательно должен быть очень оптимизирован.)

LOD (level of detail, уровень детализации) — название технологии,
позволяющей переключать версии одной и той же модели с разной детализацией
в зависимости от удаленности от камеры.

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

Название лода должно быть таким же, как и у кости, которую он должен дублировать,
но с припиской _lod№, где № — это номер лода, например, Body_lod1.
Сами лоды должны использовать те же текстуры и материалы, что и основной мэш.
Оптимизация использования некоторых текстур (и, соответственно, шейдеров)
на движке DMS выполняется по правилам из файла лодов.

У всей техники должны быть прописаны правила лодирования ({lodclass "class_name"})
(либо в самом DEF-файле, либо в каком-нибудь файле из папки «properties»).

Описание классов уровней детализации находится в файле: /set/level_of_detail.set

Отключать свойства визуализации для отдельных лодов можно или через файл лодов,
или в самих лодах в скелете (ограниченно).

Рекомендуемые значения для количества полигонов:
Основной мэш — это 100%.
Первый лод — 75-80%.
Второй лод — 50%.
Третий лод — 30-35%.

Кость. (Позиция и ориентация).

Все мэши на костях позиционируются и ориентируются по своему
внутреннему «запечному» пивоту относительно финализирующий матрицы своей кости.

Финализирующая матрица — это комплекс (цепь) матриц костей,
включающий собственную матрицу своей кости.

Пивот (pivot, ось вращения) — точка, считающаяся опорной для объекта.

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

Кости имеют возможность настройки собственной позиции и ориентации относительно кости своего расположения.
(Если у кости нет своей позиции и/иди ориентации, то она полностью наследуется от
финализирующий матрицы родительской кости.)

Направления пивотов для векторов в SOEdit имеют такие цвета:
Красный — ось X;
Зелёный — ось Z;
Синий — ось Y.

Направления осей пивота для плейсхолдеров типа «клин» в SOEdit таковы:

(Знание направления пивота очень пригодится при настройке кинематики.)

;Position — Управляет только позицией.
{bone "name"
{Position 2.8501 -20.1707 9.5953}
}

;Orientation — Управляет только ориентацией.
{bone "name"
{Orientation
0 0 -1
0 1 0
1 0 0
}
}

;Matrix34 — Управляет сразу позицией и ориентацией.
{bone "name"
{Matrix34
0 -1 0
1 0 0
0 0 1
-23.1348 43.1371 0
}
}

Детальнее о матрицах.

Положение каждой кости задается с помощью указания координат (x, y, z) центра этой кости
(пивота) и ориентации ортогональных осей X1, Y1 и Z1 (векторов единичной длины) этой части.

Центр осей X1, Y1 и Z1 расположен в центре (пивоте) кости.
Координаты центра кости-потомка отсчитываются от центра кости-родителя
(родителя в иерархии костей).

Ориентация осей X1, Y1 и Z1 кости-потомка также указывается относительно осей X, Y и Z кости-родителя.

Для описания позиционирования удобнее всего рассматривать и приводить в пример
Matrix34. Поэтому при рассмотрении позиционирования будет рассматривать именно он.

Matrix34 представляет собой матрицу из чисел, расположенных в виде трех колонок и
четырех строк. Данная матрица может выглядеть в простейшем случае следующим образом:
{Matrix34
1 0 0
0 1 0
0 0 1
0 0 0
}

Первая строка матрицы определяет положение оси Х1.
Вторая строка — положение оси Y1.
Третья строка — положение оси Z1.

Оси всех костей расположены друг относительно друга в соответствии с «правилом правой руки».
Если выставить указательный палец правой руки вперед и принять его за ось X,
то большой палец, поднятый вверх, будет соответствовать направлению оси Z,
а средний палец, согнутый к ладони, — направлению оси Y.

Нижняя, четвертая строка матрицы — это координаты центра кости относительно центра
кости-родителя в координатной системе из осей X, Y и Z кости-родителя.

Для описания ориентации кости-потомка по отношению к осям X, Y и Z кости-родителя
используются значения величин проекций трех единичных векторов (векторов с длиной,
равной единице), выходящих из центра кости-потомка вдоль осей X1, Y1 и Z1 в направлениях этих осей.
На рисунке эти единичные векторы обозначены как «i», «j» и «k».

Три цифры в каждой из трех верхних строк Matrix34 «кости» — это величины проекций
векторов единичной длины, выходящих из центра «кости» вдоль соответствующей
оси «кости», на оси X, Y и Z «кости»-родителя. А именно:

1) Первая цифра в первой строке сверху — длина проекции единичного вектора «i» на
ось X, вторая цифра — длина проекции единичного вектора «i» на ось Y, а третья
цифра — длина проекции единичного вектора «i» на ось Z.

2) Первая цифра во второй строке сверху — длина проекции единичного вектора «j» на
ось X, вторая цифра — длина проекции единичного вектора «j» на ось Y, а третья
цифра — длина проекции единичного вектора «j» на ось Z.

3) Первая цифра в третьей строке сверху — длина проекции единичного вектора «k» на
ось X, вторая цифра — длина проекции единичного вектора «k» на ось Y, а третья
цифра — длина проекции единичного вектора «k» на ось Z.

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

В примере Matrix34 выше по тексту и на рисунке выше приведены значения величин этих
проекций в том случае, если оси кости расположены параллельно осям кости-родителя, т. е.
выходят в том же направлении.

Если кость, например, будет повернута на 15 град. по часовой стрелке вокруг воображаемой
оси, проходящей через центр кости и параллельной оси Y кости-родителя и совпадающей с
ней по направлению, а направление оси Y1 кости после поворота будет совпадать
с направлением оси Y кости-родителя, — три верхние строки матрицы повернутой кости
будут выглядеть следующим образом:

{Matrix34
0.9659 0 0.2588
0 1 0
-0.2588 0 0.9659
... ... ...
}

То есть,
{Matrix34
1*cos15° 0 1*sin15°
0 1 0
-1*sin15° 0 1*cos15°
... ... ...
}

Для масштабирования кости в направлении какой-либо оси значения всех трех цифр строки
Matrix34, соответствующей данной оси должны быть уменьшены или увеличены с
соответственным коэффициентом, то есть умножены на величину коэффициента масштабирования.
Если кость увеличивается или уменьшается пропорционально по всем трем осям (по длине,
ширине и высоте), — все цифры во всех трех первых строках матрицы должны быть
увеличены или уменьшены одинаково.

Например, если кость пропорционально увеличивается в два раза, коэффициент
масштабирования должен быть равен 2, а если уменьшается в два раза, то коэффициент
масштабирования должен быть равен 0,5.

В случае поворота кости на 15 град по часовой стрелке относительно оси, проходящей через
центр кости в направлении оси Y и параллельной оси Y кости-родителя, и одновременного
увеличения кости в два раза, Matrix34 повернутой и увеличенной кости будет выглядеть
следующим образом:
{Matrix34
1.9318 0 0.5176
0 2 0
-0.5176 0 1.9318
... ... ...
}

То есть,
{Matrix34
2*1*cos15° 0 2*1*sin15°
0 2*1 0
-2*1*sin15° 0 2*1*cos15°
... ... ...
}
Здесь: 2 — это коэффициент масштабирования.

Кость. (Инверсная кинематика).

Значительная часть костей модели предусматривает подвижность, которая не анимируется
заранее: катки, башни, различные механизмы наведения пушек и пулемётов.

В зависимости от типа их подвижности применяется рад модификаторов:
Revolute — Применяется для кругового вращения вокруг оси Z.
Prizmatic — Применяется для призматического движения параллельно оси Z.
Socket — Применяется для шарового вращения.
При этом оси X и Y подвижны, а ось Z — заблокирована.
(В GoH шаровый тип сломан и движется только по Y.)

;Свободное круговое вращение. (Можно встретить на колёсах или катках.)
{bone revolute "name"
}

;Свободное круговое вращение с ограничением по скорости.
;(Можно встретить на башнях танков.)
{bone revolute "name"
{speed 0.02}
}

;Тоже самое, что и предыдущее, но с другим типом и значением скорости.
{bone revolute "name"
{speed2 20}
}

;Лимитированное вращение с ограничением по скорости.
;(Можно встретить на масках орудий и на пулемётах.)
{bone revolute "name"
{speed 0.02}
{limits -30 30}
}

;Маркировка кости как кинематической, с блокировкой самой кинематики.
;(Используется в двух случаях при блокировке базиса:
; — для того, чтобы САУ при помощи своего шасси разворачивалась в направлении прицела орудия.
; — или для блокировки станины стационарного орудия, чтобы реалистично вращалась
;только его поворотная часть «turret», а для поворота станины требовалось складывать,
разворачивать и раскладывать всё орудие.
;)
{bone revolute "name"
{limits 0 0}
}

;Тоже самое, что и предыдущее.
{bone revolute "name"
{limits}
}

;Шаровое вращение с ограничением по скорости и углам.
{bone socket "name"
{limits 15}
{speed 0.007}
}

;Шаровое вращение с ограничением по скорости и углам
;с отключением передачи кинематического воздействия на родительские кости.
{bone socket "name"
{limits 30}
{speed 0.007}
{terminator} ;Эта команда указывает, что эта кость последняя в цепочке кинематики.
}

Кинематическая цепочка в движке считается от эффектора и вверх по родительским костям,
до тех пор, пока не попадется кость «root» или кость с terminator'ом.
(ОБРАЩАЙТЕ НА ЭТО ВНИМАНИЕ.) /|\ /|\ /|\

;Призматическое движение с ограничением по скорости и дальности.
(Используется в подвесках.)
{bone prizmatic "name"
{limits -0.08 0.08}
{speed 0.15}
}

Скоростные лимиты костей:
Для ограничения максимальной скорости движения кости,
применяется модификатор "Speed" или его вторая версия Speed2".
(При этом в любом случае должен быть выбран модификатор типа движения.)

Расчёт параметров для модификатора "Speed":
Для призматической привязки — 1 скоростная единица = 1/20 = 0,05 метра в секунду.
Для вращательной привязки — 1 скоростная единица = радиан в секунду.
Расчёт параметров для модификатора "Speed2":
Для призматической привязки — 1 скоростная единица = метр в секунду.
Для вращательной привязки — 1 скоростная единица = градус в секунду.

1 радиан — Это 57.29577951308233 градуса.
1 градус — Это 0.0174532925199433 радиана.

Расчёт параметров для модификатора "Speed" неудобен.
Рекомендую использовать "Speed2".
НО ДЛЯ "SPEED2" НЕЛЬЗЯ ЗАДАВАТЬ ЗНАЧЕНИЕ МЕНЬШЕ 0.573!!!
Иначе это приведёт к вылету.

Ограничение движения костей:
Т.к. возможности движения некоторых механизмов требуют ограничения,
то для этой цели применяется модификатор "Limits".
Это актуально для пулемётов и для иных механизмов наведения,
вроде вертикальной наводки орудия.

Лимиты бывают 3 типов: "Limits", "Limits N" и "Limits N N".
Но т.к. "Limits" равен "Limits 0 0", то его рассматривать не буду.

Для лимитирования модификаторов "Revolute" и "Prizmatic" применяется "Limits N N".
Для лимитирования модификатора "Socket" применяется "Limits N".

Примечание:
Для вращательной и сокетной привязки — 1 лимитная единица = 1 градус.
Для призматической привязки — 1 лимитная единица = 1 метр.

Следует отметить, что ограничение (-45˚, 45˚) противоположно ограничению (45˚, 315˚),
а ограничение (45˚, -45˚) считается ошибочным и рассматривается как (-45˚, 45˚).

Важно:
1) Кости, имена которых начинаются с "wheel" — не должны иметь лимитов.
2) Т.к. катками/колёсами игра воспринимает кости, чьё название начинается на "wheel",
то и модификатор "Revolute" устанавливается для этих костей (но не для колёсных сборок
wheelsL и wheelsR и не для декораторов).

Кость. (Внутренняя анимация).

БОльшая часть анимаций модели располагается в общем блоке анимаций всего скелета.
Но анимации поломки/ремонта компонента вводятся в кость-компонент, на которую
непосредственно воздействуют.

Внутренние анимации встречаются двух видов:
1) Break — Анимация поломки компонента.
Как правило, смещает свою кость-компонент в пространстве (чтобы выглядеть поломанной).
Должна располагаться в одно-X`овой версии кости.

2) Repair — Анимация починки компонента.
Приводит кость-компонент в начальное положение после починки.
(Использовать банальный реверс не рекомендуется.)
Должна располагаться в не X`овой версии кости.

(Эти анимации «для вида» могут играться другими костями во время перемещения своей
целевой кости, но в конце своего воспроизведения неприменимо должны возвращать эти
дополнительные кости в исходное положение.)

Файлы для этих анимаций, как правило, именуются именем компонента с
суффиксом «_r» — Repair или «_b» — Break.

;Внутренняя анимация починки компонента корпуса в кости корпуса.
{bone "body"
{animation
{sequence "repair" {file "body_r.anm"}}
}
}

;Внутренняя анимация поломки компонента корпуса в кости корпуса.
{bone "body"
{animation
{sequence "break" {file "body_b.anm"} {speed 0.8}}
}
}

(Эти анимации вызываются движком игры автоматически через волюмы компонента,
ссылающиеся на кость с анимацией. Этой костью и должна быть физическая
кость-компонент из числа основных.)

Пары этих анимаций используются на таких костях и для таких компонентов как:
Body — Корпус;
Turret — Башня;
Engine — Двигатель;
Gun_rot — Маска орудия;
И / Или. Gun — Орудие.

Иногда встречается мэшевая анимация разрыва траков только для X-модели.
Wheelsl — Кость левой колёсной сборки и левого трака;
Wheelsr — Кость правой колёсной сборки и правого трака.
(При ремонте — мэш без анимации просто сразу подменяется на целый.)

Кость. (Дополнительные параметры).

К дополнительным параметрам можно отнести запрет автоматической группировки мэшей и строку параметров.

;Запрет группировки:
{bone "name"
{VolumeView "mesh_name.ply"
{NoGroupMesh}
}
}
На эту тему есть отделения статья:
https://mow-portal.com/mow_modding_and_editor/1189-redaktor-entity-properties-view-no_group_mesh.html
(Но вкратце, этот параметр для техники не актуален.)

Строка параметров.
Ещё одним из способов указания параметров является строка параметров,
в которую, как в мусорное ведро, выгружается всякий хлам, для которого разработчики не
стали делать отдельных блоков данных.
Кроме попутного мусора, неверных и устаревших параметров, эта строка может и должна
содержать некоторые важные флаги и значения.
Все параметры в строке перечисляются через точку с запятой и не должны иметь никаких
иных символов, кроме: английских букв; цифр и нижнего подчёркивания в названиях,
и единственной точки в возможном дробном числе, являющимся значением параметра.
Если параметр предусматривает значение, то оно должно идти через единственный знак
равенства без пробелов.

;Пример указания размерности колёс/катков и максимального угла поворота рулевых колёс.
{bone "basis"
{parameters "SteerMax=38;Wheelradius=0.4;"}
;...
}

;Пример указания идентификатора компонента.
{bone "body"
{parameters "ID=body;"}
{VolumeView "body.ply"}
}

Параметры:
1) CommonMesh; — Для кости применяется анимации вершин (вертексная анимация.)
2) Land; — Этот мэш является патчем ландшафта. То есть может изменять карту высот,
чтобы по нему можно было ходить. Почти не актуален для техники. Требует использования
дополнительных скриптов и настройки DEF-файла. Встречал на подводной лодке и LCVP.
Пример патчера ландшафта из DEF-файла (подводной лодки):
{Extender "land_patch" ;Объявление патчера ландшафта.
{TerrainType "road" "bridge"}
{updateEntities 0}
{Nonormals 1}
}
(Подробно о патчере ландшафта будет рассказано сильно позже.)

3) Ground; — Дополнительный флаг, идущий после «Land».
Указывает, что данный патч относится к слою рендера «Ground».
Он принимает на себя тени, но не отбрасывает их в случае пониженной детализации теней.
(Не актуален для техники.)

4) Align; — Кость является кандидатом на выставление по уровню земли.
Используется совместно с флагом «Land».
Для работы требует в DEF`е {extender "land_patch" со включенным {AlignEnabled 1}.
(Не актуален для техники.)

4) Wheelradius=0.45; — Задаёт значение радиуса по умолчанию для всех колёс и катков.
(Костей, название которых начинается на «Wheel».)
Параметр можно использовать только в стартовой кости «basis» !!!

5) SteerMax=38; — Задаёт максимальный угол поворота рулевых колёс.
(Управляет поворотом костей, название которых начинается на «Steer».)
Параметр можно использовать только в стартовой кости «basis» !!!
Ограничение угла поворота конкретных костей «Steer» выполняется лимитированием кинематики.

6) Radius=0.3; — Задаёт индивидуальный радиус вращения своей кости-колесу.
(Кости, название которой начинается на «Wheel» или «Roller».)
Параметр нельзя использовать в стартовой кости «basis».

7) ID=trackleft; — Идентифицирует кость, как принадлежащую к определенному компоненту.
Именно по этому параметру, кости подменяются на визуально сломанные или целые.
Также, по этому параметру подсвечиваются мэши компонентов, которые пользователь
выбирает курсором при указании конкретного атакуемого компонента.
Таким образом:
— кости корпуса должны иметь параметр ID=body;
— кости башни — ID=turret;
— в случае многобашенности вторичные башни: ID=turret1 и т. д.
Если башня называется "turret1", то и её компонент, тэг и ID — тоже должны
называться "turret1", иначе может возникнуть путаница.
Кость наводки орудия "gun_rot" (часто выполняющая роль маски орудия — "mantlet")
обычно имеет ID=gun;
Кость с мэшем орудия тоже имеет ID=gun;
С ходовой частью всё немного сложнее:
7.1) Кости колёсных сборок wheelsL и wheelsR;
7.2) Катки wheelL... и wheelR...;
7.3) Траки trackL и trackR
— соответственно должны иметь параметры ID=trackleft; и ID=trackright.
Если такие элементы ходовой части, как wheelsL и wheelsR, объединены в одну деталь, то
параметр ID указывается как "body".

Почти всем костям с мэшами нужно указывать идентификатор, но есть исключения:
тем мэшам, которые не наследуются в X-версии моделей, а также мешам-расходникам
(типа бомб и ракет), — идентификаторы использовать не обязательно.
(Но SOEdit не умеет различать кому надо, а кому не надо.)

8) Support; — Этой костью модель будет опираться на грунт (актуально для колёс самолётов).
С параметром support нужно быть аккуратнее. По всей видимости, использовать его нужно
либо на всех колёсах, либо нигде вовсе. Иначе модель может перекосить. Или на любых
склонах она начнёт «нырять» под землю. Сами разрабы из BW путаются с этим параметром.
Указывая в документации необходимость его установки, но сами используют его крайне не
регулярно. Я предполагаю, что игра в основном сама автоматически устанавливает его для
колёс. А при ручной установке настройщиком модели — сбрасывает этот параметр со всех
колёс, рассчитывая на полный контроль со стороны настройщика модели.
(Параметр зависит от локального и глобального параметров радиуса.)

Названия и функциональное назначение некоторых костей.

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

Главная кость «Basis»:
Для техники кость «Basis» представляет собой начальную кость иерархии.
Своеобразную точку отсчёта, на которой располагаются самые нижнеуровневые кости.
Эта кость не имеет собственного визуального представления, однако по её расположению
под моделью может рисоваться спрайт.

(В простых объектах, вроде инвентаря или объектах окружения, начальная кость может иметь и другое название.)

Начальная кость скелета должна иметь нулевые координаты и матрицу
1 0 0
0 -1 0
0 0 1
для корректного позиционирования и движения в игре.

Физические кости:
Физические кости можно разделить на типичные и ситуативные.

К типичным можно отнести:
Кость «Body»:
Кость корпуса.
Имеет визуальное представление. Имеет прилинкованные волюмы.
Имеет встроенную анимацию (как правило).
Есть у всей техники. Линкуется к базису.

Кость «Engine»:
Кость двигателя.
Может иметь или не иметь визуального представления (по ситуации).
Имеет прилинкованные волюмы. Имеет встроенную анимацию (как правило).
Есть у всей моторизированной техники. Линкуется к корпусу.

Кость «Cabin»:
Кость кабины автомобиля.
Имеет визуальное представление. Имеет прилинкованные волюмы.
Имеет встроенную анимацию (как правило).
Есть у грузовых автомобилей. Линкуется к корпусу.

Кость «Turret»:
Кость башни или поворотного механизма лафета орудия для горизонтального наведения.
Имеет визуальное представление. Имеет прилинкованные волюмы.
Имеет встроенную анимацию (как правило).
Есть у техники с башней или с механизмом наведения орудия.
Линкуется к корпусу.

Кость «Gun_Rot»:
Кость для вертикального наведения орудия.
Имеет визуальное представление. Имеет прилинкованные волюмы (как правило).
Имеет встроенную анимацию (как правило). Имеет лимиты кинематики.
Есть у техники с башней или с механизмом наведения орудия.
Линкуется к башне танка иди к тумбе самоходки.
Не редко, для упрощения, эту кость назначают не отдельным компонентом,
а частью компонента башни или орудия. (Через назначение волюмов.)

Кость «Gun»:
Кость орудия (пушки).
Имеет визуальное представление. Имеет прилинкованные волюмы.
Не имеет встроенную анимацию.
(Анимация поломки / починки орудия в GoH отдана кости «gun_rot».)
Есть у техники с орудием.
Линкуется к кости вертикального наведения орудия (как правило).

Кости «Wheel»:
Кости колёс / катков.
Кости WheelR1, WheelR2, WheelR3, … — Кости правых колёс / катков.
Кости WheelL1, WheelL2, WheelL3, … — Кости левых колёс / катков.
(Нумеруются от передних к задним.)
Имеют визуальное представление. Имеют прилинкованные волюмы.
Не имеют встроенной анимации.
Линкуются к костям-амортизаторам «suspension».
В случае с автомобилями и орудиями кости «Wheel» являются отдельными компонентами.
В случае с танковым (гусеничным) шасси — являются частями компонентов
правого и левого трака соответственно.
Лимиты и скорость во wheel-костях не указывается.

Кости «Track»:
Кости танковых гусениц.
Кость «TrackR» — Правая гусеница.
Кость «TrackL» — Левая гусеница.
Имеют визуальное представление. Имеют прилинкованные волюмы.
Не имеют встроенную анимацию (как правило).
Есть у танков и полугусеничных машин.
Линкуются к костям колёсных сборок «WheelsR» и «WheelsL» соответственно.

Кость «BodyBack»:
Кость кузова грузовика.
Имеет визуальное представление. Имеет прилинкованные волюмы.
Имеет встроенную анимацию (как правило).
Есть у грузовых автомобилей. Линкуется к корпусу.

Кость «Fuel»:
Кость топливного бака (одного или нескольких).
Не имеет визуального представления (как правило). Имеет прилинкованные волюмы.
Не имеет встроенную анимацию.
Есть почти у всего самоходного наземного транспорта.
Линкуется к корпусу.

Кость «Transmission»:
Кость трансмиссии.
Не имеет визуального представления (как правило). Имеет прилинкованный волюм.
Не имеет встроенную анимацию.
Есть у бронетехники. Линкуется к корпусу.

Кость «Ammo»:
Кость ящика с боеприпасами (одного или нескольких).
Не имеет визуального представления (как правило). Имеет прилинкованные волюмы.
Не имеет встроенную анимацию.
Есть у бронетехники. Линкуется к корпусу.

Кости «Wing*»:
Кости крыльев самолёта.
Кости WingR1, WingR2, WingR3. — Правые отрезки крыла.
Кости WingL1, WingL2, WingL3. — Левые отрезки крыла.
Имеют визуальное представление. Имеют прилинкованные волюмы.
Не имеют встроенную анимацию. Линкуются к корпусу.

К ситуативным костям можно отнести:
Кости «Shield*»:
Кости всевозможных броне-щитков, навесных экранов, тентов (иногда).
Имеют визуальное представление. Имеют прилинкованные волюмы (как правило).
Не имеет встроенную анимацию.
Есть у некоторого самоходного наземного транспорта.
Линкуются к местам, которые собой прикрывают: корпус, башня, кузов.
Иногда линкуются на рамы со множеством щитков.
Если название кости начинается на «shield» (допустим: «shield_cover», «shieldR1»,
«shieldL1», «shield_lower», и т. д.), и при этом в модели есть волюм с точно таким же
названием, как у этой кости, то при наличии в DEF-файле модели декларации:
{extender "shield"
{on}
}
— эти «shield» кости-щитки можно будет отключать в редакторе (в свойствах юнита).
При этом отключаются и «shield»-волюмы, и кости, вложенные в «shield» кости.

Кости ситуативных компонентов, специфичных для моделей.
К таким костим можно:
Aileron*, rudder*, elevator*, flap*, elevator* — Рулевые поверхности самолёта.
Stabilizer* — Стабилизаторы самолёта.
Canopy — Навес или створка (как правило, стеклянная) над кабиной пилота.
Gear* — Механизация шасси самолёта.
Aux_Turret# — Дополнительные башни.
Gun# — Дополнительные орудия.
Window# — Стёкла для транспорта.
Lamp — Прожектор.
Body_front, body_center, body_rear — Сегменты корабля.
Basket — Корзина с инструментами и личными вещами позади башни танка.
Roller — Опорная кость минного трала.
(В эту кость внутри движка зашит параметр support.
Вы должны ей индивидуально прописывать параметр радиуса.)

Door*, cover*, hatch* — Двери и лючки. Тоже иногда выступают в роли компонентов,
хоть обычно и выполняют лишь декоративную роль.
(Компонентные кости, имеющие визуальное представление (мэш), должны иметь
параметр идентификатора, идентифицирующий их как конкретный компонент.)

Вообще, существует огромное множество неважных компонентов, которые выдумываются
моделистами только для конкретной модели. О них рассказывать не буду.
Вы сами должны изучить типичное устройство интересующего вас вида модели.
Иногда моделисты могут пойти на упрощение и не делать отдельной кости для одного или нескольких компонентов.
Волюмы таких компонентов могут быть привязаны к дополнительным логическим костям
или костям компонентов, в которых нет встроенной анимации.

Есть и такие компоненты, которые состоят из костей с разными названиями,
к которым привязаны их собственные волюмы,
привязанные в конечном итоге к одному компоненту.
Допустим, кости: «body», «standl», «standr» и привязанные к ним соответствующие волюмы,
в GoH`е идентифицируются как компонент «body», после применения стандартного
компонентного макроса ("body" repair(45)).
Смотри файл: properties\cannon.ext и properties\vehicle.ext

Логические кости:
Логические кости можно разделить на кости-эффекторы, кости линковки, кости восприятия,
прокси-кости, служебные кости.

Кости-эффекторы:
Кости «HeadlightL» и «HeadlightR»:
Источники света — фары.
Свечение ориентируется вперёд по оси X.
Линкуются к корпусу.

Кость «FxLight»:
Дополнительный источник свечения.
Использовался в старых играх серии. Располагался между фарами.
Был неявным источником света. Ориентировался вперёд по оси X.
(В GoH иногда используется моделерами «по старой памяти».)
Линкуется к корпусу.

Кости «FxStop#»:
(«FxStop1», «FxStop2».)
Места размещения стоп-сигнальных огней.
Ориентируются вперёд по оси X.
Линкуются к корпусу.

Кость «FxShot»:
Кость, по расположению которой создавалось пылевое облако во время выстрела.
Использовалась в старых играх серии. Располагалось примерно по-центру юнита.
Линковалось к корпусу.

Кости «FxSmoke#»:
(«FxSmoke1», «FxSmoke2», ...)
Источники выхлопа двигателя.
Ориентируются вперёд по оси X.
У разных видов техники может быть разное кол-во этих костей.
У самолётов — 12. (1-6 — Первый двигатель. 7-12 — Второй двигатель.)
У кораблей — 3.
У поездов и танков — 4.
У автомобилей — 2.
У мотоцикла — 1.
Линкуются к корпусу (как правило).

Кости «FxShell»:
Кости выброса стреляных пулемётных гильз.
Нумерация у таких костей может отсутствовать (если источник гильз один).
Если источников несколько, используется нумерация «FxShell#».
Ориентируются вперёд по оси X.
Используются в открытых пулемётах.
Эффекты для юнитов с несколькими FxShell, как правило, скриптуются индивидуально.
Линкуются к пулемётам.

Кость «Fx_Invers»:
Кость выброса стреляных пушечных гильз.
Нумерация у таких костей может отсутствовать. (Если источник гильз один.)
Если источников несколько, то нумерация «Fx_Invers#».
Ориентируются вперёд по оси X.
Используются в открытых пушках и на некоторой бронетехнике.
Эффекты для юнитов с несколькими Fx_Invers скриптуются индивидуально.
Линкуются к орудиям (как правило).

Кости «FxTraceR#» и «FxTraceL#»:
(«FxTraceR1», «FxTraceR2», ...)
Кости выброса грязи и пыли из под траков или колес.
Размещаются под траками танков и под колесами машин.
Ориентируются вперёд по оси X.
На автомобилях линкуются на кости шасси, являющиеся родительскими для «Wheel*».
На танках линкуются к колёсным сборкам «WheelsR» и «WheelsL».
Обычно таких костей на всю модель не больше 4. Но в модели аэросаней ещё есть
кость «FxTraceM1», создающая снежное облако за юнитом во время движения.

Кости «FxFire#»:
Источники открытого огня при горении техники.
Ориентируются вперёд по оси X.
FxFire1 — Огонь от горящего двигателя.
Линкуется к корпусу, реже — к двигателю.
FxFire2 — Не используется. Относится к старым играм серии.
Её роль исполняет FxFire4.
FxFire3 — Огонь из люка в башни / рубки танка.
Размещается немного под люком.
Линкуется к башне — для танка, или к корпусу — для самоходки.
FxFire4 — Огонь из под башни.
Размещается по-центру между башней и корпусом.
Линкуется к корпусу.
FxFire5 — Огонь на открытой площадке.
Размещается по центру открытого места, немного под поверхностью видимой геометрии.
Используется на транспорте с открытым верхом.
Линкуется к корпусу.

Кости «Foresight#»:
Кости стрельбы (кости прицеливания).
Ориентируются вперёд по оси X.
В одноствольных огневых системах именно из этих костей вылетают снаряды и пули.
Они располагаются на концах стволов орудий и пулемётов (за пределами волюмов)
и также служат местами для появления вспышек от выстрелов.
Линкуются к костям своего оружия.
Для многоствольных систем они служат лишь костями прицеливания, а сама
стрельба выполняется из shooter-костей.
В многоствольных системах название орудия, foresight`а, shooter`ов может подбираться
и скриптоваться индивидуально.

Принадлежность:
Foresight — Кость стрельбы для одноствольных миномётов (включая реактивные).
И кость прицеливания для многоствольных миномётов.
Принадлежит к оружию, объявленному как «gun».
Foresight1 — Кость стрельбы для пушек.
Принадлежит к объявлению «gun».
Foresight1a — Кость стрельбы для мелкокалиберной вспомогательной танковой пушки.
Принадлежит к «gun1».
Foresight1b — Кость стрельбы для мелкокалиберной вспомогательной танковой пушки.
Принадлежит к «gun2».
Foresight2 — Иногда может использоваться как кость стрельбы из огнемёта.
Иногда может использоваться как кость прицеливания для реактивного миномёта или
как вторая кость стрельбы для основного калибра.
Привязки к конкретному объявлению оружия нет. Требует индивидуальной скриптовки.
Foresight3 — Иногда используется как кость стрельбы для спаренного пулемёта «mgun».
(Используется крайне редко.)
Foresight4 — Кость стрельбы для мелкокалиберного пулемёта.
Для самолёта — принадлежит к «mgun2». Для бронетехники — к «mgun1».
Иногда принадлежит к «flamer1» (в качестве огнемёта). Требует индивидуальной скриптовки.
Foresight5 — Кость стрельбы для мелкокалиберного пулемёта в бронетехнике.
Принадлежит к «mgun2».
Foresight6 — Кость стрельбы для мелкокалиберного пулемёта.
Для самолёта — принадлежит к «mgun4». Для бронетехники — к «mgun3».
Foresight7 — Кость стрельбы для мелкокалиберного пулемёта бронетехники.
Принадлежит к «mgun4».
Foresight14 — Кость стрельбы для крупнокалиберного пулемёта бронетехники.
Принадлежит к «mgun1».

Кости «Shooter<суффикс>##»:
Кости многоствольных огневых систем.
Ориентируются вперёд по оси X.
Их использование требует указания количества стволов и специфичного имени shooter`а.
(Если используется shooter по-умолчанию «shooter», то его указывать не обязательно.)

Пример для танка «panzer1» — «PzKpfw I Ausf.B». (DEF-файл.)
{Weaponry
{place "mgun" ;Объявление пулемёта.
{Barrels 2} ;Кол-во стволов.
{type "main"}
{weapon "mg13_no_bipod_x2" filling "ammo mgun_ger mg13" 50}
{charger "commander"}
{gunner "commander"}
("abm_mgun")
{basic}
}
}
В данном случае стрельба будет выполняться из костей «shooter00» и «shooter01», так как
используется стандартный shooter. Костью наводки по-умолчанию является «Foresight3».

;Скриптовка выполняется для юнита индивидуально (в данном случае — танка).
Смотри файл: set\interaction_entity\tank\tank-specifics.inc
{"panzer1 tank"
{on spawn
{add_view "flash_gun_big" "flashbarrel00" "shooter00"}
{add_view "flash_gun_big" "flashbarrel01" "shooter01"}
}
{on fire "mgun" overload ;Переопределение эффекта стрельбы для нашего пулемёта.
;...
{if name "00" ;Первый ствол.
{view start "flashbarrel00"}
{delay 0.2
{view pause "flashbarrel00"}
}
else name "01" ;Второй ствол.
{view start "flashbarrel01"}
{delay 0.2
{view pause "flashbarrel01"}
}
}
}
;...

Пример для самолёта «yak1_ser69» — «ЯК-1-69» (DEF-файл):
{Weaponry
{place "mgun2" ;Объявление пулемёта.
{weapon "shkas_il2" filled}
{barrels 2} ;Кол-во стволов.
{foresight "foresight4"} ;Кость наводки.
{shooter "shooter_mg"} ;Нестандартный shooter.
{charger "driver"}
{gunner "driver"}
{ai_in_manual}
{basic}
}
}
В данном случае стрельба будет выполняться из костей «shooter_mg00» и «shooter_mg01»,
так как используется shooter «shooter_mg».
Костью наводки является «Foresight4».

Скриптовка аналогична (с поправкой на названия и требуемый файл скриптов).

Костям shooter кинематика не задаётся. Они могут быть статичны.
Наводка выполняется foresight-костью и её прокси-костью. Вся кинематика — в них.

Кости линковки:

Кости «Mgun#»:
Кости пулемётов.
Иногда они являются лишь визуальными костями-декораторами,
но часто выступают в роли мест крепления ручных пулемётов.
Ориентируются вперёд по оси X.
Ось Z должна смотреть вверх. Ось Y должна смотреть направо от модели по её курсу.
В SOEdit хелпер типа «клин» должен быть ориентирован острой стороной вперёд,
скошенной стороной направо, синей гранью наверх.

Кости пулемётов располагаются на двух кинематических прокси-костях наведения
— по вертикали и по горизонтали.

В роли линковочных такие пулемётные кости часто не имеют Foresight.

Это может приписываться примерно так (DEF-файл):
{extender "inventory"
;Устанавливаем маски для крепления к объявленному оружию.
{weapon "mgun" {mask "mountable"}} ; mountable — тэг из стафа оружия.
{weapon "mgun2" {mask "mountable"}}
{Box
;Вешаем пулемёты из инвентаря к объявлениям.
{item "dt_bipod" filling "ammo mgun_rus dt" 63 {user "mgun"}}
{item "dt_bipod" filling "ammo mgun_rus dt" 63 {user "mgun2"}}
{item "ammo mgun_rus dt" 1008}
;Не забываем боеприпасы.
}
}
{Weaponry
{place "mgun" ;Объявляем первый пулемёт.
{type "hull"}
{LinkBone "mgun"} ;Линкуем пулемёт из объявления к кости.
{LinkAnimation "off"} ;Анимацию не наследуем, т. к. не хуман.
{gunner "gunner"}
{charger "gunner"}
("abm_mgun")
{rotate} ;Т.к. техника из примера является самоходкой,
;то разрешаем поворот всем корпусом по направлению прицела.

{basic}
}
{place "mgun2" ;Объявляем второй пулемёт.
{type "hull"}
{LinkBone "mgun2"}
{LinkAnimation "off"}
{gunner "gunner2"}
{charger "gunner2"}
("abm_mgun")
{rotate}
{basic}
{ai_in_manual}
}
}

При некоторой степени криворукости требуется создание и настройка Foresight.

Кости «Seat##»:
(«Seat01», «Seat02», ...)
Указывают местоположения сидящих в/на технике бойцов-пассажиров.
Ориентируются вперёд по оси X (если аниматорами не задумано иное).
(Если используются чужие анимации, то положения этих костей может потребоваться
корректировать под конкретные анимации).
Линкуются к базису.

Кости «Emit#»:
(«Emit0», «Emit1», ...)
Кости посадки/высадки солдат. Ориентируются вперёд по оси X.
Линкуются к корпусу (как правило).
Указывают место, откуда начнет проигрываться анимация посадки солдат в технику.
Конфигураций сопоставления эмиторов (дверей) с сетерами (отображаемыми и не
отображаемыми посадочными местами) так много, что на их перечисление уйдёт половина документа.

Желаемую конфигурацию ищите сами в файлах пассажирских макросов:
Файл: properties\cannon_crew.ext
Файл: properties\car_crew.ext
Файл: properties\tank_crew.ext

Разберу только танк «t3476_43» — «Т-34 обр. 1943 г.».

В DEF-файле объявлены и сконфигурированы анимации:
«driver», «left», «right», «armor» и «armor1».

В DEF-файле используются следующие макросы:
("crew_4_human_2_extended")
("seat_human" place(seat1) bone(seat01) door(emit3) animation(armor))
("seat_human" place(seat2) bone(seat02) door(emit4) animation(armor1))
("seat_human" place(seat3) bone(seat03) door(emit5) animation(armor))
("seat_human" place(seat4) bone(seat04) door(emit6) animation(armor1))

Макрос: ("crew_4_human_2_extended")
Объявляет три двери («emit0», «emit1», «emit2»);
Объявляет водителя («driver») и разрешает ему через эти двери «ходить».
Объявляет две двери («emit1», «emit2») (пусть уже и повторно);
Объявляет стрелков и командира («gunner», «gunner3», «commander»);
И разрешает им через эти двери «ходить».
Здесь Emit0 — Это люк водителя; Emit1 — Позиция слева; Emit2 — Позиция справа.
Для этого макроса требуются конфиги анимаций «driver», «left», «right».

Макросы: ("seat_human" ...
Объявляют посадочные места «Seat№»;
Привязывают их к костям размещения на броне «Seat0№»;
Объявляют по индивидуальной двери «Emit№» для каждого пассажира;
И разрешают этим пассажирам «ходить» через их индивидуальные двери,
используя конфиги анимаций «armor» и «armor1».

В данном случае это выглядит так:

К видимым членам экипажа применяется примерно та же логика.
Изучайте устройство моделей и их экипажные макросы.

Ещё небольшое лирическое отступление по местам размещения бойцов в целом:
{placer
{place "%place" ;Условное название посадочного места.
{group "crew"}
{linkbone "%place"} ;Условная кость привязки бойца.
{turnoff ;То, что можно отключить для визуально отображаемого размещённого.
{sensor} ;Собственный визор.
;(Для члена экипажа (не пассажира) нужно назначать новый визор.
;В данном случае будет «top».)
{visible} ;Саму визуализацию. Внезапно.
{shadow} ;Тень.
{targetable} ;;Игнорирование его как цели, чтобы по нему не стреляли.
};Примечание: если после параметра поставить 0 ({visible 0}), то можно
;инвертировать работу параметра, то есть здесь — отключить отключение.
;(Это может быть полезно для переопределения значения параметра.)
{visor "top"} ;Новый назначенный пресет сенсора визора.
{openForCrush 0} ;Не может быть убит обломками.
;(Допустим, от разрушающихся зданий.)
{sealable} ;Может быть спрятан в танке. (При нажатии кнопки закрытия люка.
;Одно из специальных действий в блоке кнопок снизу-справа в
;игровом интерфейсе.)
{attach squat_lie} ;Подобная запись означает, что боец не жёстко закреплён
;на своей LinkBone-кости, а динамически, то есть может поворачиваться и
;стрелять по врагу.
}

Перечень attach`ей:

Обoзнaчeниe нa кapтe в редакторе	Тип:	Описание:
	None	Положение не назначено.
	Look left	Положение: стоять за укрытием с возможностью выглядывать справа, и при необходимости, стрелять. При необходимости боец может спрятаться и скрыться.
	Look right	Положение: стоять за укрытием с возможностью выглядывать слева, и при необходимости, стрелять. При необходимости боец может спрятаться и скрыться.
	Look 2 way	Положение: стоять за укрытием с возможностью выглядывать с обеих сторон, и при необходимости, стрелять. При необходимости боец может спрятаться и скрыться.
	Snipe cover	Положение: стрельба стоя с возможностью присесть. В положении сидя боец будет скрыт.
	Squart lie	Положение: стрельба сидя с возможностью пригнуться. В положении пригнувшись боец будет скрыт.
	Hide standart	Положение: стоя за большим укрытием. Стандартное укрытие, защищающее спину бойца.
	Hide squat	Положение: сидя за средним укрытием. Защищает сидящего бойца со спины.
	Open lie	Положение: лёжа за мелким укрытием. Можно вести фронтальный огонь из положения лежа.
	Bush standart	Положение: стоя в кустах. Скрывает визуально, но не защищает от огня.
	Bush squart	Положение: в присядь в кустах. Скрывает визуально, но не защищает от огня.
	Bush lie	Положение: лёжа в кустах. Скрывает визуально, но не защищает от огня.

;Такая запись может встретиться на «Голиафе».
{placer
{crew 0} ;//Техника становится дроном.
{place "driver" remove} ;Удаляет объявленное ранее посадочное место.
}

Конфигураторы анимаций тоже могут иметь свои особенности.
{boarder
{anm "armor1" ;Объявление условного конфига анимации.
{forward
{speed 1.5} ;Множитель скорости перемещения по вектору от точки старта до точки выхода.
{loop "stand_upstairs" +1.5} ;Может использоваться цикличная анимация вместо анимации begin.
{end "pose_seat_armor_1"}
{fix_orientation} ;Фиксит ориентирование бойца,
;чтобы он был не перпендикулярен земле, а был наклонён от точки старта до точки выхода/перехода.
}
;...

Могут встречаться места размещения со сложным путём, через несколько узлов (нод, путевых точек).

(define "crew_human"
{placer {place "%place" {group "%group"}}}
;Объявление условного посадочного места (с условной группой).

{boarder
{door "%door" ;Объявление условной «двери» посадки/высадки.
{queue} ;Подходить к месту посадки не всей толпой, а по мере посадки предыдущих.
;Можно использовать вариацию {queue 0}, чтобы движок не резервировал двери
;(типа: одна на вход, а другая на выход), а использовал одновременно все.

{auto_release_time 1.2} ;Установка максимальной
;задержки очереди (в секундах).
}
{node "node01"};Объявление узла (такая кость должна быть в скелете).
{node "node02"};Объявление узла (такая кость должна быть в скелете).
{link "%place" "node02" {anm "passenger_1"}} ;Привязка условного
;посадочного места «%place» к узлу «node02» с конфигом анимации «passenger_1».

{link "node02" "node01" {anm "[fsm]"}} ;Привязка узла «node02» к
;узлу «node01» с «естественной» анимацией перемещения бойца,
;определяемой системой конечного автомата анимации [fsm].

{link "node01" "%door" {anm "passenger_1"}} ;Привязка узла «node01» к
;«двери» (эмиттеру) с конфигом анимации «passenger_1».
}
)

("crew_human" place(seat1) door(Emit4) animation(passenger_1) group(passengers))

Пример с созданием цепочек движения:
{placer
{place "x"
{NoCollect} ;Это «посадочное место» будет проходиться «транзитом».
;Есть ещё вариация «NoCollectWhenSpawn»: посадочное место будет занято,
;но после перезагрузки или при копировании, бойца просто кикнет с места.
;Смысл «NoCollectWhenSpawn» мне не совсем ясен.
}
}

{boarder
{door "emit1" {queue 0} {chain "up"} {auto_release_time 1.5}}
;Эта дверь объявлена как принадлежащая цепочке «up».

{door "emit2" {queue 0} {chain "down"} {auto_release_time 1.5}}
;Эта дверь объявлена как принадлежащая цепочке «down».

{node "p0"} ;Объявление проходных узлов.
{node "p1"}
{node "p2"}

;Объявление конфигов анимаций.
{anm "up" {forward {speed 1.2} {loop "stand_upstairs"} {fix_orientation}}}
{anm "down" {forward {speed 1.2} {loop "stand_upstairs" -1} {fix_orientation}}}

;Создание маршрутной цепочки и настройка её отрезков через параметр «chain».
{link "emit1" "p0" {anm "[fsm]"} {forward putoff} {chain "up"}}
{link "p0" "p1" {anm "up"} {chain "up"}}
{link "p1" "emit2" {anm "up"} {chain "up"}}
{link "emit2" "x" {forward puton} {chain "up"}}
{link "emit2" "p1" {anm "down"} {forward putoff} {chain "down"}}
{link "p1" "p0" {anm "down"} {chain "down"}}
{link "p0" "emit1" {anm "[fsm]"} {forward puton} {chain "down"}}
{link "emit1" "x" {chain "down"}}
}

Пример с созданием единой цепочки движения:

{placer
{place "1" {attach snipe_cover} {linkbone "attach1"}}
;Это посадочное место будет динамическим (с подвижным бойцом).
}

{Boarder
{door "emit1"}
{node "ladder_bottom"}
{node "ladder_top"}
{node "ladder_bottom1"}
{node "ladder_top1"}
{node "ladder_bottom2"}
{node "ladder_top2"}

{anm "ladder_bind"
{forward {begin "stand_climb_stairs"}}
{reverse {end "stand_climb_stairs" -1}}
}
{anm "ladder"
{forward {speed 1.2} {loop "stand_upstairs"}}
{reverse {speed 1.2} {loop "stand_upstairs" -1}}
}

;Создание маршрутной цепочки без разбивки (с постоянной настройкой).
{link "emit1" "ladder_bottom" {anm "ladder_bind"} {forward putoff} {reverse puton}}
{link "ladder_bottom" "ladder_top1" {anm "ladder"}}
{link "ladder_top1" "ladder_bottom2" {anm "ladder_bind"}{forward putoff} {reverse puton}}
{link "ladder_bottom2" "ladder_top2" {anm "ladder"}}
{link "ladder_top2" "1" {forward puton} {reverse putoff}}
{link "1" "ladder_top2" {forward puton} {reverse putoff}}
{link "ladder_top2" "ladder_bottom2" {forward puton} {reverse putoff}}
{link "ladder_bottom2" "ladder_top1" {forward puton} {reverse putoff}}
{link "ladder_top1" "ladder_bottom" {forward puton} {reverse putoff}}
{link "ladder_bottom" "emit1" {forward puton} {reverse putoff}}
}

;Конец лирического отступления.

Кости «Link#»:
(«Link1», «Link2»...)
Кости сцепных устройств.
Ориентируются по оси X, в противоположную от своей модели сторону.
Линкуются к базису (как правило).
Link1 — Кость, которая устанавливается предмету буксировки.
Link2 — Кость, которая устанавливается буксиру.
(Логика работает и для Ж/Д-техники: может буксировать и быть буксируемой.)

Также отмечу, что для буксирования не Ж/Д-техники в движок игры зашит
ряд глобальных тэгов (свойств), которые нужно прописывать в props`ах конкретных
буксирующих и буксируемых юнитов.
«trailer», «trailer_medium», «trailer_heavy» — для буксируемой техники.
«tractor», «tractor_medium», «tractor_heavy» — для буксирующей техники.
(«trailer_medium» или «trailer_heavy» используются в паре «trailer».)
(«tractor_medium» или «tractor_heavy» используются в паре «tractor».)
Для лёгких транспортёров можно использовать только «tractor».
Для лёгких орудий можно использовать только «trailer».
Для Ж/Д-техники используется «train_part».

Кости «Attach#»:
(«Attach1», «Attach2», ...)
Кости крепления внешних объектов.
Ориентируются по оси X.
Линкуются к корпусу (как правило).
Иногда бывает необходимо закрепить один или несколько дополнительных объектов на корпусе какого-либо юнита.
Это может быть Ж/Д вагон-платформа, на которую нужно закрепить технику или ящики.
Это может быть баржа, на которую нужно закрепить несколько зенитных установок.
Это может быть юнит, из-за скриптовых особенностей требующий размещения на нём
неких невидимых объектов, нужных для скриптов.
Это может быть юнит, на котором можно закрепить какие-нибудь декораторы в игровом редакторе.
Своим местоположением и ориентацией кости «Attach» определяют положение
стартовой кости закрепляемого объекта.

В DEF-файле к этим костям объекты привязываются так:
{Placer
{place "attach1" ;Название места крепления.
{entity "76mm_rus_aphebc"} ;Прикрепляемый объект.
{Linkbone "attach1"} ;Кость, на которую происходит крепление.
{handlebone "76mm_rus_aphebc"} ;Название базовой кости прикрепляемого объекта.
;(Не похоже, что этот параметр вообще работает...)

{obstacle disable} ;Отключение зоны препятствия, создаваемой прикрепляемым объектом.
;Есть ещё вариация «external», использующаяся в подчиняющих структурных объектах.
}
{place "attach2"
{entity "76mm_rus_aphebc"}
{Linkbone "attach2"}
{handlebone "76mm_rus_aphebc"}
{obstacle disable}
}
;...
}

Вариант с просто созданием Placement-мест размещения.
{Placer
{place "attach1"
{Linkbone "attach1"}
{handlebone "basis"}
{obstacle disable}
{attach} ;Объявление возможности крепления.
}
{place "attach2"
{Linkbone "attach2"}
{handlebone "basis"}
{obstacle disable}
{attach}
}
;...
}

Прилинковать объект к этим местам можно в редакторе при помощи
консольной команды «g_link»

Консоль можно открыть на кнопку «Ё» (в другой раскладке — «тильда»).

Для этого нужно выбрать прикрепляемый объект, зажать Shift и выбрать объект, к которому нужно прикрепиться.

После этого ввести и применить команду.

Если placement-мест на объекте размещения несколько, то для попадания прикрепляемого
объекта в нужное место может понадобится несколько вводов команды.
Главное — не посадите одну технику внутрь другой на невидимое место.

Кости восприятия:
Кости «Visor#»:
(«Visor1», «Visor2», ...)
Визоры, «глаза» юнитов.
Ориентируются по оси X.
С позиций этих костей начинаются поля зрения юнитов.
Параметры заметности и обнаружения можно найти в папке: set\vision\
Файл: \set\vision\spotting.inc — Файл глобальной терминологии.
Файл: \set\vision\vision.set — Файл глобальной конфигурации
(определяет последовательность других файлов).
Файл: \set\vision\spotting.inc — Файл с глобальными макросами полей зрения.
Файл: \set\vision\hearing.inc — Файл с глобальными макросами слышимости.
Файл: \set\vision\vision_fields.inc — Файл с определениями визоров (пресетами визоров).
Эти файлы отлично комментированы. Расписывать их не буду. (Смотри доп. материалы.)

Большинство технических юнитов имеют визоры (за исключением повозок).
Также юниты имеют кости «ушей» («hearing_bone»), автоматически создаваемые
в properties-файлах и конфигурируемые в сенсорный пресет «hearing».

Стандартные названия визорных костей, их подшивка к сенсорным пресетам
и соответствующее определение ролей этих костей в основном выполняется в
заголовочных файлах модели.
Однако нередко в конкретных моделях выполняется переопределение костей для
сенсорных пресетов по умолчанию либо создаются новые сенсорные пресеты
под конкретную специфику.

Иногда в качестве визорных костей используются не специализированные кости «Visor»,
а какие-либо иные, в роде «Foresight». Это почти не моветон.

Перечень заголовочных файлов с их стандартными визорными костями
и сенсорными пресетами:

Файл: properties/vehicle.ext
{sensor
{Visor "hearing"
{vision "noise_detection"}
{bone "hearing_bone"}
}
}

Файлы:
properties/stretcher.ext
properties/railway.ext
properties/cannon_mgun.ext
наследуют данные из файла: properties/vehicle.ext

Файл: properties/cannon.ext
иаследуют данные из файла: properties/vehicle.ext
и дополняет их:
{sensor
{visor "main"
{vision "cannon_main"}
{bone "visor"}
}
}

Файл: properties/airborne.ext
наследуют данные из файла: properties/vehicle.ext
и дополняет их:
{sensor
{Visor "main"
(mod "mp" {vision "airborne_main_mp"}) ;Версия для мультиплеера.
(mod not "mp" {vision "airborne_main"}) ;Версия не для мультиплеера.
{bone "visor"}
}
{visor "around"
(mod "mp" {vision "none"})
(mod not "mp" {vision "airborne_around"})
{bone "basis"}
}
}

Файл: properties/bicycle.ext
наследуют данные из файла: properties/vehicle.ext
и дополняет их:
{sensor
{visor "none"
{vision "none"}
}
}

Файл: properties/car.ext
наследуют данные из файла: properties/vehicle.ext
и дополняет их:
{sensor
{visor "main"
{vision "vehicle_main"}
{bone "visor2"}
}
{visor "around"
{vision "human_peripheral"}
{bone "visor1"}
}
{visor "none"
{vision "none"}
}
}

Файл: properties/halftrack.ext
наследуют данные из файла: properties/car.ext

Файл: properties/armoredcar.ext
наследуют данные из файла: properties/vehicle.ext
и дополняет их:
{sensor
{visor "main"
{vision "tank_range_200"}
{bone "foresight1"}
}
{Visor "driver"
{vision "tank_driver"}
{bone "visor2"}
}
{visor "around"
{vision "vehicle_around"}
{bone "visor1"}
}
{visor "human"
{vision "human"}
{bone "visor3"}
}
{visor "none"
{vision "none"}
}
{Visor "hearing"
{vision "noise_detection"}
{bone "hearing_bone"}
}
}

Файл: properties/searchlight.ext
наследуют данные из файла: properties/vehicle.ext
и дополняет их:
{sensor
{visor "main"
{vision "searchlight"}
{bone "foresight3"}
}
}

Файл: properties/moto.ext
наследуют данные из файла: properties/vehicle.ext
и дополняет их:
{sensor
{visor "main"
{vision "vehicle_main"}
{bone "visor2"}
}
{visor "around"
{vision "vehicle_around"}
{bone "visor1"}
}
{visor "none"
{vision "none"}
}
}

Файл: properties/marine.ext
наследуют данные из файла: properties/vehicle.ext
и дополняет их:
{sensor
{visor "main"
{vision "marine_main"}
{bone "visor"}
}
{visor "none"
{vision "none"}
}
}

Файл: properties/tank_unarmed.ext
{sensor
{visor "main"
{vision "tank_range_200"}
{bone "foresight1"}
}
{Visor "driver"
{vision "tank_driver"}
{bone "visor2"}
}
{visor "around"
{vision "tank_around"}
{bone "visor1"}
}
{visor "human"
{vision "human"}
{bone "visor3"}
}
{visor "none"
{vision "none"}
}
{visor "hearing"
{vision "noise_detection"}
{bone "hearing_bone"} ;Слуховая кость
}
}

Файлы:
properties/tank.ext
properties/tank_assaultgun.ext
наследуют данные из файла: properties/tank_unarmed.ext

Файл: properties/searchlight.ext
наследуют данные из файла: tank_unarmed.ext
и частично переопределяет их:
{sensor
{visor "main"
{vision "searchlight"}
{bone "foresight3"}
}
}

Эти стандартные пресеты сенсоров потом используются в файлах
экипажно-пассажирских макросов:
Файл: properties\cannon_crew.ext
Файл: properties\car_crew.ext
Файл: properties\tank_crew.ext

Ещё немного про синтаксис:
{sensor
{visor "blahblahblah" ;Объявление названия пресета сенсора.
{vision "human"} ;Пресет визирования из set\vision\vision_fields.inc
{bone "visor1"} ;Кость, которая должна быть в скелете модели,
;которая использует этот сенсор.
}
;...
}

Типичные визорные кости. Их использование и назначение:
Для машинистов самолётов, пилотов автомобилей и водителей поездов используется
кость «Visor», линкуемая к корпусу «body» транспортного средства.

Для автомобилей car.ext и halftrack.ext используются кости:
«Visor1» — Линкуется к кости кабины «cabin» и предназначена для командира.
«Visor2» — Линкуется к кости кабины «cabin» и предназначена для водителя.

Для орудий cannon.ext используются кость «Visor», которая линкуется
на турель или кость вертикальной наводки.

Для бронемашин armoredcar.ext используются кости:
«Foresight1» — Для стрелка из пушки
(при соответствующей подшивке сенсора к стрелку).
«Visor1» — Линкуется к кости корпуса и предназначена для командира.
«Visor2» — Линкуется к кости корпуса и предназначена для водителя.
«Visor3» — Линкуется к кости башни (как правило).
Может использоваться для открытого (не под бронёй) стрелка из пушки
(при соответствующей подшивке сенсора к стрелку).

Для танков и самоходок tank.ext, tank_assaultgun.ext, tank_unarmed.ext используются кости:
«Foresight1» — В основном для стрелка из пушки.
«Visor1» — Линкуется к кости башни и предназначена, в основном, для командиров и заряжающих.
«Visor2» — Линкуется к кости корпуса и предназначена, в основном, для водителя.

Ещё немного специфики:
1) Некоторая открытая техника может частично или полностью
полагаться на визоры своего экипажа.

2) Могут встречаться места размещения, к которыми подключено сразу несколько
сенсорных пресетов (как в самой модели, так в properties-файлах).

Работает это так:
Предположим, что у нас есть несколько сенсорных пресетов, вместе или раздельно
объявленных «где-то», откуда их может подтянуть модель.

{sensor
{visor "blahblahblah_1"
{vision "tank_range_200"}
{bone "*name1*"}
}
{visor "blahblahblah_2"
{vision "tank_range_200"}
{bone "*name2*"}
}
}

«Где-то» было объявлено посадочное место члена экипажа:
{placer
{place "*crew_name*"
{visor "blahblahblah_1"} ;И ему был задан один сенсорный пресет.
}
}

После этого, «где-то» снова было объявлено посадочное место этого члена экипажа:
{placer
{place "*crew_name*"
{visor "blahblahblah_2"} ;И ему был задан другой сенсорный пресет.
}
}

Это приведёт к тому, что один член экипажа будет использовать сразу ряд сенсоров.
Неплохо, если это сделано намерено.
Но по-незнанию мододелы часто устраивают хаос в сенсорике.

Прокси-кости:
Прокси-кости в моделях выполняют две довольно скучные, но важные задачи:
коррекцию пивота и настройку кинематики.

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

Вы заменили сам файл пушки. Но вот незадача.
У другой модельки пушки оказался совершенно другой «запечённый» пивот:

Вы, конечно, можете просто изменить расположение и ориентацию новой пушки.
Но как только этот танк выстрелит, то есть задействует анимацию, модифицирующую
матрицу пушки, моделька вновь займёт визуально неправильное положение.

В большинстве случаев, конечно, есть возможность открыть файл анимации стрельбы
и удалить из неё кость пушки. Но это приведёт к тому, что пушка вовсе перестанет
двигаться во время выстрела. Что выглядеть будет, весьма, посредственно...

Простым и рабочим выходом из данной ситуации является прокси-кость.
В данном случае эта кость является прокси между анимированной костью «gun»
(из которой нужно выкинуть мэш), и «запечённым» пивотом мэша внутри новой модельки пушки.
Модельку (мэш) новой пушки нужно подшить внутрь прокси-кости.

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

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

Для этого на кости, которая является родительской для кости, которую нужно проксировать,
создаётся пустая кость, которую можно так и подписать: «proxy_*чего-то там*».
После этого проксируемую кость можно просто вырезать ножницами и вставить как
вложенную в прокси-кость, через меню ПКМ в дереве компонентов.

Прокси кости настройки кинематики характерны для систем прицеливания.
Самый простейший случай — это корпусный пулемёт (прилинкованый к кости «body»).

Прокси-кость «mgun_h_rot2» наводит пулемёт по-вертикали.
Прокси-кость «mgun_h_rot1» наводит пулемёт по-горизонтали.
Эти кости имеют вращательную привязку «Revolute» и лимитированы по углам наводки.

Лимиты по углам составляют:
Для кости «mgun_h_rot2» — от 30 до -15.

То есть 30 градусов наверх и 15 градусов вниз.

Для кости «mgun_h_rot1» — от 15 до -15.

То есть 15 градусов налево и 15 градусов направо соответственно.
(В данном случае скорости вращения заданны в DEF-файле через макрос.
Но базовые настройки скорости можно задавать и здесь, в MDL.)

Напоминаю, что вращение всех кинематических костей выполняется по оси Z (Revolute).

Служебные кости:
В движок игры и скрипты зашито множество служебных названий для костей.
Большинство из них являются либо компонентными, либо декоративными.
Либо, по крайней мере их работа очевидна и видна сразу, а сценарий применения одинаков.
Но есть ряд костей, применение которых можно назвать более специфичным,
чем у всех остальных.

Кости «Steer*»:
Это рулевые кости, использующиеся как для поворота (как правило, передних) колёс
автомобилей, так и для поворота декоративного рулевого колеса в кабине водителя.
Эти кости имеют вращательную привязку «Revolute» и, при необходимости, лимиты
углов вращения. Для передних колёс ось Z нужно перевернуть вниз (не инверсией).

Для рулящих задних колёс (вроде «пумы») ось Z должна смотреть вверх.
Для поворота рулевого колеса водителя ось Z должна смотреть в противоположную от водителя сторону.
Рулевые кости колёс линкуются к своим мостам:
Передние — к кости «pivot_front»; Задние — к кости «pivot_back».
Декоративное рулевое колесо линкуется к кабине, или при отсутствии оной, к корпусу.
При использовании Steer-костей в базовой кости модели требуется указать параметр SteerMax=00;
в котором нужно задать ваш максимальный угол поворота рулевых колёс.

Кости «Support#»:
(«Support1», «Support2», ...)
Этими костями модель будет опираться на грунт. Support-кости являются аналогами
костей с параметром «Support;». Правила использования, соответственно, аналогичны.
Support-кости зависят от локального и глобального параметров радиуса.

Кости «Pivot_Front» и «Pivot_Back»:
Кости колёсных осей (передняя и задняя) в трансмиссии колёсной, морской и
воздухоплавающей техники.

По этим костям игровой движок определяет стартовую и конечную точку шасси юнита,
центр тяжести, и, частично, направление движения. Также. По положению
кости «Pivot_front» рассчитывается проекция обстаклов (препятствий) юнитов.

За исключением кораблей, эти кости должны определять собой центры переднего и заднего
моста. В случае с кораблями и амфибиями, эти кости определяют нос и корму.

Эти кости должны располагаться и ориентироваться строго прямо по оси X модели.
Их координаты Y должны быть равны 0.
Координаты Z также не должны быть экстремальными.
То есть должны быть на уровне шасси.

Эти кости есть у самолётов, буксируемых орудий, автомобильного транспорта, БТР`ов и кораблей.

Для самолётов положение этих костей определяет направление движения при разгоне.
Кость «Pivot_back» не должна физически располагаться перед костью «Pivot_front»,
т.к. это приводит к неправильному расчету вектора движения юнита.
(Особенно это заметно на самолётах, которые могут начать взлетать вбок или назад на огромной скорости.)
(Если колёса или support*-кости не имеют в родительских костях «pivot_back» или
«pivot_front», то это может приводить к мгновенной посадке самолёта.)
(Если самолёт после посадки не может остановиться, то вероятно он не может
отпереться на полный набор support*-костей).

Для буксируемых орудий без задней колёсной пары используется только «Pivot_front» без
принудительного вкорячивания «Pivot_back».

За редким исключением эти кости не имеют собственных мэшей.
Линкуются к базису.

Визуальные кости (декор):
Кости «Detail»:
(«Detail1», «Detail2», ...)
Кости, названия которых начинаются на «Detail», — это визуальные детали на транспортных
средствах, случайно выбирающиеся игровым движком для отображения во время спавна
модели. Использование деталей повышает визуальное разнообразие и добавляет моделям индивидуальности.
В качестве деталей может выступать шанцевый инструмент, брёвна, бочки (как на Т-34),
канистры, ящики, цепи, канаты, запчасти и т.д.

Обычно детали выступают в качестве конечных костей, не имеющих костей-потомков.
Но иногда они могут иметь вложенные кости, что позволяет отключать отображение и
кинематику сразу для всей группы вложенных костей при помощи отключения
этой родительской кости-детали.
Волюмы таких костей (если таковые имеются), кости стрельбы и визирования внутри
костей-деталей при этом не отключаются.
К деталям редко создаются волюмы, по которым их можно отстрелить,
но такое имеет место быть, например бочки на Т-34.

Детали обычно линкуются к корпусу или к башне.
Значением для их параметра идентификатора обычно является название компонента,
на который они линкуются.

Набором отображаемых по умолчанию деталей можно управлять из под DEF-файла.
{extender "detail"
{random 0} ;Отключение рандомизации отображения.
;(При этом все детали становятся включёнными.)
{detail1 0} ;Отключение отображения конкретной детали по названию её кости.
{detail2 0}
{detail_left 0}
{detail_right 0}
}

Кости «Cover*», «Hatch*» и «Door*»:
Кости лючков и дверей.
Как правило, не являются компонентами.
Не используют кинематику.
Часто бывают анимированны.
Имеют идентификаторы компонентов, частью которых являются.
Места линковки зависят от конкретного устройства модели.

Кости «Enumerator#»:
(«Enumerator1», «Enumerator2», ...)
Цель этих костей — отображение случайного трехзначного номера на борту машины.

Enumerator`ы представляют из себя кости из трех полигонов, каждый из которых имеет
свой материал (как правило: "number1.mtl", "number2.mtl", "number3.mtl"),
каждому из которых назначена текстура с изображением цифры.
Сами текстуры хранятся здесь:
texture\common\model\enumerator\ (устаревший путь).
texture\common\vehicle\enumerator\
И разделяются на своего рода «шрифты», хранящиеся в одноимённых папках:
«1», «2», «3», «ger», «ger2», «np», «red», «ru1», «ru2»...

Название «шрифта» можно выбрать в DEF-файле, прописав соответствующее расширение.
{extender "enumerator"
{digit_folder "ru1"} ;Название папки «шрифта».
}

Эти кости линкуются к корпусу или башне и не имеют идентификаторов.

Кости «WheelsR» и «WheelsL»:
Кости правой и левой колёсных сборок для танкового шасси.
На эти кости линкуются кости подвески «suspension_*», к которым линкуются катки.
На эти кости линкуются траки и эффекторы.
Сами колёсные сборки линкуются либо к базису, либо к дополнительной прокси-кости.
В зависимости от версии конструкции модели эти кости могут иметь или не иметь мэш.
Мэшем является скинованная, подвижна часть подвески.
Имеют идентификаторы своей части шасси:
ID=trackleft; для WheelsL.
ID=trackright; для WheelsR.

Кости «SuspL» и «SuspR»:
Скинованные, подвижные части подвески.
Используются в моделях, чьи кости «WheelsR» и «WheelsL» не имеют мэша.
Имеют идентификаторы своей части шасси:
ID=trackleft; для SuspL.
ID=trackright; для SuspR.

Вынужденные кости-декораторы:
Такие кости могут создаваться моделлерами, когда возникает необходимость экспортировать
мэш с гигантским количеством вертексов.
Игровой мэш ограничен 65535 вертексами для одного PLY-файла.
Чтобы преодолеть это ограничение, некоторые моделлеры «нарезают» мэши на несколько
отдельных костей, где все, кроме одной являются просто вынужденными декораторами.
Все подобные вынужденные декораторы линкуются на кость, от мэша которого были отрезаны.

Кости авиадвигателя:
Схемы устройства авиадвигателей могут отличаться в зависимости от конкретной
конструкции самолёта, но их базовое устройство таково:
Кости авиадвигателей разделяются на кости для первого «Engine1» и второго «Engine2»
двигателей. Если двигатель один, то его визуальные кости продолжают маркироваться
с припиской «1». В пример будет взят однодвигательный самолёт «ПО-2».

Кость «Propeller1»:
Пропеллер в простое.

Моделька пропеллера, отображающаяся у самолёта находящегося на земле.
Не скрыта по умолчанию. Участвует в первой половине анимации запуска двигателя
и во второй половине анимации остановки двигателя.
Линкуется к компонентной кости «Engine1» первого двигателя.
Имеет идентификатор ID=Engine1;

Кость «Propeller1_Work»:
Пропеллер в работе.

Плоский мэш со смазанной текстурой быстро вращающего пропеллера.
Скрыта по умолчанию. Участвует во второй половине анимации запуска двигателя,
во всей анимации крейсерской работы двигателя и в первой половине анимации остановки двигателя.
Линкуется к компонентной кости «Engine1» первого двигателя.
Имеет идентификатор ID=Engine1;
Используется в связи с тем, что анимация модельки «пропеллера в простое» не может
вращаться достаточно быстро и не может воссоздавать похожий эффект.

Кость «Prop1_Work»:
Сердечник пропеллера при работе.

Используется в качестве «заплатки» вместо скрытой кости пропеллера в простое.
Скрыта по умолчанию. Участвует во второй половине анимации запуска двигателя,
во всей анимации крейсерской работы двигателя и в первой половине анимации остановки двигателя.
Линкуется к кости «Propeller1_Work» первого двигателя.
Имеет идентификатор ID=Engine1;

Анимации пропеллеров как управляют отображением и скрытием пропеллерных
костей, так и выполняют непосредственное вращение этих костей.
Инверсная кинематика тут не используется.

Пара примечаний по костям в целом:
1) При создании модельки следите за тем, чтобы кости линковались к костям, визуальной частью которых они являются.
2) Если модель использует одинаковые мэши (допустим, катки на танках), то будет лучше,
если кости с одинаковыми мэшами будут ссылаться на один и тот же файл, а не на несколько
разных файлов с одинаковым содержимым.
(В 3D Max это делается с помощью клонирования кости-образщика с опцией «Instance».
А в SoEdit можно перевыбрать мэш на используемый в кости-образщике через редактор костей.)

Некоторые скриптовые эффекты и не контекстные версии команд для костей и компонентов:

{bone hide "body"} ;Скрывает ветвь кости, начиная с указанной.
;(Кинематика скрытых костей блокируется, но эффекты продолжают работать.)

{bone show "body"} ;Отображает ветвь кости, начиная с указанной.
;(Кинематика костей вновь начинает работать.)

{bone cut "turret"} ;Удаляет ветвь кости, начиная с указанной.
;Ни о каком восстановлении и о работе эффектов речи уже не идёт.
;(При удалении кости, к которой есть скиновая привязка, игра может вылететь с ошибкой.)

{on ik begin "turret" ;Эффект начала кинематического движения указанной кости.
{on ik end "turret" ;Эффект завершения кинематического движения указанной кости.
;(Не реагируют на анимацию.)

{tear "piece_medium_steel" bone "turret" ;Физический отрыв указанной ветви костей
;с её привязкой к физическому хелперу «piece_medium_steel».
{impulse up 10 no_position} ;Оторванной кости можно придать импульс для веселья.
}
;(При отрыве кости, к которой есть скиновая привязка, — игра может вылететь с ошибкой.)

{components "body" break} ;Повреждает (ломает) указанный компонент.
{components "body" repair} ;Чинит указанный компонент.
{components "body" destroy} ;Уничтожает указанный компонент.

{if work "body" ;Проверяет, является ли указанный компонент целым.
{if not work "body" ;Проверяет, является ли указанный компонент не целым.
{if broken "body" ;Проверяет, является ли указанный компонент сломанным.
{if broken "wheel" 2 ;Проверяет, есть ли у юнита указанное количество каким-либо
;образом (хоть номинально и где-либо) объявленных компонентов, чьё название
;начинается на «wheel», которые являются сломанными.
{if destroyed "turret" ;Проверяет, является ли указанный компонент уничтоженным.

{on break ;Эффект поломки какого-либо компонента.
;...
{on repair ;Эффект починки какого-либо компонента.
;...
{on destroy ;Эффект уничтожения какого-либо компонента.
{if component "body" ;Проверка, на какой компонент воздействовал эффект.

Волюмы. (Коллизия).

Коллизия — это упрощенная физическая модель объекта, определяющая его осязаемость.

Коллизия состоит из набора волюмов (объёмов), определяющих собой области пространства.

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

Наибольшая часть волюмов — это объекты взаимодействия, определяющие физическую
область, занимаемого моделью пространства, и покрывающие её визуальную форму.
Но часть волюмов специфична и предназначена для:
1) «Вырезания» пустот в других волюмах;
2) Определения пересечений с другими волюмами (нужно для скриптов);
3) Поддержания объектов на плаву.
4) Некоторых иных задач, вроде помощи игроку при выборе юнита,
или для максимального упрощения физических расчётов во время тарана.

Большая часть (а иногда и вообще все) волюмы принадлежат компонентам
с целью придания им возможности влиять на окружающий мир
и быть подверженными его влиянию.

Волюмы не обязательно должны точно повторять контуры компонента модели, к которому
прилинкованы. Слишком подробный волюм будет съедать большое количество
процессорного ресурса, но и слишком грубый волюм не будет правильно отражать
геометрические параметры объекта.
Не слишком подробная детализированность одного волюма компенсируется тем,
что один компонент может иметь в своём составе сразу несколько волюмов, которые можно
прилинковать к одной или нескольким костям.
(Компоненты, типичные для модели своего класса, должны иметь волюмы
для возможности ремонта этих компонентов, если они ломаются по скриптам.)

Волюмы компонентов определяют их физические параметры:
Контуры для физического взаимодействия, материалы, толщины и ещё целый ряд иной специфики.

Волюмы не являются костями, поэтому они должны быть прилинкованы к тем костям,
частями компонентов которых они являются и вместе с которыми они должны двигаться.

Волюмы, принадлежащие одним компонентами (компонентные), нельзя линковать к костям,
предназначенным для других компонентов.
Допустим, волюмы «ShieldL№», «ShieldR№» и т. д. будет некорректно линковать к костям «Body» или «Turret».
(Но это правило можно игнорировать для не компонентных волюмов, даже если они
инициализированы как броневые, например волюмы «Armor*».)

Волюм обладает множеством характеристик:
1) Геометрия.
2) Позиция и ориентация.
3) Характеристики бронирования.
4) Возможности взаимодействия.
5) Настройки материалов.
6) Привязка и идентификация.
7) Иные возможности.

Волюм. (Геометрия).

Волюмы можно разделить на мэшевые «Polyhedron» и параметрические «Box / Cylinder / Sphere».
(SOEdit не умеет работать с шаровыми волюмами «Sphere» и заменяет их на «Box».)

У всех волюмов есть стороны бронирования: Перед; Зад; Лево; Право; Верх; Низ.
Им задаются соответствующие толщины брони в миллиметрах условной броневой стали.

В случае с мэшевым волюмом моделист сам определяет его геометрию и задаёт стороны
в соответствующей программе (типа 3D Max).

В случае с параметрическими волюмами их геометрия создаётся игровым движком
автоматически на основе их метрических параметров.
Для волюмов типа «Box» — Это длина, ширина, высота.
Для волюмов типа «Cylinder» — Это диаметр и длина.
Для волюмов типа «Sphere» — Это только диаметр.
Одна единица для диаметра соответствует одному дециметру.
Одна единица для длины, ширины и высоты соответствует половине дециметра.

Стороны для параметрических волюмов генерируются автоматически, но не учитывают
ориентации матриц. А поэтому их стороны могут быть расположены корректно только в
том случае, когда финализирующая матрица волюма полностью прямая.
Не рекомендую задавать толщины сторонам параметрических волюмов, так-как это почти
гарантированно приведёт к путанице. Стоит ограничиваться общей толщиной.
(SOEdit не умеет визуализировать стороны параметрических волюмов.)

Стоит внимательно относиться мэшевым волюмам, следя за их конвексностью (выпуклостью).

Волюм должен быть конвексным.
То есть если взять два любых соседних граничащих треугольника, то угол между ними
по границе не должен быть обращен внутрь волюма или почти отсутствовать.

Дыры и разрывы граней в волюмах также недопустимы.
Волюмы, созданные путём прямого конвертирования из «сырого» визуального мэша,
и волюмы, созданные путём аттача двух и более даже примитивных мэшей, — также недопустимы.
Более наглядно примеры неконвексности будут показаны в главе, посвящённой
контролю и тестированию моделей.

Волюм. (Позиция и ориентация).

В общем и целом настройка позиции и ориентации совпадает с тем, как это
устроено в кости. Читай позицию и ориентацию кости.

Волюм. (Характеристики бронирования).

Thickness (Стороны бронирования волюма):
Существует два вида расчёта брони волюма:
1) Расчёт толщины по трассировке.
2) Расчёт толщины по толщинам сторон.

Расчёт по трассировке физ. объёма является одной из опций пресетов брони Armor → Setting.
При этом игнорируются стороны бронирования и углы наклона волюма.
(В пресетах брони есть много тонких и альтернативных видов настройки брони.
Об этом можно прочитать в дополнительных материалах и иных первоисточниках.)

Для техники используется расчёт по толщинам сторон:
{volume "body"
{thickness hollow 45.0 0.3
{front 100.0 0.0}
{rear 45.0 0.5}
{top 20.0 0.5}
{bottom 15.0 0.5}
{left 45.0 0.3}
{right 45.0 0.3}
}
}

Директива «Hollow» (полый) и вторая колонка цифр активно применялись в первых играх
серии, выходивших на движках GEM1.
Мне не удалось обнаружить хоть какого-либо их влияния ни на одну игру серии.
Не удалось обнаружить и их использования в GoH.
Эти параметры существуют и поддерживаются в режиме легаси-совместимости.

Цифра в первой строке (там где «Thickness») обозначает общую толщину.
(Толщины всех сторон по-умолчанию.)
Это значение можно не указывать, если указаны толщины для всех шести сторон.

Далее опционально можно задать толщины для конкретных сторон.
Front — Перед; Rear — Зад; Left — Лево; Right — Право; Top — Верх; Bottom — Низ.

(Примечание: Чтобы бронебойный снаряд прошёл волюм насквозь, ему нужно пробить
обе бронированные плоскости волюма с учётом угла встречи снаряда с этими плоскостями,
и характеристиками материала волюма.)

CastSteel (Коэффициент прочности волюма).
Коэффициент прочности литой броневой стали относительно катанной гомогенной брони.
Используется совместно с параметром толщины для придания броне реальной
сопротивляемости. (Чтобы не приходилось в параметр
толщины прописывать вручную пересчитанные значения и читать после этого нытьё
игроков о том, что циферки брони не совпадают с «Википедией».)

{volume "turret"
{thickness 53}
{CastSteel 0.8063}
}
;Эффективная толщина снижена до: 42.7339мм бронестали.

HighHardness и Quality (Высокая твердость и условное качество волюма).
Высокая твёрдость по Бринеллю. (Хрупкость стали.) И общее «качество» стали.
— Ещё одни параметры для скрытого ухудшения брони.

Не замечал их совместного применения. Их суть примерно похожа.
Эти параметры меняют характеристики эффективной толщины брони и получаемого урона.

Используются они совместно с параметром толщины.

{volume "body1"
{thickness 100}
{HighHardness}
}

{volume "body1"
{thickness 100}
{Quality "large_flaw"}
}

Неизвестно, какие параметры толщин/прочностей в игре установлены для броневых сталей
низкой и средней твёрдости.

Параметр «HighHardness», предположительно, апеллирует к таблице толщин?/твёрдостей
брони в файле set\damage.set, доводящей твёрдость брони до 300/450 BH.
Могу лишь предположить, что стандартные твёрдости по Бринеллю для броневой стали
в игре должны варьироваться от 250 до 350 BH для гомогенных бронесталей средней
твёрдости, т.к. это наиболее популярный вид бронестали в рамках второй мировой войны.

Параметр «Quality» апеллирует к «плохому» легированию и «высокому» содержанию углерода в броневой стали.
У этого параметра существует четыре значения:
1) «No_Flaw» — Без недостатков. (Тоже самое, что и полное отсутствие параметра.)
2) «Small_Flaw» — Небольшой недостаток качества.
3) «Medium_Flaw» — Средний недостаток качества.
4) «Large_Flaw» — Большой недостаток качества.

Т.к. разработчики GoH не сподобились опубликовать таблицы падений характеристик,
то пришлось создавать их, исходя из очень приблизительных (неточных) результатов
собственного тестирования.

Приведённые ниже таблицы нельзя воспринимать как истину для прогнозирования точных
значений. Но определённые корреляции толщин брони / калибров снарядов / параметров,
как по мне, небезынтересны.
(Версия игры на момент тестирования — V 1.060.0.)

Таблицы для HighHardness.

(В графах «Побитие с HighHardness» и «Побитие без HighHardness» указано минимальное
достаточное бронепробитие, понадобившееся для поражения (пробития с первой попытки)
листа брони с учётом его не идеального угла наклона к снаряду, в том числе из-за кривой
баллистической траектории полёта снаряда.)

Тестируемая толщина брони = 80мм	Побитие без HighHardness	Побитие с HighHardness	Оставшаяся прочность / падение прочности при HighHardness.
Выстрел ББ 152мм БР-540 из пушки М-10Т Д/20	96мм	81мм	84.38% / 15.62%

Тестируемая толщина брони = 40мм	Побитие без HighHardness	Побитие с HighHardness	Оставшаяся прочность / падение прочности при HighHardness.
Выстрел ББ 152мм БР-540 из пушки М-10Т Д/20	45мм	28мм	62.22% / 37.78%
Выстрел ББ 37мм М-60 из пушки 1-К Д/45	44мм	38мм	86.36% / 13.64%

Таблицы для Quality.

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

Тестируемая толщина брони = 80мм	Выстрел ББ 152мм БР-540 из пушки М-10Т Д/20	Оставшаяся прочность / относительное падение прочности.
Без Flaw	96мм	100,00%
Small_Flaw	89мм	92.71% / 7.29%
Medium_Flaw	80мм	83.33% / 9.38%
Large_Flaw	77мм	80.21% / 3.12%

Тестируемая толщина брони = 40мм	Выстрел ББ 152мм БР-540 из пушки М-10Т Д/20	Оставшаяся прочность / относительное падение прочности.
Без Flaw	45мм	100,00%
Small_Flaw	40мм	88.89% / 11.11%
Medium_Flaw	35мм	77.78% / 11.11%
Large_Flaw	33мм	73.33% / 4.45%

Тестируемая толщина брони = 40мм	Выстрел ББ 37мм М-60 из пушки 1-К Д/45	Оставшаяся прочность / относительное падение прочности.
Без Flaw	44мм	100,00%
Small_Flaw	42мм	95.45% / 4.55%
Medium_Flaw	41мм	93.18% / 2.27%
Large_Flaw	41мм	93.18% / 0%

Небольшое лирическое отступление.
Разработчики GoH преимущественно и массово применили параметр «HighHardness»
только против советских танков всех этапов войны, наплевав и на то, где эта сталь
применялась (пример: бронесталь средней твёрдости на танках семейства ИС и, само собой,
САУ на их основе в игре помечена как сталь высокой твёрдости), и на то, что в ходе войны
Советский Союз повышал стойкость (уменьшал хрупкость) брони высокой твёрдости путём
повышения её легирования (пример: литые башни Т-34-85).

Броня высокой твёрдости производилась и использовалась из-за того, что «детали из
гомогенной брони высокой твёрдости при больших углах наклона к вертикали уверенно
отражали бронебойные снаряды, по калибру примерно равные толщине самой брони»
и эффективнее противостояли массово используемым немцами остроголовым снарядам.

Снарядостойкость брони высокой твёрдости априори выше, чем брони средней твёрдости.
Каким образом у разработчиков так получилось, что броня высокой твёрдости менее стойка
по сравнению с бронёй средней твёрдости на толщинах до 50мм — непонятно.

Даже апелляция к хрупкости советской брони не выдерживает критики, если взглянуть на этот отчёт:
https://www.tankarchives.com/2013/05/soviet-armour-quality.html

Зато для обеспечения большего игрового преимущества своей любимой нации разработчики
GoH скромно и почти полностью проигнорировали тот факт, что немецкая сталелитейная
промышленность к лету 1944 года стала испытывать серьёзный дефицит легирующих
элементов, что очень ухудшило качество производимой бронетехники, сделав её хрупкой.
В GoH только несколько немецких танков и самоходок имеют некачественную броню,
а не вся немецкая бронетехника, выпускавшаяся в поздний период войны.

Источники фотографий:
https://ru.wikipedia.org/wiki/Jagdpanzer_IV
https://web.archive.org/web/20240223135535/https://warspot.ru/4750-nemetskiy-zverinets-pod-ognyom
https://www.warhistoryonline.com/war-articles/36-images-of-destroyed-panzers-and-shermans.html
https://www.warhistoryonline.com/military-vehicle-news/the-situation-in-normandy-the-german-perspective-by-world-of-tanks.html
https://web.archive.org/web/20260205063613/https://yuripasholok.livejournal.com/9217689.html https://dzen.ru/a/WUwAR33d6KST69Y2

(Т.ж. литература: «Боевые машины Уралвагонзавода - Танк Т-34» страницы 35-40. В папке с доп. материалами.)

Кстати, разработчики GoH забыли и про англичан, чьё качество брони также вызывает
некоторые вопросы. «Хрустальные» танки Vickers Mk.E, закупленные Китаем в 1934 году и
потерянные в 1937 году в ходе боёв с Японией.

Источники:
https://web.archive.org/web/20260204181901/https://yuripasholok.livejournal.com/10049407.html
https://web.archive.org/web/20251121195505/https://alternathistory.ru/yurij-pasholok-somnitelnaya-chudo-bronya-dlya-anglijskih-eksportnyh-tankov/
https://web.archive.org/web/20250219212504/https://477768.livejournal.com/6936222.html

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

Отдельного пинка разработчики GoH заслуживают и за то,
что массово раздали нацистам и их союзникам трофейную технику других стран.
Но при этом «забыли», что трофейную технику использовали не только их любимчики.

Источники:
https://web.archive.org/web/20250909025349/https://477768.livejournal.com/6794902.html
https://web.archive.org/web/20230720013935/https://mihalchuk-1974.livejournal.com/6524.html
https://web.archive.org/web/20250917134610/https://wio.ru/tank/capt/capt-ru.htm

(Т.ж. литература: «Трофеи в Красной армии. 1941-1945». В папке с доп. материалами.)

В советском союзе в 43г. было так много трофейного барахла, что на его основе
серийно (иногда десятками, а иногда и сотнями штук) производили уже собственную
бронетехнику. Пример: СГ-122 и СУ-76И.

Источники:
https://web.archive.org/web/20250123135715/https://topwar.ru/251537-protivotankovyj-potencial-i-poslevoennaja-sluzhba-sau-isu-122-i-isu-122s.html
https://web.archive.org/web/20240302014216/https://topwar.ru/172258-protivotankovye-vozmozhnosti-sovetskih-122-mm-samohodnyh-artillerijskih-ustanovok.html
https://web.archive.org/web/20240523221253/https://topwar.ru/157245-rasskazy-ob-oruzhii-su-76i-pervoe-shturmovoe.html

Но «реализм» в GoH — он только для кого и против кого надо «реализм».
Конец небольшого лирического отступления.

Волюм. (Возможности взаимодействия).

Able (Возможности волюма).
Как уже говорилось выше, волюмы предназначены не только для обработки столкновений,
но и предусматривают множество специфических опций, которые настраиваются в блоке Able.

{Volume "name"
{Able Clear ; Clear — Позволяет предварительно полностью обнулить вообще все опции.

{NoLook 0}
;Позволять ли ИИ по этому волюму обнаруживать сущность.
;(0 — Разрешать, 1 — Запрещать.)
;(Отключено. По-умолчанию 0.)

{Blast 1}
;Позволять ли волюму реагировать на взрывные волны.
;(Включено. По-умолчанию 1.)

{Blockcamera 1}
;Блокировать ли прохождение камеры через этот волюм при игре от первого лица.
;(Не блокирует сценарную камеру.)
;(Включено. По-умолчанию 1.)

{Bullet 1}
;Позволять ли волюму реагировать на столкновение со снарядами и пулями.
;(Включено. По-умолчанию 1.)

{Contact 1}
;Позволять ли волюму реагировать на столкновение с другими объемами
;(Включено. По-умолчанию 1.)

{Contact_Ground 1}
;Позволять ли игре по этому волюму рассчитывать физический контакт с
;поверхностью земли
;(Включено. По-умолчанию 1.)

{Float 0}
;Может ли этот волюм плавать на поверхности воды.
;Такие волюмы перехватывают на себя функции стабилизации на воде.
;Для корректной стабилизации должно быть хотя бы 4 таких волюма по краям модели.
;Другие Able`ы на таких волюмах обычно полностью очищаются,
;оставляя волюм специфичным, плавающим.
;(Используется только на балластных волюмах лодок.)
;(Отключено. По-умолчанию 0.)

{Hole 0}
;Вырезает ли этот волюм дыру в другом волюме данной модели.
;Другие Able`ы на таких волюмах обычно полностью очищаются,
;оставляя волюм специфичным.
;(Отключено. По-умолчанию 0.)

{Holed 0}
;Можно ли вырезать дыру в этом волюме при помощи другого волюма со свойством
;«Hole» из этой же модели.
;(Отключено. По-умолчанию 0.)

{NoWoundDecal 0}
;Позволять ли снарядам оставлять следы пробоин и иного урона на броне
;при попадании по этому волюму
;(Отключено. По-умолчанию 0.)

{Obstacle 1}
;Использовать ли этот волюм для автогенерации зон препятствий (обстаклов).
;Если у модели нет специализированного блока зон препятствий, то игровой движок
;автоматически генерирует единый обстакл модели по геометрии объёмов волюмов,
;находящихся на высоте ~25 Z-единиц (1,25 метра). Примечание: Для автогенерации
;множества обстаклов (то есть для каждого волюма отдельно) вместо одного единого,
;В DEF-файле можно глобально прописать команду {CompoundObstacles}
;(Включено. По-умолчанию 1.)

{Overlap 0}
;Присылать ли скриптовому обработчику модели системные события пересечения
;волюма с другими объектами.
;События «{on overlap begin» или «{on overlap end» с возможными дальнейшими
;проверками «{if volume "wheelr1"» или «{if bone "emit"» или «{if effector "vehicle"».
;(Например: кусты шевелятся при пересечении с солдатом.)
;(Отключено. По-умолчанию 0.)

{Select 1}
;Можно ли по этому волюму выделять сущность курсором мыши.
;В GoH на мелкой артиллерии и станковых пулемётах существуют специализированные
;волюмы большого размера, которые так и называются «select». Они предназначены
;для удобного выбора юнита пользователями с широкоэкранными мониторами.
;(Включено. По-умолчанию 1.)

{Throwing 1}
;Учитывать ли этот волюм при расчёте траектории бросаемого предмета
;(к примеру — ножа).
;(Включено. По-умолчанию 1.)

{Touch 1}
;Должен ли курсор мыши менять свой вид над данным волюмом (например, на окнах).
;(Включено. По-умолчанию 1.)

{Visible 1}
;Используется ли этот волюм для построения карты высот ландшафта,
;то есть, загораживает ли обзор для ИИ.
;(Включено. По-умолчанию 1.)

{Window 0}
;Принадлежит ли этот волюм к разбиваемому окну.
;(Отключено. По-умолчанию 0.)
}
}
;(Некоторые опции могут быть специфичны для разных игр.)

Активировать опцию можно и без прописывания единицы.
{Window} эквивалентно {Window 1}.

Скрипты интеракций позволяют управлять возможностями волюма / волюмов.
Команда «{volume» работает с контекстным волюмом.
Команда «{volumes» работает с любым / любыми волюмами.

Примеры:
{volumes disable all} ;Отключает все опции всех волюмов.
{volumes "trackleft" disable blast} ;Отключает опцию принятия взрывной волны
для волюма «trackleft».
{volumes "body" enable all} ;Включает все опции волюма «body».
{volumes "cabin" enable overlap} ;Включает опцию пересечения для волюма «cabin».
;(В качестве названий, здесь используются тэги волюмов. Но об этом — далее...)

{on contact overload
{if effector "vehicle"
{if volume "body"
{volume disable contact contact_ground}
;Отключает опции столкновения для контекстного волюма, в который корпусом врезалась техника.

Depend_On_Wind (Зависимость волюма от ветра.)
Влияет на расположение волюма в зависимости от силы и направления ветра.
Это нужно для того, чтобы расположение коллизии ствола дерева совпадало с
расположением её визуальной модельки во время сильного ветра.

{Volume "name"
{Depend_On_Wind}
}

Параметр не актуален для техники. В SoEdit`е используется в режиме совместимости.

Волюм. (Настройки материалов).

Material (Материал волюма).
Кроме броневой стали по-умолчанию существует ещё целый ряд «пользовательских»
материалов, чьи характеристики определены в файле set\material.set

Пример с назначением волюму багажника грузовика материала «дерево».
{volume "bodyback"
{material "wood"}
}

Материалом по-умолчанию является сталь, прописанная в как глобальный тэг (свойство)
в props`е properties`ов техники.
Но есть возможность локально менять материал по-умолчанию для конкретной модели.
Для этого, например для спасательной лодки, в её DEF-файле можно прописать:
{volume defaultmaterial "wood"}

Density (Плотность волюма).
Влияет на вес и, косвенно, на время физического взаимодействия волюма.
Сами по себе волюмы имеют вес, определяемый их физическими объёмами и свойствами
их материалов. Это влияет и на центр масс модели, и, косвенно на время, через которое
физический движок игры прекратит перемещать, к примеру, упавший объект.

{Volume "name"
{density 0.3} ;Задаётся в пределах [0...1].
}

Замечал обнуление плотности на волюмах минных тралов.
Замечал значения 0.01 на волюмах самолётов, которые должны подольше скользить
по земле после падения в результате сбития.

Волюм. (Привязка и идентификация).

Component (Компонент волюма).
Все компоненты модели должны иметь свои волюмы.
Принадлежность к компонентам прописываются в самих волюмах.
Каждый волюм может являться частью только одного компонента.

По умолчанию волюмы, одноимённые с компонентами, автоматически привязываются
к своим компонентам. Но так-как на один компонент может приходиться по несколько
волюмов, и так-как названия волюмов в принципе часто могут не совпадать с именами компонентов,
то иногда приходится выполнять привязку «вручную».

{Volume "name"
{Component "body"}
}

Tags (Индивидуальные тэги волюма).
Тэги волюмов позволяют скриптам и игровому движку в целом, определить предназначение
волюма. Каждому волюму игровой движок автоматически назначает тэг, равный названию
этого волюма. Но кроме этого, есть возможность настраивать тэги под свои нужды.

;У этого волюма по-умолчанию будет тэг «detail2».
{Volume "detail2"
}

;Этому волюму дополнительно назначается тэг «my_tag».
;У этого волюма будет два тэга: «detail2» и «my_tag».
{Volume "detail2"
{Tags "my_tag"}
}

;Из этого волюма сначала полностью удаляются все тэги.
;После чего ему назначается тэг «my_tag».
{Volume "detail2"
{Tags Clear "my_tag"}
}

;Из этого волюма удаляется тэг «detail2».
;После чего ему назначается тэг «my_tag».
{Volume "detail2"
{Tags "-detail2" "my_tag"}
} ;(Знак «-» здесь работает так же, как и в глобальных тэгах (props`ах) в DEF-файлах.)

В большинстве случаев, в конечном итоге у волюмов должен быть тэг, в котором
указывается название компонента, к которому этот волюм принадлежит:
{Volume "body1"
{Component "body"}
{Tags "body"}
}
{Volume "body2"
{Component "body"}
{Tags "body"}
}

В скриптах интеракций проверка волюмов выполняется по тэгу.
{on contact overload ;Переопределение обработчика столкновений.
{if effector "vehicle"; Глобальный тэг врезавшегося объекта.
{if volume "body" ; <--- Тэг волюма, в который врезались.

События {on «***», в которых можно проверять тэг волюма:
bullet_hit, pierce, break_armor, break_armor_again, blast, contact, overlap, ground_hit, blast_hit,
hit, blast_wreaked, "in_hole", "tear".

Также для волюмов существует служебный тэг «No_Target», не запрещающий, но
уменьшающий желание юнитов стрелять по этому волюму.

Bone (Кость привязки).
Все волюмы должны быть привязаны к костям своих компонентов.
Этот блок определяет, к какой кости будет привязан волюм.
{Volume "name"
{Вone "body"}
}

Волюм. (Иные возможности).

Disabled (Отключение волюма).
Иногда, допустим во время отладки, возникает необходимость отключить некоторые
волюмы, чтобы они не мешались. Для этого применяется соответствующая команда:
{Volume "name"
{Disabled}
}

(Но эта команда не влияет на отображение волюма во время рендера в игровом редакторе.)

Названия и функциональное назначение некоторых волюмов.

Волюмы «Body#»:
Волюмы компонента корпуса.
Линкуются к кости «Body».

Волюмы «Wheel*»:
Волюмы компонентов колёс.

Для автомобилей и орудий:
Волюмы «Wheelleft№» линкуются к костям «Wheell№».
Волюмы «Wheelright№» линкуются к костям «Wheelr№».
Для самолётов:
Волюм «Wheell» линкуется к кости «Wheel_l».
Волюм «Wheelr» линкуется к кости «Wheel_r».
Волюм «Wheelback» линкуется к кости «Wheelback».

Волюмы «Turret#»:
Волюмы компонента главной башни.
Линкуются к кости «Turret».

Волюмы «Aux_Turret#»:
Волюмы компонентов дополнительных башен.
Волюмы первой дополнительной башни «Aux_Turret1№» линкуются к кости «Aux_Turret1».
Волюмы второй дополнительной башни «Aux_Turret2№» линкуются к кости «Aux_Turret2».
…

Волюмы «Basket*»:
Волюмы компонента корзины с инструментами и личными вещами позади башни танка.
Линкуются к кости «Basket».

Волюмы «Mantlet*»:
Волюм компонента маски орудия.
Используется для больших орудийных масок.
Маски небольших размеров, как правило называются «Barrel№».
Линкуются к кости «Mantlet» или «Gun_Rot» по усмотрению моделлера.

Волюмы «Barrel#»:
Волюмы компонетов орудий.
Волюмы главного орудия «Barrel№» линкуются к кости «Gun_Rot»
или «Gun» по усмотрению моделлера.
Волюмы орудий первой дополнительной башни «Barrel1№» линкуются к кости «Gun1_Rot»
или «Gun1» по усмотрению моделлера.
Волюмы орудий второй дополнительной башни «Barrel2№» линкуются к кости «Gun2_Rot»
или «Gun2» по усмотрению моделлера.

Волюм «Transmission»:
Волюмы компонента трансмиссии.
Линкуется к кости «Transmission».
Присутствует на танках, автомобилях и бронеавтомобилях.

Волюм «Breech»:
Волюм казенной части орудия в бронетехнике.
Является волюмом компонента главного орудия.
Линкуется к кости «Gun_Rot».

Волюмы «Ammo#»:
Волюмы компонентов боекомплекта.
Линкуется к костям «Ammo#» или кости «Internals» по усмотрению моделлера.

Волюмы «Fuel#»:
Волюмы компонентов топливных баков.
Линкуется к костям «Fuel#» или кости «Internals» по усмотрению моделлера.

Волюмы «TrackLeft» и «TrackRight»:
Волюмы компонентов левого и правого траков.
Линкуется к костям «WheelsL» и «WheelsR» соответственно.

Волюмы «TrackLeft#» и «TrackRight#»:
Волюмы катков.
Являются волюмами компонентов левого и правого траков.
Линкуется либо к костям рессор «Suspension_L» и «Suspension_R» соответственно,
либо к костям самих катков «Wheel#» и «Wheel#» соответственно.
(Это, конечно, на усмотрение моделлера, но лучше линковать к рессорам.)

Волюмы «Stand*»:
Волюмы станин орудий.
Являются волюмами компонента корпуса.
Волюм «StandC» линкуется к кости «Support1» или кости «Center_Leg».
Волюм «StandL» линкуется к кости «Support2» или кости «Standl» или кости «Left_Leg».
Волюм «StandR» линкуется к кости «Support3» или кости «Standr» или кости «Right_Leg».
В зависимости от устройства модели.

Волюм «Select»:
Вспомогательный волюм удобного выбора юнита пользователями
с широкоэкранными мониторами.
Предназначен для мелкой артиллерии и пулемётов.
Его форма выбирается моделлером исходя из представления игрока о том,
какой формы должен быть корпус модели.
Его размер при необходимости может быть больше размера всей модели.
Линкуется к кости «Basis».

Волюм «Lamp#»:
Волюм компонента стекла прожектора.
Линкуется к кости стекла «Lamp_Glass1».

Волюмы «Hole#»:
Служебные волюмы вырезания пустот в других волюмах.
Линкуются, как правило, на те же кости, на которые линкуются волюмы, в которых вырезаются пустоты.

Волюмы «Window#» и «Glass#»:
Волюмы компонентов оконных стёкол.
Линкуются к одноимённым костям стёкол.

Волюмы «BodyBack#»:
Волюмы компонента багажного отделения грузовика.
Линкуются к кости «BodyBack».
При наличии откидных бортов соответствующие волюмы линкуются к ним.

Волюм «Sticky»:
Служебный волюм «прилипания» гранаты, закинутой внутрь техники, к ближайшему
члену экипажа. Функционирует благодаря скриптам интеракций.
Не используется в моделях GoH. В качестве такого волюма используются волюмы «Hole#»
с добавленными тэгами «Sticky».

Волюмы «Cupola#»:
Волюмы смотровых башенок.
На момент версии игры «V 1.060.0» у этих волюмов нет привязки к какому-либо
компоненту. Но эти волюмы всё равно инициализированы как элементы брони.
Но фактически скрипты интеракций воспринимают их как принадлежащие к главной башне.
Линкуются по ситуации.
Волюм, выделенный красным цветом на «БА-ФАИ» прилинкован к откидному люку башни.
Волюмы, выделенные синим цветом на той же машине, прилинкованы к корпусу.
Волюм на «Т-34» прилинкован к башне.

Волюмы «Hatch*» и «Cover*»:
Волюмы лючков.
На момент версии игры «V 1.060.0» у этих волюмов нет привязки к какому-либо
компоненту. Но эти волюмы всё равно инициализированы как элементы брони.
Бронирование этих волюмов настраивается так, чтобы лючки были вполне способы держать
огонь лёгкого стрелкового вооружения, для защиты зенитного стрелка.
Линкуются к соответствующим костям лючков.

Волюмы «Armor#» и «Hull_Armor#»:
Волюмы безкомпонентной брони.
Линкуются к костям тех компонентов, к визуальной части которых относятся.

Волюмы «Shield*»:
Волюмы компонентов экранного бронирования.
Линкуются к одноимённым костям навесной брони.

Волюм «Inventory»:
Волюм боекомплекта.
Использовался в старых играх серии вместо волюмов «Ammo».
Не имеет смысла в GoH.

Волюмы «Roller#» и «SwingArm#»:
Безкомпонентные волюмы минного трала.
Волюмы «Roller» являются разминирующими и имеют огромную толщину брони.
Волюмы «SwingArm» обеспечивают осязаемость каркаса минного трала.
Линкуются к костям, визуальными частями которых являются.
(Некоторые находящиеся на земле и не предусматривающие вращения волюмы «Roller»,
линкуются к каркасу.)

Волюм «Ram»:
Служебный клинообразный волюм упрощенного физического взаимодействия при таране
другой техники. Предназначен для отбрасывания в сторону остовов подбитой техники,
находящихся на пути движущейся техники.
Используется на автомобилях, БТР`ах, танках.
Линкуется к кости «Body».

Волюмы «Engine#»:
Волюмы компонента(ов) двигателя(ей).

Для самолётов это:
Для первого двигателя:
Волюмы «Engine1», «Engine11» … «Engine16».
Линкуются к кости первого двигателя «Engine1».
Для второго двигателя:
Волюм «Engine2».
Линкуются к кости второго двигателя «Engine2».
(Для самолётов с одним двигателем используется первый двигатель.)

Для иного моторизированного транспорта это волюмы «Engine», «Engine1» … «Engine5».

Волюмы «#Blade#»:
Волюмы компонента(ов) воздушного(ых) винта(ов).
Для первого двигателя:
Волюмы «1Blade1» … «1Blade4».
Линкуются к кости пропеллера первого двигателя «Propeller1».
Для второго двигателя:
Волюмы «2Blade1» … «2Blade4».
Линкуются к кости пропеллера второго двигателя «Propeller2».

Волюмы «Spin#»:
Волюмы компонентов воздушных винтов.
Волюм «Spin1» линкуется к кости первого двигателя «Engine1».
Волюм «Spin2» линкуется к кости второго двигателя «Engine2» (при наличии).

Волюмы «Canopy#»:
(«Canopy», «Canopy1», «Canopy2»...)
Безкомпонентные волюмы обтекателя кабины пилота.
Линкуются к кости кабины «Canopy».

Волюм «Cockpit»:
Безкомпонентный волюм лобового стекла самолёта.
Линкуются к кости корпуса «Body».

Волюмы «Aileron#»:
(«Aileron1» ... «Aileron4».)
Волюмы компонентов элеронов (поверхности управления креном).
Линкуются к одноимённым костям элеронов.

Волюмы «Elevator#»:
(«Elevator1», «Elevator2»...)
Волюмы компонентов рулей высоты.
Линкуются к одноимённым костям рулей высоты.

Волюмы «Rudder#»:
(«Rudder», «Rudder1», «Rudder2»...)
Волюмы компонента руля направления.
Линкуются к кости руля направления «Rudder».

Волюмы «Stabilizer#»:
(«Stabilizer», «Stabilizer1» ... «Stabilizer3».)
Волюмы стабилизатора самолёта.
Являются волюмами компонента корпуса.
Линкуются к кости корпуса «Body».

Волюмы «Wing*»:
Волюмы компонентов левого и правого крыла самолёта.
Волюмы нижнего (основного) левого крыла «WingL1» … «WingL3».
Волюмы нижнего (основного) правого крыла «WingR1» … «WingR3».
Волюмы верхнего (дополнительного) левого крыла «WingLT1» … «WingLT3».
Волюмы верхнего (дополнительного) правого крыла «WingRT1» … «WingRT3».
Линкуются к одноимённым костям, означающим соответствующие части (отрезки) крыльев.

Волюмы «Flap#»:
(«Flap1», «Flap2»...)
Волюмы компонентов закрылков самолёта.
Линкуются к одноимённым костям закрылков.

Волюмы «Gear##»:
(«Gear_L», «Gear2_L», «Gear_R», «Gear2_R»...)
Волюмы правого и левого компонентов механизации шасси самолёта.
Линкуются к одноимённым костям механизации.

Волюмы «Cabin#»:
Волюмы компонента кабины.
В старых играх серии применялись на кораблях и грузовых автомобилях.
Сейчас применяются только на кораблях.
Линкуется к одноимённой кости кабины.

Волюмы «Ballast#»:
(«Ballast0» ... «Ballast10».)
Безкомпонентные волюмы обеспечения плавучести.
Линкуются к кости корпуса «Body».

Волюмы «Detail#»:
Волюмы компонентов отрываемых деталей.
Используются в случае необходимости сделать деталь отрываемой.
Линкуются к одноимённым костям деталей.

Зоны. (Препятствия / Области).

Препятствия и области используются для обозначения специфических зон на игровой карте
под проецирующими их моделями.

Препятствия (обстаклы) и области (ареи) имеют одинаковое техническое устройство, но разное предназначение.

Препятствия используются для обозначения зон непроходимости юнитов.
Области используются для обозначения зон вырезания ландшафта и для обозначения зон интерьера зданий.

Зоны обладают рядом характеристик:
1) Геометрия.
2) Тип перемещения.
3) Идентификация.

Зоны. (Геометрия).

Геометрически зоны бывают трёх типов: прямоугольные, круглые, полигональные.

От типа фигуры зависят требуемые геометрические параметры и тип перемещения.

Для прямоугольных зон используются такие параметры, как: «Center», «Extent», «Axis».
{Obstacle "obstacle0"
{Obb2 ;Прямоугольник.
{Center 0 0}
{Extent 10 30}
{Axis -1 0}
}
{Rotate}
}

Для круглых зон используются такие параметры, как: «Center» и «Radius».
{Obstacle "obstacle1"
{Circle2 ;Круг.
{Radius 20}
{Center 0 0}
}
{Rotate}
}

Для полигональных зон используется параметр «Center» и перечень последовательно
соединённых «Vertex»`ов. (Последний вертекс автоматически соединяется с первым.)
(Изредка используется и параметр «Radius», «увеличивающий» размер вертексов.)
{Obstacle "obstacle7"
{Polygon2 ;Полигон.
{Radius 0}
{Vertex 49.9997 0.174746}
{Vertex -50.1744 49.8249}
{Vertex -49.8249 -50.1744}
}
{Rotate}
}

Полигональная зона может использовать только тип перемещения «Rotate».
Как и в случае с волюмом, полигональная зона должна быть конвексна.
(Читай определение из волюма.)

Одна единица для «Center», «Extent» и «Radius» соответствует одному дециметру.
Одна единица для «Vertex» соответствует половине дециметра.

Center:
Задаёт точку отсчёта для центра зоны по X/Y.

Extent:
Задаёт протяженность по X/Y.

Axis:
Двумерный вектор, описывающий угол поворота:
{Axis «ось абсцисс» «ось ординат»}

Radius:
Задаёт радиус для точки отсчёта или для вертексов.

Vertex:
Задаёт координату новой точки зоны по X/Y.

Зоны. (Тип перемещения).

Существует три типа перемещения зон: «Static», «Move» и «Rotate».
Static — Зона никак не будет реагировать на изменение положения и ориентации модели.
Move — Зона будет перемещаться вместе с моделью, но не будет реагировать на изменение её ориентации.
Rotate — Зона будет перемещаться и поворачиваться вместе с моделью.
По умолчанию всегда нужно использовать тип «Rotate».

Зоны. (Идентификация).

Tags (Индивидуальные тэги зоны).
Тэги зон позволяют скриптам и игровому движку в целом, определить предназначение
зоны. Каждой зоне игровой движок автоматически назначает тэг, равный названию
этой зоны. Но кроме этого есть возможность настраивать тэги под свои нужды.

Настройка тэгов зон совпадает с таковой у волюмов.
(Читай определение из тэгов волюмов.)
Про скрипты для зон препятствий будет сказано позже.

Зоны препятствия. (Обстаклы).

По умолчанию игровой движок сам генерирует единую зону препятствия для всей модели,
ориентируясь на проекцию её волюмов (с не отключенными опциями «Obstacle»),
находящихся на высоте ~ 1,25 метра над землёй.

Но так как для некоторых (т. е. не квадратных) моделей (вроде артиллерийских орудий или
самолётов) генерация по умолчанию работает не корректно, то необходимо вручную
создавать зоны ограничения движения, примерно описывающие контуры модели юнита.

Вручную созданные обстаклы автоматически собой замещают те, что создаются самим игровым движком.

Проецирование обстаклов на поверхность игровой карты выполняется либо по
кости «Pivot_Front», либо (при отсутствии этой кости) — по кости «Root», создаваемой для
модели самим игровым движком.
Соответственно, финализирующая матрица кости «Pivot_Front» — должна быть прямой
во избежание искажений при проекции.

Смотри видео:
https://www.youtube.com/watch?v=ryq-_QDBASk
https://rutube.ru/video/75e55d7876121e5d34bd9c7faed7d6f2/

Как правило, модели сложной формы имеют несколько простых обстаклов, описывающих её силуэт.
Для самолётов характерно использование трёх прямоугольных обстаклов, примерно
описывающих силуэт: крыльев, фюзеляжа, хвостового стабилизатора.

Для орудий без раздвижных станин характерно использование двух обстаклов:
один — для рамы с шасси, и один — для неподвижной станины.

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

В данном случае:
Красный обстакл — общий. Не принадлежит ни к одной группе и активен всегда.
Синий обстакл принадлежит к группе «Close» и включается, когда орудие переходит в транспортировочный режим.
Зелёные обстаклы принадлежат к группе «Open» и включаются, когда орудие переходит в развёрнутый режим.

За переключение групп обстаклов отвечает соответствующий «extender» в DEF-файле:
{extender "cannon"
{animation
{switch "close"}
;// "gunner" "charger" "charger2" "commander"
{move "cannon_pak40_pusher_left" "cannon_pak40_pusher_right"
"mortar_driver_l" "mgun_browning_driver_r"}
{aim "cannon_m42_gunlayer" "" "" ""}
{fire "new_cannon_gunner_fire" "new_cannon_charger_fire"
"new_cannon_charger2_fire" "new_cannon_commander_fire"}
{reload "new_cannon_gunner_reload" "new_cannon_charger_reload"
"new_cannon_charger2_reload" "new_cannon_commander_reload"}
}

;// move state: cannon being pushed and which positions play animations
{move {workers "driver1" "driver2" "driver3" "driver4" minWorkers 2} {obstacle "close"}} ;<---

;// fire/attack state: cannon aim, fire, and reload events
{attack {workers "gunner" "charger" "charger2" "commander"} {obstacle "open"}} ;<---

;// trailing state: cannon is being towed {obstacle} not needed. Uses "close"
{trailing {workers "seat1" "seat2" "seat3" "seat4"}}
}

Работой обстаклов модели можно управлять из под скриптов интеракций.
Для этого применяется команда «Area»:
{area disable "box001"} ;Выключает указанный Obstacle. (В качестве названия выступает тэг.)
{area enable "box001"} ;Включает указанный Obstacle. (В качестве названия выступает тэг.)
{area disable} ;Выключает все Obstacle.
{area enable} ;Включает все Obstacle.
{area rebuild} ;Полностью перестраивает проекцию Obstacle.

Также в случае с автогенерацией обстаклов есть возможность указать игровому движку,
что нужно генерировать не один единый обстакл по всем волюмам,
а отдельный обстакл для каждого подходящего волюма.
Для этого в DEF-файле нужно прописать: {CompoundObstacles}
(Но это не годится для техники, так как обстаклов будет слишком много.)

Прочие зоны. (Ареи).

Изначально (до релиза первой игры серии) плоские области использовались
для определения факта вхождения/выхождения юнитов в/из них.
Это приводило к срабатыванию соответствующих скриптовых событий {OnBegin "OnEnter"} и {OnEnd "OnExit"}.
Но теперь ареи имеют два более специализированных предназначения: Вырезание
ландшафта и обозначение зоны внутреннего пространства здания.

Само собой, для техники это не применимо.
В принципе, использование арей для техники — это ошибка.
Ареи не работают как обстаклы, и в SoEdit они существуют ради совместимости.
Но для справки:

Зона «Cut»:
Зона вырезания ландшафта.
Она используется для имитации углублений в земле, создания окопов, погребов и проч.

Может быть всего одна на модель.
Может работать только при объявленном и активном патчере ландшафта и только при загруженном режиме F3.
И так-как доступ к таким моделям теряется в загруженном режиме F3, то и выставлять
на карту их нужно только в загруженном режиме F2.

Зоны «Interior#»:
Зоны внутреннего пространства здания.
Таких зон у одной модели может быть некоторое количество.
Они используется игровым движком, чтобы определить нахождение юнита
пользовательского плеера внутри здания для последующего скрытия костей экстерьера.

Костями экстерьера считаются кости «Exterior#».
Этими костями могут быть любые наружные стены, сегменты, части крыши и т. д.
Скрываются также и все кости вложенные внутрь костей экстерьера.

(В данном случае кость «Exterior»`а одна. Окрашена в розовый.)

Чтобы это работало, нужно либо прописать это здание в собственную группу скрытия крыш (F2 --> Edifice),

либо прописать в её DEF-файле: {extender "edifice"}

Патчер ландшафта.

В некоторых случаях моделям нужны участки, по которым юниты могли бы перемещаться
так же, как по земле. Для этого в модель можно добавить низкополигональную мэшевую
кость с параметром «Land;». Этот параметр даёт возможность генерировать карту высот
на основе данных о мэши кости. После этого в DEF-файле нужно объявить патчер
ландшафта: {Extender "land_patch"}

(Окрашена в красный.)
(Само визуальное отображение этой кости можно отключить.)

Но в контексте техники, патчер ландшафта нужно не только объявить, но и настроить,
и соответствующим образом проскриптовать.

;В DEF-файле:
{Extender "land_patch"
{on 0} ;Патчер ландшафта выключен, пока не включим его скриптом.

{NoNormals 1} ;Не выполнять построение непроходимых участков по краю патча.
;Чтобы юнит мог сходить даже с очень крутого патча с большим перепадом высот.
;Это может требовать создания собственных обстаклов в местах,
;где юнит всё же не должен ходить по отвесной поверхности карты высот.

;Дополнительно можно прописать ещё пару парвметров:

{UpdateEntities 0} ;Не обновлять положение юнитов на патче.
;Это нужно для того, чтобы юнит не падал и не разбивался с высоты патченого
;ландшафта при его скриптовом отключении.

{TerrainType "road" "bridge"} ;Тип территории патча.
;(Тип проходимости и тип спецэффектов.)
;(По-умолчанию типы равны «земле».)
;Полный перечень типов спецэффектов и их привязок к типам территорий
;можно найти в файле: set\interaction_terrain\terrains.set
}

(Дополнительные параметры смотри в прилагающейся документации.)

Типы территорий.

Допустимые значения типа проходимости «PP»:

Ground (Земля) — Основная скорость перемещения;
No_pass (Запрет на прохождение) — Совершенно невозможно пройти по местности; (*1)
Swamp (Болото) — Топкая местность. Люди и машины тонут или движутся медленно; (*2)
Road (Дорога) — Скорость движения равносильна скорости на асфальтированной
дороге (максимальная скорость передвижения);
No_pass_human (Запрет на прохождение пехоты) — Пехота совершенно не может пройти по местности; (*3)
Snow (Снег) — Скорость движения слегка снижена;
Forest (Лес) — Скорость движения весьма снижена;
Slope (Склон) — Скорость движения снижена (особенно пехоты);
Water (Вода) — Юнит либо плывет (если может), либо тонет;
Deep_water (глубоководье) — Возможен проход больших кораблей;
Shallow_water (мелководье) — Замедление движения.
Солдат не может находиться в положении лежа, техника движется медленней.

Выделенные жирным шрифтом типы являются основными.
Подтипы: «shallow_water», «water», «deep_water» в редакторе карт представлены одним типом — «Water».
Разделение на подтипы происходит автоматически по глубине относительно «water altitude»,
задающий уровень воды относительно нуля мировых координат.

Сноски:
*1) Не во всех редакторах это работает для всех юнитов. В GoH техника просто не хочет
самостоятельно заезжать в эти зоны.
*2) Начиная с GoH юниты на этом террейне не тонут, а просто движутся медленно.
*3) Не вздумайте трогать «No_pass_human» во втором штурме. Это приведёт к вылету!

Допустимые значения типа спецэффектов «FX»:

Ground (Земля) — Пыль, воронки, фактура осыпавшейся земли;
Shallow_water (Мелководье);
Water (Вода);
Deep_water (Глубоководье);
Ppuddle (Лужа);
Mud (Грязь) — Соответствующие спецэффекты воды;
Road (Дорога) — Отсутствие пыли, минимальная пыль, воронки бетонных цветов и фактур;
Country_road — Средняя пыль, воронки оттенков земель, фактура осыпавшейся земли;
Rock (Скала) — Камни, появившиеся в результате попадания снаряда, воронки оттенков земель,
скал, фактура скал;
Ice (Лёд) — Льдинки, воронки во льду;
Swamp (Болото) — Спецэффекты воды, воронки цвета грязи;
Sand (Песок) — Густая пыль, воронки оттенков песка с фактурой осыпавшегося песка;
Bridge (Мост) — Не оставляет следов от взрывов, летят камни, доски, пыль от разрушений;
Bridge_wood (Деревянный) — Не оставляет следов от взрывов. летят деревянные щепки;
Bridge_steel (Стальной) — Не оставляет следов от взрывов, летят искры от пуль;
Bridge_snow (Заснеженный) — Остаются спрайтовые следы от взрывов, разлетаются клубы снега;
Snow (Снег) — Воронки в снегу, земля со снегом;
Grass (Трава) — Земля с травой, пыль, воронки оттенков земель и фактур.

(Доступность типов спецэффектов зависит от выбранного типа проходимости.)

Скрипты для управления техникой с патчем ландшафта:
Для примера можно взять props`овый скрипт того же десантного катера «LCVP»:

Файл: set\interaction_entity\vehicle\vehicle-main.inc
{"open_with_land" ;Название props`ового скрипта.
{on "open" ;«Пользовательский» эффект открытия аппарели.
{ani_stop "drift"} ;Остановка анимации дрейфа катера.
{ani_play "dooropen" callback} ;Старт анимации открытия аппарели с
;параметром реагирования на её завершение.

{land on} ;Включение работы патчера.
{chassis_work 0} ;Запрет возможности перемещения для модели.
{physics_work 0} ;Запрет физической симуляции для модели.
{area enable} ;Включение обстаклов (по бокам десантного отделения).
}
{on "close" ;«Пользовательский» эффект закрытия аппарели.
{ani_play "dooropen" -1 callback} ;Старт реверса анимации открытия аппарели
;с параметром реагирования на её завершение.

{ani_play "drift" loop} ;Старт цикличного воспроизведения ;анимации дрейфа катера.

{land off} ;Выключение работы патчера.
{chassis_work 1} ;Разрешение возможности перемещения для модели.
{physics_work 1} ;Разрешение физической симуляции для модели.
{area disable} ;Выключение обстаклов.
}
{on animation_end "dooropen" ;Реагирование на завершение воспроизведения соответствующей анимации
;(в любую сторону).

{update_visibility_patch} ;Разовый перерасчёт карты высот Land-параметровых костей модели.
}
}

Примечание:
Команды внутри одного delay`ного уровня выполняются скриптовым квантовщиком
как бы в один проход, «одновременно» (параллельно). И так как, по всей видимости,
квантовщик имеет беды с автоматической приоритезацией и синхронизацией исполнения
команд, то это может рандомно приводить к неисполнению некоторых команд или к вылетам.
Если полезете в скрипты, то вы сами должны заботиться о том, чтобы команды, влияющие
на одни и те же аспекты (в особенности структуры) не пересекались по времени
исполнения. Для этого можно использовать:
{delay 0
;Ваш код.
{delay 0
;Ваш код.
}
}
;для разбивки на разные кванты.
(Не стоит забывать и о том, когда вообще, в принципе, логично исполнять ту или иную команду.)

«Пользовательские» props`овые эффекты скриптов модели вызываются триггерной
командой Entity → «Effect».

(Допустим, открытие аппарели при прихождении на вейпоинт.)

С (по умолчанию) выключенным патчером.

(Карта высот считается только во волюмам. Боец не может ходить по полу катера — плывёт.)

Со включенным (по скрипту) патчером.

(Карта высот перерасчитана. Боец может ходить.)

Донастройка бронирования, компонентов, кинематики и спец. способностей.

Настройка компонентов модели не ограничивается настойкой MDL-скелета.
В DEF-файле модели и/или в сопутствующем EXT-файле, подключенном в DEF`е:
(include "bt2.ext")
необходимо выполнить донастройку параметров волюмов и
инициализировать компоненты макросами.
Кроме этого, иногда бывает нужно донастраивать кинематику и спец. способности,
вроде зоны пополнения боеприпасов.

Разные типы техники имеют схожие в целом, но различающиеся в деталях аспекты настройки.
Так, к примеру, самолёты или орудия имеют часть макросов, которые специфичны только
для этих типов техники и не могут быть вызваны для других типов.
Однако, большая часть макросов унифицирована и может использоваться для настройки почти любой техники.

Так, для самолётов донастройка включает в себя:
1) Общую реинициализацию брони при помощи одного из макросов:
("recon_tier1")
("recon_tier2")
("fighter_tier1")
("fighter_tier2")
Различия заключаются в значениях живучести компонентов.
Характеристики таких макросов для всех видов техники (кроме автомобилей) в дальнейшем
смотри в файле: properties\armor.ext

(Касаемо любой техники: Если в модели не прописан какой-нибудь подобный макрос, то
используются значения по-умолчанию из заголовочного файла.
Обычно это первый include в DEF-файле.)

2) Инициализацию компонентов.
Так как самолёт состоит из стандартных компонентов, то большая часть из них
автоматически инициализируется файлом properties\airborne.ext
имеющим также часть собственных авиа-макросов.

В DEF-файле остаётся лишь прописать:
2.1) Один из макросов количества двигателей, имеющихся у самолёта:
("single_engine")
("double_engine")
("triple_engine")
("quad_engine")

2.2) Компоненты шасси:
("wheel" args "wheelr") ;В последней паре кавычек — название волюма колеса.
("wheel" args "wheell")
("wheel" args "wheelback")
(Макрос из общего файла техники: properties\vehicle.ext)

2.3) Нестандартные компоненты, если таковые были использованы:
(Допустим, второй ряд крыльев на биплане «ПО-2».)
("wing" number(rt1) component(right_top) tag(wing))
("wing" number(rt2) component(right2_top) tag(wing))
("wing" number(lt1) component(left_top) tag(wing))
("wing" number(lt2) component(left2_top) tag(wing))

3) Настройку волюмов (иногда):
Это может быть настройка материалов, тэгов, толщин, способностей...
{volume "propeller"
{material "wood"}
{tags "no_target" "wood"}
{thickness 3.0}
{able clear {bullet} {blast} {touch} {contact} {NoWoundDecal}}
}

4) Настройку кинематики вооружения при помощи макросов:
("mp_gun_limits")
("mp_mgun_limits")
;(Это вооружение должно быть в скелете.)
Смотри файл: properties\airborne.ext

Для орудий донастройка включает в себя:
1) Настройку особых свойств (при необходимости):

1.1) Покидание орудия при вражеской атаке:
;Только для режима игры, технически не являющимся мультиплеерм.
(mod not "mp" {able "emit_on_attack"})
;Применяется на миномётах и на некоторых пулемётах.

На реактивных миномётах может использоваться в безусловной форме:
{able "emit_on_attack"}

1.2) Тип прикрепления объекта:
{constrain none} ;В данном случае нет привязки ни по высоте, ни нормали к поверхности.
Видел использование на пулемётной турели.

1.3) Запрет стрельбы по умолчанию:
(mod "mp"
{brain
{properties
{fire_mode hold}
}
}
)
;Только для режима игры, технически являющейся мультиплеерм.
;Применяется на реактивных миномётах.

1.4) Запрет физической симуляции:
{simulation {able 0}}
;Допустим, на советской береговой батарее «305мм MB-2-12».

2) Инициализацию некоторых компонентов:

2.1) Ствол орудия (при его наличии):
("gun" repair(30) thickness(20)) ;30 — время ремонта, 20 — толщина.

;Дополнительные орудия:
("gun1" repair(60) thickness(120))
("gun2" repair(60) thickness(120))

2.2) Компоненты шасси:
;Для резиновых колёс:
("wheel" args "wheelright1")
("wheel" args "wheelright2")
("wheel" args "wheelleft1")
("wheel" args "wheelleft2")

;Для цельнометаллических колёс:
("solid_wheel" args "wheelleft")
("solid_wheel" args "wheelright")

2.3) Щитки (при наличии):
;Каждый щиток как отдельный компонент.
("shield" args "shield" 8) ;После «args» прописывается название волюма и его толщина.
("shield" args "shield_lower" 8)
("shield" args "shield_upper" 8)

;Несколько щитков как один компонент:
("shield_group" args "shield1" 8 "shield")
("shield_group" args "shield2" 8 "shield")
("shield_group" args "shield21" 8 "shield2")
("shield_group" args "shield22" 8 "shield2")
;В последней паре кавычек прописывается название объявляемого компонента.

3) Общую реинициализацию брони при помощи одного из макросов
(для орудий с заголовком (include "/properties/cannon.ext") ).
("armor_carried_cannon") ;MGs and mortars
("armor_light_cannon") ;37-47mm, autocannons, Nebelwerfer
("armor_medium_cannon") ;50-100mm
("armor_heavy_cannon") ;howitzers, big towed guns

(Для орудий с заголовком (include "/properties/cannon_mgun.ext") макрос не требуется.)

3.1) Реинициализацию толщины брони (для некоторых сверхтяжёлых орудий):
("cannon_thickness" args 25)

4) Настройку волюмов (иногда):
В основном это включает в себя настройку способностей или тэгов.
{volume "body5" {tags "invisible"}} ;// volume disabled on carriage hidden
{volume "wheelleft" {tags "invisible"} {able {visible 0}}}
{volume "wheelright" {tags "invisible"} {able {visible 0}}}

Если орудие является транспортируемым (то есть имеет props "wheeled") и при этом
имеет props "invisible", то осязаемостью волюмов с тэгом "invisible" начинает управлять
скрипт интеракций: {"cannon wheeled invisible"
Из файла: set\interaction_entity\cannon.inc
Указанные волюмы становятся неосязаемыми при разворачивании орудия.

5) Настройку кинематики для некоторых подвижных костей:
{bone "basis"
{speed2 15}
}
{bone "turret"
{limits -5 5}
{speed2 10}
}
{bone "gun_rot"
{limits -13 15}
{speed2 10}
}
(Если настраиваемых костей нет в скелете, игра вылети с ошибкой.
Или, если указанные значения не будут подходить под необходимый для этого
тип кинематики, настройки не применяться или игра вылетит. с ошибкой.)

Для автомобилей донастройка включает в себя:
1) Настройку особых свойств (при необходимости):
(Допустим зону пополнения боеприпасов или топлива.)

Для этого в заголовке модели нужно прописать соответствующий «include» «resupply».
{game_entity
(include "/properties/car.ext")
(include "/properties/selection/vehicle_elongated.inc" scale(1.10))
(include "/properties/resupply.inc") ; <----

И вызвать один макрос желаемого типа пополнения:
("truck_ammo_heavy") ;Патроны + артиллерийские боеприпасы.
("truck_ammo_heavy_2x") ;Патроны + артиллерийские боеприпасы X2.
("supply_engineer") ;Сапёрный инвентарь.
("supply_engineer_light") ;Сапёрный инвентарь (в 2,5 раза меньше).
("supply_fuel" liters(2840)) ;Пополнение топлива для техники и огнемётчиков.
Смотри файл: properties/resupply.inc

2) Инициализацию некоторых компонентов:
2.1) Компоненты шасси:
("wheel" args "wheelright1")
("wheel" args "wheelright2")
("wheel" args "wheelleft1")
("wheel" args "wheelleft2")

;Компоненты траков (для полугусеничников).
("tracks" repair(30) thickness(15)) ;30 — время ремонта, 15 — толщина.

2.2) Компоненты стёкол:
("glass" args "glass1") ;В последней паре кавычек — название волюма.
("glass" args "glass2")
("glass" args "window1")
("glass" args "window2")

2.3) Компоненты топливных баков (обычно у автомобилей он один):
("fuel" args "fuel1") ;В последней паре кавычек — название волюма.
...

2.4) Компонент трансмиссии:
("transmission" args "transmission") ;В последней паре кавычек — название волюма.

2.5) Компоненты боеукладок (при наличии):
("ammo" args "ammo") ;В последней паре кавычек — название волюма.
...

2.6) Компонент кузова (для грузовика):
("bodyback" repair(30))

2.7) Компонент брезентового чехла кузова (при наличии):
("shield_cover")
;(Только для волюмов «shield_cover», «shield_cover1», «shield_cover2».)

2.8) Щитки (при наличии):
;(Допустим, зенитные или реактивные установки на базе грузовиков.)
("shield" args "shield1" 5)
("shield" args "shield2" 5)
("shield_group" args "shield1" 6 "shield")
("shield_group" args "shield2" 6 "shield")
;(Настройка такая же, что и в орудиях.)

2.9) Компоненты орудия и механизма горизонтального наведения (при необходимости):
("gun" repair(30) thickness(15))
("turret" repair(45))
;(Допустим, на зенитной установке на базе грузовика.)

3) Реинициализацию толщины брони (при необходимости):
("car_thickness" body(3) engine(1.5))
;3 — толщины волюмов корпуса, 1.5 — толщины волюмов двигателя.

4) Настройку волюмов (иногда):
В основном это включает настройку способностей, материалов или тэгов:
{volume "detail10"
{thickness 0.5}
{material "fabric"}
{able {NoWoundDecal} {holed}}
{tags "armor"}
}

Иногда может применяться макрос для обозначения волюмов в качестве деревянных:
("wood" args "bodyback1") ;В последней паре кавычек — название волюма.
("wood" args "bodyback2")
("wood" args "bodyback3")

5) Настройку кинематики для некоторых подвижных костей:
{bone "mgun_a_rot1"
{speed2 60}
}
{bone "mgun_a_rot2"
{speed2 60}
}
;(Настройка такая же, что и для орудий.)

Для бронеавтомобилей и танков донастройка включает в себя:
1) Настройку особых свойств (при необходимости):
(Допустим зону пополнения боеприпасов или топлива.
;Настройка такая же, что и для автомобилей.)

2) Общую реинициализацию брони при помощи одного из макросов:
2.1) Для БТР`ов: ("armoredcar_tier1") или ("armoredcar_tier2")
2.2) Для танкеток: ("tankette_tier1")
2.3) Для лёгких танков: ("tank_light_tier1") или ("tank_light_tier2")
2.4) Для средних танков: ("tank_medium_tier1") или ("tank_medium_tier2")
2.5) Для тяжёлых танков: ("tank_heavy_tier1") или ("tank_heavy_tier2")

3) Инициализацию некоторых компонентов:
3.1) Компоненты шасси:
;Колёса (для БТР’ов):
("wheel" args "wheelright1")
("wheel" args "wheelright2")
("wheel" args "wheelleft1")
("wheel" args "wheelleft2")

;Для цельнометаллических колёс:
("solid_wheel" args "wheelright1")
("solid_wheel" args "wheelleft1")
("solid_wheel" args "wheelright2")
("solid_wheel" args "wheelleft2")

;Компоненты траков (для танков и полугусеничников):
("tracks" repair(30) thickness(15)) ;30 — время ремонта, 15 — толщина.

3.2) Дополнительные башни (при наличии):
("aux_turret" repair(45))
;Макрос объявляет компоненты: «Aux_Turret1», «Aux_Turret2»,
«Aux_Turret3», «Aux_Turret4».
;И сопоставляет с каждым из них по три волюма:
«Aux_Turret№», «Aux_Turret№1», «Aux_Turret№2», где № — это номер башни.

Для привязки дополнительного волюма можно использовать соответствующий макрос:
("make_component" args "aux_turret13" "aux_turret1")
;«Aux_Turret13» — Имя волюма. «Aux_Turret1» — Название компонента, к которому будет
привязан волюм.

Несмотря на название «Make_Component», этот макрос не объявляет компонент, а только привязывает волюм к нему.

3.3) Щитки (при наличии):
Или детали, настроенные как щитки.
("shield" args "shield1" 9)
("shield" args "shield2" 10)
("shield" args "detail1" 15)
("shield" args "detail2" 15)
При желании, можно доинициализировать компонент.
{component "detail1" {tags "cut_part"}}
;Компоненту указывается тэг возможности его отрыва при повреждении.
Смотри перечень допустимых компонентов в файле: set\interaction_entity\tank\tank-main.inc
Примерно со строки 361. (Версия игры на момент написания: V 1.061.0.)

("shield_tear" args "shieldl1" 5)
("shield_tear" args "shieldl2" 5)
;Волюму и компоненту щитка сразу задаётся тэг «Cut_Part», обозначающий возможность его отрыва при повреждении.

("shield_track" args "shield1" 15)
;Конструкционная сталь. Макрос уменьшает прочность вдвое.

("shield_group" args "detail11" 10 "detail1")
("shield_group" args "detail12" 10 "detail1")
;(Настройка такая же, что и в моделях.)

("shield_part" args "shield3" 105 "turret")
("shield_part" args "shield4" 105 "turret")
;Тоже самое, что и «Shield_Group», но без объявления указанного компонента
; — только привязка.

("gun_shield" args "gun_shield" 10)
("gun_shield" args "gun_shield1" 8)
;Макрос предназначен для защиты орудия на САУ с открытым верхом.
;Позволяет ранить/оглушить экипаж при проникновении снаряда внутрь.
;Компоненты техники не повреждаются.

3.4) Компонент брезентового чехла кузова (при наличии):
("shield_cover")
;Допустим, на «M3A1».

3.5) Компонент кузова (для тягачей):
("bodyback" repair(30))
;Допустим, на «Sd.Kfz 6».

3.6) Ствол орудия (при наличии):
("gun" repair(30) thickness(20))
;(Настройка такая же, что и в моделях орудий.)

3.7) Компонент главной башни (механизм горизонтального наведения).
("turret" repair(45))
;(При необходимости и только для БТР`ов.)

3.8) Компонент маски орудия.
("mantlet" repair(30))
;(При необходимости и только для БТР`ов.)

3.9) Компоненты стёкол.
("glass" args "window1")
("glass" args "window2")
;(При необходимости и только для БТР`ов.)

3.10) Компоненты топливных баков.
("fuel" args "fuel1")
("fuel" args "fuel2")

3.11) Компоненты боеукладок.
("ammo" args "ammo1")
("ammo" args "ammo2")

3.12) Компонент трансмиссии.
("transmission" args "transmission")

3.13) Компоненты внешних реактивных боеприпасов.
("rocket" args "rocket00")
("rocket" args "rocket01")

4) Настройку волюмов.
В основном это включает в себя настройку толщин, способностей и тэгов.
{volume "body2"
{thickness 60
{front 75}
{top 40}
{rear 20}
{bottom 20}
}
{CastSteel 0.8063}
}
{volume "barrel4"
{able {holed}}
}
{volume "armor1"
{thickness 10
{front 20}
{rear 20}
}
{tags "armor"}
}

Иногда может применяться макрос для донастройки волюмов безкомпонентной брони:
("armor" args "armor1" 20) ;После «args» прописывается название волюма и его толщина.
("armor" args "armor2" 20)

5) Настройку кинематики для некоторых подвижных костей.
{bone "gun_rot"
{limits -5 20}
{speed2 5}
}
{bone "aux_turret1"
{limits -15 15}
{speed2 5}
}

;Для настройки скорости вращения башен можно применять соответствующие макросы:
{bone "turret"
("turret_light" power_traverse(0)) ;// manual
;Малые башни, БТР/лёгкие танки.
}
{bone "turret"
("turret_medium" power_traverse(19))
;Средние башни, большие башни, легкие танки, средние танки.
}
{bone "turret"
("turret_heavy" power_traverse(24))
;Тяжёлые башни, большие башни средних танков, тяжёлые танки.
}

Формулы макросов уточняй в файле: properties\mobility.inc

;{speed2 (+ 10 (/ %power_traverse 2.5))}
;Расшифровывается как:
;speed2 = 10 + (power_traverse / 2.5)

Некоторые аспекты устройства моделей.

Пример орудия «37-мм 1-K».
(MDL-файл.)

;(Блок общих анимаций модели.)
{skeleton
{animation
{sequence "recoil" {speed 0.9}} ;Анимация выстрела.
{sequence "close" {speed 0.65}} ;Анимация складывания орудия
;для транспортировки (изменения положения).
{sequence "aim_v" {speed 1}{resume}} ;Анимация вращения ручки
;вертикального привода. (Кость «Aim_Wheel1».)
{sequence "aim_h" {speed 1}{resume}} ;Анимация вращения ручки
;горизонтального привода. (Кость «Aim_Wheel2».)

(Элементы скелета.)

(DEF-файл.)

;(Заголовок.)
{game_entity
(include "/properties/cannon.ext") ;Заголовочный файл.
{extension "37mm_m30.mdl"} ;Загрузка файла скелета модели.
(include "/properties/selection/cannon_elongated.inc" scale(0.9)) ;Декаль под юнитом.
{props "cannon_small" "wheeled" "vision_lev02_can" "muzzle_37mm_47mm" "cannon_sandbag_small" "trailer" "trailer_light"
"detect_atgun_small" "c_at_lite"}
;Перечень глобальных тэгов/свойств модели.
;Здесь:

;"cannon_small" — Обозначает модель как лёгкую пушку для скриптов.
;Позволяет раздавить пушку бронемашинами, в то время как обычно это невозможно.
;из: set\interaction_entity\cannon.inc

;"wheeled" — В конечном итоге, в данном случае, управляет скоростью
;и возможностью перекатывания орудия в зависимости от повреждённости шасси.
;Смотри файл: set\interaction_entity\cannon.inc
;Примерно со строки 525. (Версия игры на момент написания: V 1.061.0.)

;"vision_lev02_can" — Определяет заметность юнита.
;Смотри файлы в папке: set\vision\

;"muzzle_37mm_47mm" — Определяет пыльность/шумность/дымность
;выстрела главного калибра.
;Смотри файл: set\interaction_entity\muzzle.inc

;"cannon_sandbag_small" — Определяет возможность создания небольшого
;укрепления для орудия.
;Смотри файл: interface\action\sandbag_vehicle.set
;Смотри файл: set\interaction_entity\vehicle\vehicle-main.inc
;Примерно со строки 1138.

;"trailer" — Определяет возможность транспортировки этого орудия за
;соответствующую кость при помощи любого тягача.

;"trailer_light" — Нет данных.
;На момент написания статьи в игре нет определения для этого свойства.

;"detect_atgun_small" — Определяет видимость/слышимость юнита в тумане войны.
;Смотри файл: set\detect.set

;"c_at_lite" — Нет данных.
;На момент написания статьи в игре нет определения для этого свойства.

{collider "cannon_small"} ;Определяет работу коллизии.
;Смотри файл: set\colliders.set

{targetclass "cannon_small"} ;Какой целью является юнит.
;Смотри файл: set\target\ammo.set

{targetSelector "cannon_small"} ;С какими целями и какими средствами он должен бороться.
;Смотри файл: set\target\select.set

;(Настройка специфики работы орудия.)
{extender "cannon"
{animation
{switch "close"};Название анимации, меняющей положение орудия
;(из главного блока анимаций скелета).

;// "gunner" "charger" "charger2" "commander"
{move "cannon_pak40_pusher_left" "cannon_pak40_pusher_right" "mortar_driver_l" "mgun_browning_driver_r"}
{aim "cannon_small_gunner_aim" "cannon_small_charger_aim" "cannon_small_charger2_aim" "cannon_small_commander_aim"}
{fire "cannon_small_gunner_fire" "cannon_small_charger_fire" "cannon_small_charger2_fire" "cannon_small_commander_fire"}
{reload "cannon_small_gunner_reload" "cannon_small_charger_reload" "cannon_small_charger2_reload"
"cannon_small_commander_reload"}

;По умолчанию названия вышеприведённых анимаций указываются
;в соответствии с последовательностью объявленных посадочных мест своего типа.
;Move = Move (транспортировка орудия экипажем).
;Aim (Прицеливание) / Fire (Выстрел) / Reload (Перезарядка)
; = Attack (Орудие развёрнуто).
}
;Но нижеприведённые блоки: Move / Attack / Trailing способны переопределять
;последовательность (а значит и сопоставление) посадочных мест и анимаций.

{move {workers "driver1" "driver2" "driver3" "driver4" minWorkers 2} {obstacle "close"}}
;//Состояние move: пушка выдвигается и в каких позициях воспроизводится анимация

{attack {workers "gunner" "charger" "charger2" "commander"} {obstacle "open"}}
;//Состояние fire/attack: прицеливание пушки, стрельба и перезарядка

{trailing {workers "seat1" "seat2" "seat3" "seat4"}}
;//Состояние буксировки: пушка буксируется, {obstacle} не требуется.
;Используется "close".

;Примечания:
;1) Анимации из блоков: Move/Aim/Fire/Reload должны быть визуально совместимы
;с позами сопоставленных посадочных мест. (Блок «Boarder». Смотри в своём DEF`е.)

;2) Если какому-либо члену экипажа не нужны дополнительные анимации,
;то в кавычках ничего не пишется: {aim "cannon_m42_gunlayer" "" "" ""}

;3) Иногда в блоке «Fire», после названия анимации (через пробел), может
;указываться время задержки срабатывания анимаций из блока «Reload» (в сек).
;{fire "Cannon_gunlayer_fire-alert" "cannon_zis3_charger_fire 0.13"}

;4) Иногда в конце экстендера может прописываться {rotate_ik_Limit 0},
;запрещающий орудию вращать станину, что требует от игрока вручную переводить
;орудие в транспортировочный режим для его разворота в нужную сторону.
}

;MinWorkers — (Здесь), минимально необходимое количество членов экипажа для ручной транспортировки.

;Obstacle — Название задействуемой группы препятствий модели.

Пример автомобиля «ГАЗ-ААА».
(MDL-файл.)

;Блок общих анимаций модели.
{skeleton
{animation
{sequence "start" {speed 0.6}} ;Анимация старта движения.
{sequence "stop" {speed 0.6}} ;Анимация торможения.
{sequence "doorleft" {speed 0.6} {events {1 "truck_open"} {62 "truck_close"}}}
;Анимация открытия левой двери кабины.

{sequence "doorright" {speed 0.6} {events {1 "truck_open"} {61 "truck_close"}}}
;Анимация открытия правой двери кабины.

{sequence "close_back" {speed 0.6} {events {13 "tailgate_close"}}}
;Анимация закрытия кузова грузовика.

{sequence "open_back" {speed 0.6} {events {1 "tailgate_open"}}}
;Анимация открытия кузова грузовика.

{sequence "board" {speed 1} {events {0 "board"}}}
;Анимация-заглушка, срабатывающая при посадке пассажиров.
;Должна быть прописана в конфигурациях анимаций посадки/высадки
;пассажиров.

;Вроде чего-то такого в DEF-файле:
;{boarder
; {anm "passenger"
; {forward {begin "board_body"} {end "seat_passenger"} {base "board"}} <---
; {reverse {end "emit_body" 1} {base "board"}} <---
; }
;}
;Позволяет управлять анимациями «open_back» и «close_back» через
;скрипты интеракций при наличии у этого транспортного юнита свойства
;«multi_board».
}
}

(Элементы скелета.)

Кость «dummy» — это просто заглушка, используемая в такой же
анимации-заглушке «board».

(DEF-файл.)

;(Заголовок.)
{game_entity
(include "/properties/car.ext") ;Заголовочный файл.
(include "/properties/selection/vehicle_elongated.inc" scale(1.0)) ;Декаль под юнитом.
{props "multi_board" "truck" "vision_lev02" "tractor" "tractor_heavy" "Captor"}

;Перечень глобальных тэгов/свойств модели.
;Здесь:

;"multi_board" — Обозначает наличие пассажирской багажной/кузовной двери
;у транспортного средства. Подключает скрипт интеракций,
;управляющий анимациями «open_back» и «close_back».
;Смотри файл: set\interaction_entity\vehicle\vehicle-main.inc
;(Строка 1530 на момент написания справки.)

;"truck" — Обозначает для скриптов модель как грузовик.
;Переопределяет в скриптах параметры устойчивости к урону.
;из: set\interaction_entity\car-main.inc

;"vision_lev02" — Определяет заметность юнита.
;Смотри файлы в папке: set\vision\

;"tractor" — Определяет для этого юнита возможность транспортировать орудия за
;соответствующую кость.

;"tractor_heavy" — Расширяет возможность транспортировки вплоть до тяжёлых орудий.

;"Captor" — используется для того, чтобы боты перемещали приказы и останавливались на расстоянии от флагов.

{able "emit_on_attack"} ;Покидание орудия при вражеской атаке.

{extension "gaz_aaa.mdl"} ;Загрузка файла скелета модели.

{collider "truck"} ;Определяет работу коллизии.
;Смотри файл: set\colliders.set

{patherId "gazaaa"} ;Определяет проходимость юнита.
;Смотри файл: set\pather.set

Пример танка «БТ-5 обр. 1934 г.».
(MDL-файл.)

;Блок общих анимаций модели.
{skeleton
{animation
{sequence "start" {speed 0.7}} ;Анимация старта движения.
{sequence "stop" {speed 0.7}} ;Анимация торможения.
{sequence "fire" {speed 0.75}} ;Анимация выстрела.
{sequence "open_driver" {speed 0.1} {events {2 "hatch_light"} {16 "hatch_light"}}}
;Анимация люка механика водитля.

{sequence "open" {speed 0.1}{resume} {events {2 "hatch_light"}}}
;Анимация основного (ых) люка экипажа.
;Закрывается, если в танке есть хотя бы один член экипажа.
;Открывается, либо если в танке не осталось экипажа,
;либо если в танке есть зенитный стрелок.

(Элементы скелета.)

(Описание DEF-файла похожего танка можно найти в главе,
посвящённой устройству DEF-файла, как такового.)

Повреждённые версии моделей.

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

Модели зданий, конструкций и сооружений разрушаются в основном в одну стадию,
так как не предполагают ремонта.

Модели техники имеют две стадии:
1) Повреждённая — подразумевающая возможность ремонта пострадавших компонентов;
2) Полностью уничтоженная — не подразумевающая ремонта.

Повреждённые и уничтоженные версии моделей именуется точно так же,
как неповреждённые, но с добавлением постфиксов «_x» и «_xx» соответственно.

Названия файлов моделей получаются следующие:
t26_33.def — Неповреждённая модель.
t26_33_x.def — Повреждённая версия.
t26_33_xx.def — Уничтоженная версия.

В игре они могут выглядеть примерно так.

X и XX версии моделей принято хранить в отдельной подпапке «X», находящейся рядом с папкой модели.

Как при получении определённого повреждения, так и при ремонте игра
способна «на лету» подменять части компонентов модели, некоторые из которых, кстати,
не обязаны терять свою функциональность при нефатальном повреждении.
(Пример: колесо автомобиля может быть повреждено, но автомобиль может
продолжать движение, хоть и с меньшей скоростью.)

Визуальные изменения повреждённой модели от целой достигаются несколькими основными способами:
1) Изменением текстуры.
Следы попаданий, следы копоти и гари, ржавчина, грязь, царапины, потёртости, сколы.
Если геометрия имеет один полигональный слой, не уходящий вглубь машины,
то он может быть «продырявлен» альфа-каналом.
Может применяться текстура спекуляра, подчёркивающая новые сколы краски.

2) Изменением некоторой геометрии.
Оборванные гусеницы, спустившие колёса, погнутая немассивная геометрия.

3) Работой анимации.
Автоматически срабатывающая анимация повреждения компонентов,
меняющая расположение и ориентацию некоторых костей таким образом, чтобы игроку
сразу становилось очевидно состояние пострадавшего компонента.
(Анимация ремонта должна возвращать на место те кости, что были перемещены анимацией поломки.)

Техническое исполнение повреждённой модели заключается в следующем:
1) Нужно скопировать неповреждённую модель и добавить к её названию постфикс «_x».
2) Откройте «_x» модель.
3) Удалите все волюмы, за исключением тех, которые должны изменится вслед за
изменением размера своего мэша.
(Вроде спустивших колёс автомобиля, чьи волюмы также должны быть уменьшены.)

4) Удалите вспомогательные безмэшевые кости, от которых не зависит геометрия модели.
Это кости: «emit», «visor», «seat», «headlight», «foresight», «shooter», «fxtrace»...
Но нельзя удалять, к примеру, кости «suspension_», на которые крепятся катки и колёса,
или «gun_rot», на который крепится орудие.

5) Удалите кости «enumerator».
6) Удалите все анимации из главного блока анимаций скелета.
7) Замените главные компонентные мэши их повреждёнными версиями.
8) Измените размеры волюмов под новые размеры изменённых мэшей
(если такие есть из пункта 3).

9) В тех основных физических костях (вроде «body», «turret» ...), которые содержат
внутреннюю анимацию ремонта, нужно заменить анимацию «repair» на анимацию «break»
(с соответствующей заменой файлов с самой анимацией).

10) Если у вас нет повреждённых версий каких-либо текстур, то их нужно создать.
Вообще, способов испортить текстуры довольно много, и основные стилистические способы
описаны выше. Но в дополнительных материалах к справке есть отдельное руководство
по созданию x/xx-текстур. Обычно я просто миксую неповреждённые версии текстур с
текстурой повреждений «crash.dds» (также есть в папке дополнительных материалов).
Повреждённые версии текстур, для удобства, также можно именовать постфиксом «_x».

11) Пропишите повреждённые текстуры в материалах повреждённой модели.

DEF-файлы повреждённых моделей устроены достаточно просто.
В основном это просто вызов файла скелета и указание бесполезной директивы {RimLight}.

;Начало DEF-файла «X»-модели.
{game_entity
{extension "bt5_x.mdl"} {RimLight}
}
;Конец DEF-файла «X»-модели.

RimLight бесполезен, так как за контурную подсветку (ореолы) отвечает включенный блок
«Brain», и работа ореолов попросту наследуется с неповреждённой модели.

Визуальные изменения полностью уничтоженной модели от повреждённой достигаются
несколькими основными способами:
1) Изменением текстуры.
Эффект крупного пожара; Следы ржавчины; Обильная грязь.
Может применяться текстура бампа, подчёркивающая деформацию геометрии.

2) Изменением некоторой геометрии.
Части мэшей (включая массивные) могут быть сильно деформированы или отсутствовать.
Можно удалить декоративные (и некоторые второстепенные компонентные) кости.

3) Отрыванием некоторых компонентов.
Некоторые элементы (вроде колёс и лючков) могут быть преобразованы в обломки «part#»,
разлетающиеся в разные стороны согласно игровой физике в момент взрыва техники.

Техническое исполнение уничтоженной модели заключается в следующем:
1) Нужно скопировать неповреждённую модель и добавить к её названию постфикс «_xx».
2) Откройте «_xx» модель.
3) Удалите вспомогательные безмэшевые кости, от которых не зависит геометрия модели
(так же, как при создании повреждённой модели).

4) Удалите кости «enumerator» и «detail».
5) Удалите все анимации как из главного блока анимаций, так и из костей.
6) Замените мэши их уничтоженными версиями.
7) Кости, которые должны стать разлетающимися обломками нужно переименовать в номерные «part»`ы.

Ограничтесь не более чем 10 обломками на модель (а лучше 2-5).
Волюмы не компонентных переименованных костей-обломков нужно переименовать
соответственно названию их обломков.
(У всех обломков должны быть волюмы. Если их нет — создайте. Геометрия волюмов
обломков, желательно, должна быть упрощённой.)

8) Если у вас нет уничтоженных версий каких-либо текстур, то их нужно создать.
(Способ такой же, как и при создании повреждённой версии текстур.)

9) Пропишите уничтоженные текстуры в материалах уничтоженной модели.

DEF-файлы уничтоженных моделей подразумевают указание толщин тех же волюмов, как у неповреждённой модели.

;Начало DEF-файла «XX»-модели.
{game_entity
(include "/properties/vehicle_xx.ext")
{extension "m4a1_76w_xx.mdl"}
; ...
{volume "body7"; Hull lower middle
{thickness 38.1 {front 63.5} {rear 10} {bottom 25.4}}
}
; ...
{volume "part1"
{thickness 25}
}
; ...
("tracks" thickness(20))
; ...
}
;Конец DEF-файла «XX»-модели.

Примечания:
1) При создании повреждённых и уничтоженных версий моделей необходимо соблюдать
исходную иерархию, названия и матрицу костей. (Про имена обломков это не касается.)

2) LOD`ы также необходимо подвергать изменениям, соответствующим их основным мэшам.

Примеры использования программы.

Пять примеров: один практический и четыре теоретических.
Первый пример нацелен на ваше обучение нажатию нескольких базовых кнопок.
Второй пример демонстрирует возможность по сборке моделей из нескольких других.
Третий и четвёртый примеры дополнительно демонстрируют возможности по созданию
и настройке препятствий и анимаций.
Пятый пример показывает возможность экспорта и использования собственных запчастей.

Пример-1: Базовое использование SOEdit.
Вашей задачей в этом примере станет сборка и донастройка танка: T-34-85M.
(Изначально, модель имеет не финальное состояние.)

Файл «_t3485m (Пример).7z» с этим модом для редактора на GoH есть в папке с
дополнительными материалами к справке.
Совместимость с другими модами не гарантируется.
Этот мод должен работать на всех версиях игры, по идее...
Но никогда не знаешь, что разработчики игры сломают в следующем патче.

Так как в версии SOEdit v0.7m5* программа ещё не может работать с игровыми архивами,
то неадекватным, но рабочим вариантом заставить её видеть игровые текстуры является
распаковка игровых архивов.
(Чтобы не потерять сетевую синхронизацию, рекомендую распаковывать и подключать
к SOEdit скопированную папку игры, а не оригинал.)
Для этого примера распаковка игровых ресурсов не требуется — всё уже зашито в мод.

Инструкция.

1) Распакуйте мод с примером в папку модов игры.
Можете подключить его в самом игровом редакторе.

2) Запустите SOEdit.
3) Пропишите мод с примером в преференциях, а также пропишите свой Ник в свойствах программы.

4) Откройте модель.

Программа сругнётся на неправильно настроенную модель. Проигнорируйте это сообщение.

Модель откроется в таком виде:

5) Исправьте расположение костей «t3485m_turret», «wheelsr», «wheelsl» используя 2D-окна.

6) Исправьте ориентирование кости «t3485m_turret», используя 2D-окна.

7) Подшейте соответствующие названию мэши к костям:
«t3485m_wheell1», «t3485m_wheell3», «t3485m_wheelr1», «t3485m_wheelr3», используя редактор костей.

8) Добавьте новую визуальную кость пушки «t3485m_gun» (выбранную из файла)
в кость «gun», которая в данном случае является логической.

(Визуально корректно спозиционируйте и сориентируете добавленную кость «t3485m_gun»,
как научились этому в пунктах 5 и 6.) (Менять расположение кости «gun» нельзя.)

9) Добавьте и спозиционируйте новую логическую кость «foresight1» в кость «gun».

10) Пропишите параметры в указанных ниже костях.

В кость «basis» скопируйте строку «Wheelradius=0.46;».
В кость «t3485m_body» скопируйте строку «id=body;».
В кость «t3485m_turret» скопируйте строку «id=turret;».
В кость «t3485m_gun» скопируйте строку «id=gun;».
В кость «t3485m_wheell1» скопируйте строку «id=trackleft;radius=0.25;».
В кость «t3485m_wheell3» скопируйте строку «id=trackleft;radius=0.31;».
В кость «t3485m_wheelr1» скопируйте строку «id=trackright;radius=0.25;».
В кость «t3485m_wheelr3» скопируйте строку «id=trackright;radius=0.31;».
(Копировать нужно всё содержимое кавычек.)

11) Включите кинематическую привязку «Revolute» в костях: «wheell1», «wheell7», «wheelr1», «wheelr7».

12) Добавьте в кость «body» волюмы «body1» и «body2» из файлов.

13) Последовательно спозиционируйте и сориентируете эти волюмы,
чтобы они корректно ложились на визуальную модель.

14) Добавьте анимацию «fire» в глобальный блок анимаций и пропишите ей скорость «0.8».

15) Сохраните модель.

(При этом программа не должна выдавать ошибок.)

Пример-2: Колхоз.
Самой типичной задачей программы является адский колхозинг юнитов.

Допустим, вам зачем-то понадобилось приколхозить башню от ИС-2 на Т-34.

1) Скопируйте папки ИС-2 к Т-34 куда-нибудь.

2) Придумайте Т-34 новое название.

3) Откройте Т-34 в SOEdit и удалите все волюмы и мэши башни.

4) Удалите PLY- и VOL-файлы, которые относились к башне.

5) Сохраните Т-34 и откройте ИС-2.

6) Выпишите список файлов (включая анимации и материалы), задействованных в башне ИС-2.

(Список файлов материалов можно просматривать через твикер.)

7) Скопируйте эти файлы куда-нибудь.

8) Сравните имена файлов из списка ИС-2 с именами файлов в папке Т-34 и переименуйте
совпадающие в списке из ИС-2.

9) Переместите эти файлы в папку Т-34.

10) Скопируйте ветвь костей башни из ИС-2 в один блокнот.

11) Скопируйте (поштучно) волюмы башни из ИС-2 в другой блокнот.

12) Переименуйте названия конфликтующих костей и файлов.

13) Откройте Т-34 и на кости «body» создайте логическую прокси-кость «proxy_turret» под башню.

(Перемещая эту прокси-кость кость, вы сможете бесконфликтно перемещать башню.)

14) Скопируйте из первого блокнота ветвь костей башни и вставьте её внутрь прокси-кости башни.

15) Скопируйте все записи волюмов из второго блокнота и вставьте в блок волюмов.

Теперь было бы неплохо вырезать анимации движения ствола и антены с башни ИС-2.

16) Сохраните Т-34 и откройте ИС-2.
17) Откройте соответствующие анимации и экспортируйте кости из них.

18) Откройте Т-34 и импортируйте в каждую соответствующую анимацию ранее экспортированные кости.

19) Переименовывайте конфликтующие названия на ранее принятые новые названия костей
и сохраняйте изменения в файлах.

20) Удалите кость «gun» из анимации выстрела и импортируйте эту кость из ранее экспортированного файла.

Как видно, на башню и её элементы натянулась неправильная текстура. Дело в материале.
PLY-файлы Т-34 и ИС-2 используют файл материала «base.mtl», но у ИС-2 свой «base.mtl».
Такой файл был переименован и скопирован в папку Т-34 под новым именем «base_is2.mtl».

21) Переименуйте материалы в PLY-файлах башни при помощи твикера в редакторе костей.

Теперь нужно настроить EXT- и DEF-файлы.

22) Удалите из EXT-файла Т-34 записи волюмов, удалённых из модели, и скопируйте
вместо них записи волюмов из ext-файла ИС-2, перенесённых в Т-34.

Скорректируйте DEF-файл Т-34.

23) Замените и дополните записи об эффектах стрельбы, названиях подключаемых файлов,
экипаже и визерах, боеприпасах и вооружении, скорости вращения башни.

По итогу получается вполне рабочая колхозная модель.

(Не забывайте о создании X и XX версий моделей.)

Теперь нужно донастроить скрипты и интерфейс.

Иконки:
В папке с дополнительными материалами есть шаблоны для создания иконок:
«_stub_goh_big.xcf» — Шаблон для иконок interface\scene\unit_icon\
«_stub_goh_small.xcf» — Шаблон для иконок interface\scene\unit_icon_small\
Эти шаблоны открываются с помощью GIMP.
У каждого юнита должно быть четыре иконки:

«_00» - Юнит доступен, но не выделен и не выбран;
«_01» - Юнит выделен, но не выбран;
«_02» - Юнит выбран;
«_03» - Юнит недоступен.
Шаблоны для иконок имеют набор слоёв: переключая которые, можно добиваться нужного вида иконки.

Для иконки «_00» нужно включить следующую конфигурацию слоёв:

Для иконки «_01» нужно включить следующую конфигурацию слоёв:

Для иконки «_02» нужно включить следующую конфигурацию слоёв:

Для иконки «_03» нужно включить следующую конфигурацию слоёв:

Есть возможность (граничащая с необходимостью) прописывать иконки через EBM-файл.
(Через ebm, юниту можно прописать иконки и от другого юнита.)
В самом идеальном случае у юнита должны быть и собственные иконки, и EBM-файл:

Миниатюра с моделью повреждений:

Так как эта миниатюра позволяет пользователю быстро ориентироваться в состоянии
юнитов, то игнорировать её крайне не желательно.
Так как я не умею создавать подобные миниатюры, (а точнее — мой метод и софт
рассчитаны на чистый CTA и не совсем применимы к GoH), то:
или учитесь рисовать миниатюры самостоятельно,
или выбирайте из готовых в interface\scene\vehicle_view\,
прописывая в файле set\registry\unit.reg своего мода.

Также нужно подписать название и класс своего юнита.
Для этого по указанному адресу нужно создать собственный pot-файл и сделать в нём пару
соответствующих записей.

Скрипты.
Собственные скрипты юнита обеспечивают как звучание,
так и его дополнительную функциональность.

В самом простом случае можно просто скопировать файл:
set\interaction_entity\tank\tank-specifics.inc из игры к себе в мод, и прописать в
нём свой юнит по аналогии:

Результат может оказаться бессмысленным и беспощадным.

Пример-3: Обстаклы.
Допустим, в процессе настройки орудия настал момент создания обстаклов.

1) Нажмите ПКМ на блоке препятствий и создайте зону по умолчанию.

2) Растяните её.

Это будет обстаклом корпуса, который всегда будет активен.

3) Создайте зону одной раздвижной станины.

Это будет одним из обстаклов станины, активным в развёрнутом состоянии.

Два и более обстаклов не могут иметь одно название, поэтому нужно прописывать тэг «open».

4) Переместите и растяните его.

5) Разверните его так, чтобы он покрывал свою часть станины.

6) Создайте зону для другой раздвижной станины в развёрнутом состоянии и проделайте с ней все те же манипуляции.

7) Создайте зону для раздвижных станин в сложенном состоянии.

В данном случае в выдаче тэга нет смысла, так как обстакл должен называться «close».

8) Переместите и растяните его.

9) Сохраните mdl-файл.

Примечание:
В «{extender "cannon"» в DEF-файле (где-то после блока «{animation») тэги этих обстаклов
должны быть прописаны в соответствующих блоках:
{move {obstacle "close"}} {attack {obstacle "open"}}

Пример-4: Создание простой анимации.
Несмотря на то, что в этой версии программы ещё нет механизмов автоматической
генерации анимации, программа позволяет создавать анимацию в покадровом режиме.

Простое покадровое анимирование двери автомобиля.

1) Выделите дверь автомобиля и скопируйте её матрицу по внутреннюю память программы.

2) Повращайте дверь во всех трёх 2D-окнах, пока не найдёте то, воздействие на которое ведёт
к вращению двери в правильной оси.

3) Вставьте ранее скопированную матрицу обратно.

4) Создайте анимацию через главное меню.

5) Добавьте кость двери в анимацию.

Наша анимация будет длиной в 3 три секунды (90 кадров), воспроизводимые на нормальной скорости 1.0.

6) Создайте 45 кадров через кнопку «Вставить кадр» и включите флажок «Копировать матрицу в следующие кадры».

В первые 30 кадров дверь будет открываться. Следующие 15 кадров — время простоя.
Игровой движок имеет механизм генерации промежуточных кадров.
Ваша задача заключается в последовательном создании нескольких ключевых кадров,
из которых игровой движок построит плавную анимацию.
(Первый кадр трогать запрещено. Он является синхронизационным. Анимировать можно только начиная со второго.)

На 30 кадров можно обойтись всего четырьмя ключевыми кадрами.

7) Создайте ключевые кадры на таймлайне.
(Сначала перемещаете бегунок, потом вращаете в 2D-окне.)

8) Выключите флажок «Копировать матрицу в следующие кадры» и однократно нажмите
кнопку «Вставить инверсию анимации в конец».

9) Проверьте корректность работы анимации.

10) Сохраните эту анимацию в новый файл анимации.

Его путь сразу отобразится под тайм-лайном.

11) Подшейте эту анимацию в главном блоке анимаций и сохраните модель.
(Саму анимацию при этом можно закрыть.)

Пример-5: Добавление новых запчастей.
Этот пример включает в себя использование дополнительных программ: Blender, 3ds Max,
GIMP, а также множества плагинов к ним.

Пример не содержит инструкций по установке и настройке большинства из них,
так как в основном эти инструкции приведены на страницах скачивания.

Пример демонстрирует возможность переноса запчастей от танков из игры «World of Tanks» в «Gates of Hell».
Но вообще можете использовать любой источник контента — хоть сами моделируйте.

Софт:
1) Игра «World of Tanks».
(Скачать можно любым удобным для вас образом.)

2) Blender. (Я использую версию 4.4.)
https://download.blender.org/release/

3) Плагин для импорта «World of Tanks - Map & Vehicle Viewer» от SkepticalFox.
https://bitbucket.org/SkepticalFox/bigworld-blender-tools-wot-wowp-wows/downloads/

Инструкция по установке плагина:
https://koreanrandom.com/forum/topic/28240-blender-tank-viewer-add-on/

4) 3ds Max.
https://vk.com/pages?oid=-41878196&p=3D_Max

(Я использую версию 2016 ради совместимости с некоторыми устаревшими
плагинами. Но не все модели из примеров будут открываться на столь древней версии.
Лучше устанавливайте 2020 или новее.)

5) Плагины для экспорта моделей в игру.
Их можно найти в папках игры: Call to Arms - Gates of Hell\mods\tools\plug-ins
(Выбирайте под вашу разрядность и версию.)
Файлы плагинов "EclipseMtl64.dle" и "GemExport64.dle" нужно скопировать в папку
плагинов 3ds Max: C:\Program Files\Autodesk\3ds Max <*ваша версия*>\plugins
(Перезапустите 3ds Max, если он был включен.)

6) Плагин упрощённого создания коллизии «Convex Hull Generator» от Martin Breidt.
https://mow-portal.com/autodesk_3ds_max/1531-convex-hull-generator.html

Опционально могут пригодиться плагины:
7) Устаревший, но не бесполезный плагин для упрощённой настройки параметров и
названий элементов «MultiScript 3.1.5» от Man232.
https://mow-portal.com/autodesk_3ds_max/1532-multiscript.html

8) Плагин для подсветки сторон волюмов «Check Volume Side» от Man232.
https://mow-portal.com/autodesk_3ds_max/1533-check-volume-side-proverka-storon-voljuma.html

9) GIMP.
https://www.gimp.org/

(Предполагается, что все нужные плагины у вас будут установлены и настроены до того,
как вы начнёте читать инструкцию по переносу контента.)

Вместо «Check Volume Side» в примере используется материал «MoW_Volume_Sides.mat»,
который будет накладываться на волюмы для упрощённой настройки их сторон.
(Этот файл находится в папке с дополнительными материалами к справке.)

Его установка в 3ds Max:
1) Скопируйте файл «MoW_Volume_Sides.mat» из папки с дополнительными материалами в папку:
«Документы/Documents → 3dsMax <*Ваша версия. (Если указанна)*> → materiallibraries»
2) Откройте 3ds Max и перейдите в редактор материалов:

3) Сверните все вкладки в левой части окна и по ПКМ в пустой (нижней) области браузера
вызовите меню, через которое импортируйте указанный материал.

В верхней области браузера появится этот мульти-материал.
Для его применения перетащите его в визуализатор (центральную область окна редактора материалов).

1) Выделите мульти-материал.
2) Выделите объект для нанесения.
3) Нажмите кнопку мприменения.

Пример удобства визуализации сторон коллизии с этим материалом.

(Цвета сторон совпадают с таковыми в SOEdit`е с настройками цветов по умолчанию.)

Перенос контента из «World of Tanks» в 3ds Max на примере башни (+ её коллизии) и траков.
В качестве подопытных будут выступать Т-43 из WoT и Т-34 из GoH.

Инструкция.
1) Откройте боковую панель плагина «WoT Map Viewer» в блендере.
Нажмите кнопку пуска парсинга. Настройте и примените фильтры.
Отобразите нужную вам модель.

2) Выберите лишние элементы и удалите их.
(В примере переносится будут только траки и башня.)

3) Экспортируйте сцену в FBX-файл.

4) Выберите башню. Перейдите во вкладку «Редактирование UV».
Откройте и выпишите перечень используемых текстур.

К сожалению, через FBX не получается корректно переносить геометрию траков,
так как ломается текстурная развёртка.
(Траки, попутно экспортировавшиеся в FBX, в последствии придётся удалить.)

5) Перейдите во вкладку планировки и удалите башню.

6) Экспортируйте сцену в ABC-файл.

7) В боковой панели плагина в графе «Состояние танка» выберите «Бронирование» и нажмите кнопку «Применить».
Это будет основой для будущей коллизии.
(Этим же способом можно доставать и повреждённые версии моделей.)

8) Удалите элементы коллизии от ненужных компонентов.

9) Экспортируйте сцену в FBX-файл.

Теперь нужно найти ранее выписанные текстуры.

10) Перейдите в архивы игры.
Нужные текстуры хранятся где-то в этих архивах:

11) Найдите и извлеките нужные текстуры в папку с ранее экспортированными файлами.

Теперь 3ds Max.

12) Импортируйте файл с моделью башни.

13) Удалите лишние (попутные) элементы.

(Это действие можно пропустить, если заранее очистить файл от хлама.)

14) Импортируйте файл с моделью траков.

15) Удалите лишние (попутные) элементы.

16) Увеличьте масштаб до 3950%.

Далее нужно удалить ненужные вертексы.

17) Конвертируйте траки в «Editable Poly».

18) Включите режим выбора по вертексам.

19) Выберите и удалите обозначенные вертекы по кнопке «Remove».

Дальнейшего экспорта траков в игру в этом примере не будет.
Пример демонстрировал лишь экспорт траков в 3ds Max без поломки развёртки.

Видео с примером устаревшей настройки шасси:
https://www.youtube.com/watch?v=_nQk7RwvpH8
https://rutube.ru/video/f4af9e99e6f77edeed9c772f10d96833/

Видео с примером прикрепления катков к тракам для GoH:
https://www.youtube.com/watch?v=XBN2no8-k9I
https://rutube.ru/video/9041bdd0e92095ad2ef4d4fbdaf798a4/

Пример модели с реализацией шасси под GoH для 3D Max 2016 можно скачать здесь:
https://mow-portal.com/autodesk_3ds_max/1060-sovetskij-srednij-tank-it-3.html

20) Импортируйте файл с моделью коллизии.

21) Удалите явно лишние элементы коллизии (вроде смотровых приборов) и элементы,
чьё удаление не ведёт к нарушению силуэта компонента.

22) Включите обводку граней (для удобства).

Теперь нужно удалить полигоны, которые будут явно негативно влиять на силуэт.
23) Конвертируйте элементы будущей коллизии в «Editable Mesh» или «Editable Poly».

24) Включите режим выбора по полигонам и поштучно (через кнопку CTRL)
выберите полигоны, явно нарушающие общую конвексность, чьё отсутствие не ухудшит силуэт.
(Через ALT выбор можно отменять.)

25) Удалите эти полигоны.

Теперь нужно сгруппировать элементы коллизии по силуэтам.
26) Выберите любой элемент и включите режим «Attach».

27) Выделяя через ЛКМ, объедините элементы в силуэты.

(Перед переходом к элементу для нового силуэта режим «Attach» нужно выключать.
После перехода — включать снова.)

В данном случае получилось два силуэта.

Но так как на одном из силуэтов остались не конвексные, но важные для силуэта полигоны,
то их нужно перенести в другой силуэт.

28) Включите режим выбора по полигонам и поштучно выберите полигоны, нарушающие конвексность силуэта.

29) Отсоедините их при помощи кнопки «Detach» в новый силуэт.

30) Для каждого силуэта, при помощи плагина «Convex Hull Generator» создайте по будущему волюму.

31) Удалите элементы силуэтов — они больше не нужны.

32) Выберите объекты волюмов и перейдите в редактор материалов.

33) В редакторе материалов выберите и перетащите на «рабочий стол»
(центральную область окна редактора материалов) мульти-материал «MoW_Volume_Sides».
После чего по указанной кнопке примените его на ранее выбранных волюмах.

Волюмы окрасятся в идентификатор материала по-умолчанию.

Теперь им нужно задать «стороны» по их толщинам.
В качестве источника толщин можно использовать любые исторически корректные ресурсы.
Но для моделей из WoT можно использовать сайт https://tanks.gg

Обозначения сторон являются лишь конвенцией для упрощения настройки и отладки.
Технически вы можете их не придерживаться.

«Стороны» являются лишь идентификаторами толщин от 0 до 5 включительно,
и вам придётся ориентироваться на их количество, аппроксимируя толщины или мельче
нарезая слишком сложные волюмы с большим количеством толщин.

Кстати, технически файлы волюмов могут хранить 256 идентификаторов «сторон», но используются всего 6.

34) Конвертируйте волюмы в «Editable Mesh» и включите режим выбора по полигонам.

35) Нанесите «стороны» через прописывание идентификатора, группируя их по толщинам.

Вообще, коллизию можно делать и на основе упрощённой визуальной модели.
Для этого нужно клонировать визуальный элемент и ободрать с него всё, что не является
физически значимым при столкновении.

Теперь нужно настроить материал для визуальной модели башни.
36) Выберите визуальную модель башни и откройте редактор материалов.

37) Возьмите стандартный материал и добавьте в него соответствующие текстуры.
(Можно обойтись и без EclipseMtl. Прозрачность, если нужно, в MTL-файле можно прописать и через блокнот.)

(Вообще, желательно прописывать материалам осмысленные названия, а не *Material #27*.)

38) Активируйте и примените материал.

39) Создайте базовую кость.
Это можно сделать или через «MultiScript».

Или вручную, создав Dummy-объект.

Прописав ему имя «basis» и свойства по-умолчанию, вроде таких:

Type=Game_Entity
Model=blahblahblah
WheelRadius=0.58

(Последняя строка в окне параметров всегда должна оставаться пустой.)
(Вместо blahblahblah можете прописать своё название для экспортируемой модели.)

Теперь нужно задать названия и параметры визуальной модели и волюмам.

40) Выберите визуальную модель башни и либо задайте ей название и параметры нажатием
соответствующей кнопки в «MultiScript».

Либо пропишите их вручную.

Poly
ID=turret

41) Поштучно выбирая волюмы, либо задавайте им названия и параметры нажатием
соответствующей кнопки в «MultiScript».

Либо пропишите их вручную.
(После названия волюмы должны иметь суффикс «_vol».)

Volume

42) Перетащите элементы геометрии в базовую кость.

43) Экспортируйте сцену в MDL-файл.
В окне экспорта самого 3ds Max можете прописывать любое название файла.
MDL- и DEF-файлы будут иметь то название, которое указанно в базовой кости.
Генеральный путь экспорта нужно прописать в самом плагине.

(Перед экспортом сохраните резервную копию сцены в файл самого 3D Max.)

Экспортируется примерно следующее:

44) Конвертируйте BMP-файл нормалей в DDS и пропишите префиксы файлам геометрии
для избежания файловых конфликтов в дальнейшем.

Дальнейшее является частичным повтором примеров № 1 и 2.

45) Скопируйте экспортированные файлы геометрии, текстур и материалов в модель, которую собираетесь колхозить.

46) Откройте модель Т-34. Удалите мэш и волюмы башни.

47) Добавьте новую экспортированную визуальную кость башни «t-43_turret» (выбранную из файла)
в кость «turret», которая теперь является логической.

48) Пропишите (скопируйте) в её параметры строку «id=turret;».

49) Сориентируйте и спозиционируйте её.

50) Скопируйте её матрицу во внутреннюю память программы.

51) Добавьте в кость «turret» экспортированные волюмы «t-43_turret1.vol», «t-43_turret2.vol» и
«t-43_turret3.vol» из файлов.

Удаляйте им префиксы из названий и вставляйте матрицы в процессе.

52) На кости «turret» создайте логическую прокси-кость «proxy_gun_rot».

53) Вырежьте кость механизма горизонтального наведения «gun_rot» и вставьте её в кость «proxy_gun_rot».

54) Спозиционируйте кость «proxy_gun_rot» под новую башню.

55) В EXT-файле перепишите параметры бронирования под новые волюмы.

Осталось только донастроить текстуры.

56) Измените цветовую схему спекулярной текстуры на градацию серого и поиграйтесь
с яркостью и контрастностью, чтобы сколы и потёртости краски начали блестеть.

57) Перенесите альфа-канал из изначального файла нормали «_ANM» в текущую Diffuse-текстуру.
(Альфа-канал нужно создавать из зелёного канала «_ANM».
При этом должен присутствовать красный канал.)

Подробнее смотри в видео:
https://www.youtube.com/watch?v=yvdiRsdTBJc
https://rutube.ru/video/4353625bfed59ad93a53d1fd08985057/

В общем и целом — шараж-монтаж на этом завершен.

Примечание по примерам:
После добавления/перемещения/удаления файлов и папок — игру нужно перезапускать.

Контроль и тестирование моделей.

Работа над моделью не заканчивается на кнопке экспорта или сохранения.
Как после первоначальной настройки, так и после внесения в неё изменений,
модель нужно проверять и тестировать корректность её работы.

Общий алгоритм проверки:
1) Проверьте корректность отображения текстур на всех версиях модели.
1.1) Не должно быть никакой съехавшей развёртки.

Если такое есть, то проверяйте наличие нужных текстур и правильность настройки путей текстур.

1.2) Не должно быть «шахматных» текстур.

Если такое есть, то проверяйте наличие нужных текстур, правильность настройки их путей и внутренний формат.

1.3) Не должно быть текстур с предупреждением о DDS DXT-кодировке не кратной 4.

Если такое есть, то стандартизируйте разрешение текстур до ближайшего значения степени 2.

1.4) Не должно быть текстур позволяющих смотреть сквозь геометрию модели в непредусмотренных для этого местах.

Если такое есть, то в мэше просвечивающей кости включите флаг «TWO SIDED».

1.5) Не должно быть проблем с отображением альфа-канала.

Если такое есть, то проверяйте наличие альфа-канала в самих текстурах, а также настройки
смешивания материалов, через которые отображаются эти текстуры.

1.6) Не должно быть вывернутых наизнанку текстур.

Если такое есть, то ищите проблему (инверсию) в матрицах и решайте её (возможно с переделкой скелета)
и/или применяйте «TWO SIDED» (как вариант).

1.7) Не должно быть BUMP-материалов с BUMP-текстурами, накладываемыми на мэши без BUMP-секции данных.
Это ведёт к ошибке Vertex Shader [VS] from [vs] compile error:
***G:\SteamLibrary\steamapps\common\Call to Arms - Gates of Hell\vs(76,14-51): warning
X3206: 'mul': implicit truncation of vector type
G:\SteamLibrary\steamapps\common\Call to Arms - Gates of Hell\vs(77,14-51): warning X3206:
'mul': implicit truncation of vector type
G:\SteamLibrary\steamapps\common\Call to Arms - Gates of Hell\vs(81,18-28): error X3018:
invalid subscript 'tangent'
И к вылету игры без окна ошибки.

Более того:
В GoH даже спекулярные текстуры не работают без BUMP-секции данных в PLY-файлах.

Для исправления этой проблемы нужно либо переэкспортировать PLY с BUMP-текстурой,
либо воспользоваться утилитой «PlyBumpCalculato.exe» от 1Lt. Muhammad.
(Есть в папке с дополнительными материалами к справке.)

Утилита немного глючная и может уничтожить, а не исправить ваши PLY.
(Делайте бэкапы.)

2) Проверьте корректность работы волюмов и физики.
2.1) Проверьте отображение волюмов в редакторе, переключая режимы отображения
объёмов по Alt+C / Alt+V.
Компонентные волюмы должны быть зелёными.

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

2.2) Ощупайте модель курсором.
У всех поверхностей всех волюмов должны быть правильные показания толщин.

Если толщины неправильные, то проверьте правильность указания сторон волюмов
и толщин на этих сторонах. Если стороны и указанные на них толщины правильны,
но в игре значения не верны, то возможно, этому волюму значения прописаны где-то ещё.

2.3) Протестируйте корректность построения карты высот по Alt+H.
Покрутите модель: карта высот должна строиться корректно при любом наклоне или перевороте модели.

Если поверхность карты высот сильно не совпадает с геометрией волюмов,
то это явный признак физического брака какого-либо волюма.

(Пример с недопустимым, прямым конвертированием «сырого» мэша в волюм.)

2.4) Поднимите модель над поверхностью земли и уроните на Alt+K.
2.5) Киньте в модель несколько противотанковых гранат с разных сторон.
(Плеер в самом редакторе должен быть больше или равен нулю.)

2.6) Врежьтесь в модель на большой скорости на технике, которая может толкнуть но не разрушить эту модель.

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

Пример:
https://www.youtube.com/watch?v=xZUUTB7CsjM
https://rutube.ru/video/private/84e6a183e30fb4ca08508240faad3601/?p=lGWOeCO9srrLIwyJkd65Og

2.7) Взорвите модель.
Так как разработчики игры закрысили консольную команду «g_effect» для нефуловой
версии редактора, то можете использовать триггерную команду Entity → Effect.
(Пропишите вашей модели какой-нибудь тэг. Создайте какой-нибудь триггер с командой
«Effect». В селекторе команды пропишите тэг модели, а в графе эффекта команду «explosion».
Примените команду и запустите симуляцию.)

Проследите за корректностью физики разлёта и падения частей.

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

2.8) Протестируйте корректность прикрепления волюмов к своим компонентам.
Погоняйте модель — можете устроить небольшое сражение этих моделей между собой.

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

3) Проверьте корректность построения и проецирования обстаклов по Alt+A.
3.1) Проверьте, не мещают ли обстаклы посадке экипажа.

Если геометрия обстаклов мешает посадке экипажа, то её придётся переделать или создать с нуля.

3.2) Понаклоняйте модель в разные стороны.
Проекция должна корректно перестраиваться под силуэт модели.

Если обстаклы проецируются явно не верно, то изучайте прямоту цепи матриц пивотной
кости и корректность геометрии самих обстаклов.

Пример:
https://www.youtube.com/watch?v=ryq-_QDBASk
https://rutube.ru/video/75e55d7876121e5d34bd9c7faed7d6f2/

4) Протестируйте анимации через окно «Call function», вызываемое по кнопке «U».
4.1) Проконтролируйте наличие и работу всех базовых анимаций.

(*Анимации компонентов не должны располагаться в главном блоке анимаций.)

4.2) Проконтролируйте наличие и работу всех анимаций компонентов.

(Не X-версия модели.)

(X-версия модели.)

(*Подчёркнутые названия анимаций repair/break и костей нужно прописывать вручную.)

Если после срабатывания анимации какой-либо мэш начинает ненормально
деформироваться, то стоит отключить или переделать эту анимацию.

5) Протестируйте работу компонентов.
5.1) Поломайте компоненты через команду «g_component».
(Выберите модель. Введите в консоль команду g_component break "название компонента" Нажмите Enter.)

5.2) Почините компонент при помощи бойца-ремонтика.

Следите за срабатыванием собственных анимаций компонентов.

Если срабатывает анимация чужого компонента, то проверяйте линковку волюмов компонента.
Если боец не может починить сломанный компонент, то проверяйте наличие
и доступность волюмов этого компонента для бойца.

5.3) Проверяйте, подменяется ли визуальное представление компонентов в процессе их повреждения/восстановления.

Если подмены нет, то проверяйте корректность и наследуемость между моделями идентификаторов костей.

5.4) Отслеживайте проблемы скинования в процессе всевозможных повреждений/ремонтов/разрушений/отрывов компонентов модели.

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

(*В старых играх серии подобные сопли встречались и при невозможности
задействования BUMP-текстуры. Помогало её удаление из файла материала.)

6) Протестируйте корректность мест посадки/высадки экипажа и десанта.
6.1) Посадите в технику отряд бойцов.
Проверяйте наличие и корректность анимаций бойцов.

Если бойцы отказываются использовать какие-либо точки посадки/высадки, то проверяйте
возможность их использования макросами экипажа, наличие и физическую доступность для бойцов.

Если точки посадки/высадки расположения бойцов расположены некорректно, то исправьте их расположение.

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

Игра крайне не любит места посадки, которые используют лишь частично пересекающиеся «emit»`ы.
То есть: если «место1» использует «emit1», а «место2» использует «emit1» и «emit2», то это
чревато тем, что «место1» начнёт задействовать «emit2». Будьте внимательнее с макросами.

Если какие-либо бойцы садятся/высаживаются без анимации или зависают в воздухе,
то проверьте наличие записи об этой анимации
в файле \properties\animation\human\_reg_vehicle_crew.inc
и фактическое наличие этой анимации в папках \properties\animation\human\

Возможно, в названии анимации была допущена банальная опечатка.

Возможно, вы сможете где-нибудь найти и перенести эти файлы анимаций к себе в
соответствующую папку мода и сделать соответствующие записи в перенесённом
к себе в мод файле \properties\animation\human\_reg_vehicle_crew.inc

Или вам придётся заменить отсутствующие анимации на какие-нибудь другие
(с соответствующей корректировкой мест посадки экипажа).

Анимации и позы бойцов для конкретной модели можно делать в 3D Max,
импортируя модель техники через «Merge» к заранее открытому примеру бойца с
анимациями из примера «T2_export.max».
Как делать анимации и прописывать её заголовки в базисе — сами найдёте на ютубе.

6.2) Протестируйте позиции и ориентации мест креплений прицепов, если таковые предусмотрены.

7) Протестируйте кинематику и движение модели.
(Посадите в технику экипаж и поиграйте за эту модель.)

7.1) Контролируйте в процессе скорость и лимиты движения кинематических костей.
При необходимости скорректируйте их.

7.2) Если модель имеет траки, то контролируйте скорость и направление их движения.

Если траки синхронно движутся в противоположную сторону, то инвертируйте
(умножите на -1) значение параметра «len» в трассовом макросе в блоке шасси.

Если траки синхронно и правильно движутся при движении вперёд-назад,
но при развороте на месте начинают двигаться в неправильную сторону то, вероятно, они перепутаны местами.

Если траки двигаются правильно, но с неправильной скоростью, то отрегулируйте значение
параметра «len». (Чем ближе к нулю, тем быстрее.)

8) Протестируйте визоы модели.
(Включите туман войны на Alt+F и повращайте башню, если таковая есть.)

Визоры должны смотреть в правильные стороны, принадлежать правильным членам
экипажа и поворачиваться вместе с компонентами, к которым принадлежат.

9) Протестируйте стрельбу и эффекты модели.
9.1) Постреляйте из всех орудий и пулемётов на разные дистанции.

Если стрельба ведётся не в ту сторону, куда целится вооружение, то проверяйте
задействованные «Foresight»`ы, их ориентацию и лимиты кинематики механизма наведения.

Если орудие не может навестись на максимальную дистанцию стрельбы,
то проверяйте лимиты кинематики механизма наведения.
Рассмотрите вариант с добавлением кинематики самой «Foresight»-кости.

Если многоствольное оружие стреляет не изо всех стволов, то проверяйте указанный «shooter»,
его нумерацию в модели
(нужно shooter00 shooter01, а не shooter00 shooter02), и указанное в «barrels» количество стволов.

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

Если эффекты отсутствуют или расположены некорректно, то добавьте/исправьте их местоположение.

(*Помните, что для работы некоторых эффектов и анимаций требуется либо подключить
скрипты интеракций через «props», либо создать собственные скрипты модели.)

Иногда посматривайте файлы логов по адресу:
C:\Users\[ИМЯ ВАШЕГО ПОЛЬЗОВАТЕЛЯ]\Documents\my games\gates of hell\log

Эпилог.

Ваша (как мододела) первоочередная задача — СТРАДАТЬ БЛ#ТЬ!!!

«Страдание» в моддинге — это не выбор, а необходимость, являющаяся неотъемлемой частью обучения.
В моддинге на движках GEM# — этот процесс непрерывен.
Преодолевая циклы всё новых и новых проблемы, мододел становится опытнее.
Каждая итерация этого цикла постепенно учит мододела вырабатывать методы решения
проблем, позволяющие модить более эффективно.

Так что стоит полюбить «страдание», преодолевая лень и постигая все садистке прелести обучения на ошибках.
Также. Во многом, благодаря «страданиям» (вложенным моральным и временным ресурсам)
— получаемый результат становится более ценным.

Когда мододел только приходит в моддинг, то он может столкнуться с некоторыми недостатками в игре.
Это может вводить в замешательство.

Когда мододел осваивает базовый уровень моддинга, то он заметит в игре много сложно-решаемых
задач и проблемами. Это может злить или демотивировать.

Когда мододел становится опытным, то начинает подозревать, что игра и её движок почти во всех местах
имеют какие-то проблемы. Это может откровенно фрустрировать.

Когда мододел осваивает всё, что поддаётся изменению (и хотя бы частично изучает
устройство игрового движка), то осознаёт, что и игра и её движок — это просто удачная
последовательность глюков и багов; временных решений, сделанных разными
разработчиками в разное время «на скорую руку»; устаревших и не вполне рабочих легаси
(в которых до конца не разбирается никто из разработчиков игры);

Тогда мододел получает новое, навсегда умиротворённое лицо, абсолютное душевное спокойствие
при любых неприятностях, статус «ГУРУ» в моддинге и стиль пьяного мастера.

(Работать предстоит на корявом движке с корявым контентом, который был сделан по корявой
и не совсем актуальной документации.)

Исключительно и только ради идеологической совместимости с игрой, SOEdit также сделан только
из удачной последовательности глюков и багов.
(Сначала пьяный мастер боится дела, а потом дело боится пьяного мастера.)

Благодарности и источники.

Спасибо:
Brian A. Kay — За первоначальную версию «SOEdit».
Jdoo — За справочные материалы, идеи и прочую поддержку.
Dgn — За справочные материалы и помощь с переводом.
GhostNT — За некоторую помощь в создании программы.
Man232 — За некоторую помощь в создании программы, справочные материалы, множество плагинов его разработки
и прочую поддержку.
1Lt. Muhammad — За утилиту «PlyBumpCalculator».
Michael 'Cromtec' Stenzel — За справочные материалы.
SkepticalFox — За плагин «World of Tanks - Map & Vehicle Viewer».
https://bitbucket.org/SkepticalFox/bigworld-blender-tools-wot-wowp-wows/downloads/
Martin Breidt — За плагин «Convex Hull Generator».
Flanker — За руководство по созданию X и XX текстур.
Ghosteron — За прочую поддержку.
Владимиру Молчаливому — За прочую поддержку.
Frostyy — За идею с кнопками «Q/E» для 3D-камеры.
Пользователям ныне не существующей BestWay wiki — За справочные материалы.
Пользователям форума Боевой народ — За справочные материалы.
Сотрудникам Best Way — За справочные материалы.
Пользователям ВК-чата «GEM Editor | GEM Modding | 3D Modding» — За рецензии.
https://vk.me/join/3eqpIxF5b5ko6UABXjC1iu/ow7CwaicNSX8=
Настройщикам многочисленных моделей, приводимых на скриншотах.

Источники:
Gem RTS v1. Документация.
https://docs.bestway.com.ua/gem-rts-v1-ru

ModDB.
https://www.moddb.com/games/men-of-war-assault-squad/tutorials

Men of War Editor | 3D Max | 3D Modding.
https://vk.com/3d_max_mow

Форум боевого народа.
http://боевой-народ.рф/

Руководство по созданию X и XX текстур
http://phglobal.my1.ru/forum/14-166-95

Источник утилиты «PlyBumpCalculator» на дискорд-сервере «GEM Modding Community».
https://discord.gg/FHC2pUqv

Источник этого документа, программы и множества плагинов.
https://mow-portal.com/

Дополнительно:
С.Устьянцев, Д. Колмаков: «Боевые машины Уралвагонзавода - Танк Т-34».
Максим Викторович КОЛОМИЕЦ, Илья Борисович МОЩАНСКИЙ: «Трофеи в Красной армии. 1941-1945»

Собери свои семь смертных грехов и пять стадий принятия вместе с SOEdit!

Дополнительные материалы к справке:
https://disk.yandex.ru/d/F5jHzNSzXqUf2g

[TF6]

Комментарии

Без политики и матов. Комментарии проходят модерацию.

TonaTor [Администратор]

6 июля 2026 16:10

1 0

Jdoo, Man232, если есть что добавить, то пишите прямо сюда, в комменты.

Ссылка на сам SOEdit:

https://mow-portal.com/blogs/blog_tonator/1101-soedit-version-next-v07m5.html

Ответить

Цитировать
Soblazer [Разработчик]

6 июля 2026 14:25

1 0

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

Ответить

Цитировать
Soblazer [Разработчик]

6 июля 2026 14:19

1 0

Многа букав, не осилил.

Ответить

Цитировать

Похожие моды