Вчера случилось то чего мы ждали давно... СА расщедрились и дали страждущим мододелам инструменты для моддинга Total War: Shogun 2 - Assembly Kit. А сегодня мы начинаем публиковать перевод инструкции по работе с этим набором. Читайте и создавайте моды!
Как создать мод к Total War: Shogun 2 при помощи Набора Инструментов - Assembly Kit (инструкция)
1. Установка
В Стиме Library-> Tools-> Total War Shogun 2 – Assembly Kit
ПКМ и выбираем «Install Game»
После завершения загрузки выбираем «Play Game». Откроется папка, содержащая файл «modding.zip».
Распаковываем в C:\Official_Mod_Tools. Если распаковать в другое место,то возможны проблемы, связанные со слишком длинным именем файла. Не используйте пробелы в названии папки.
2. Обзор инструментов
Инструменты находятся в папке "binaries".
Есть папка "raw_data", содержащая хml файлы. В raw_data/db вы найдете те, которые касаются основных данных. Если вы применяете database editor и откроете указанные файлы, то увидите, что изменения вами сделанные вступили в силу.
Подпапка raw_data/BattleTerrain содержит шаблоны тактических карт местности. Структура того, как tga каждого шаблона работает и взаимодействует с другими пока не ясна.
raw_data/art содержит рисунки.
raw_data/Localization – поддержка других языков.
max_exporter содержит скрипты для 3Dmax,которые экспортируются в нужный игре формат.
В working_data лежит весь материал, вами созданный и экспортировали в binary (т.е. формат, который юзает игра, примерно так же, как делали в моддинге до этого).
Папка "retail" не существует сразу после установки; она появляется на завершающей стадии создания мода.
3. Сущность инструментов
TWeak
Запускаете TWeak, из меню Tools выбираете "DAVE - Database Visual Editor".
Спросит, соединиться ли с raw_data/db, жмите "yes".
В меню "View", выберите "Table Launcher". Откроется список доступных db таблиц.
Открытие – двойной левый щелчок.
Делайте то, что нужно; по завершении кликните "Apply" в окне редактирования.
BOB
Теперь надо вставить изменения в pack файл.
Из папки binaries, запустите BOB.Release.exe.
В списке слева раздвиньте дерево "database" и выберите таблицу ,которую редактировали.
В списке в центре найдите таблицу снова (под "db") и выделите ее. Выберите и Provider и Consumer действия; Provider конвертирует xml в binary, а Consumer засунет binary в pack.
В списке справа под data, выберите "mod.pack".
Справа внизу нажмите "Start". Откроется итоговое окно с сообщениями о происходящем. Даже если все прошло хорошо будет предостережение об операции Create Pack; это вызвано тем, что вы правили только подраздел возможного файла, так что программа говорит, что остальные не затронуты... не волнуйтесь насчет этого.
Глянем на папку retail; она должна содержать папку "data" с вашим "mod.pack".
Скопируйте ее в вашу папку shogun2/data и мод запуститься при следующем запуске Сегун 2.
4. Управление модами: выбор и загрузка на Workshop
При запуске Сегун 2 из Стим, сначала откроется ModManager со списком модов, помещенных вами в папку data. Выберите нужный.
Если двойным щелчком кликнуть по моду, появится дополнительное окно позволяющее изменить название и описание мода. Сделав это можете жать "Upload to Workshop", и ваш мод залит. Нужно сделать его Видимым (Visible) из Workshop если вы желаете, чтобы другие юзеры могли играть в него.
Шаблоны армий в кампании
Эти таблицы позволяют определять, какие армии и флоты ИИ будет создавать и как он будет оценивать юнитов с точки зрения перспективы их рекррутирования.
Таблицы, контролирующие этот процесс:
Как это работает.
В таблице start_pos_factions фракции привязаны к balance_config и quality_config
• balance_config определяет, какой шаблон армии\флота будет использоваться
• quality_config определяет ценность юнитов для этой фракции
Возможность устанавливать разные конфигурации для разных фракций позволяет контролировать состав их армий.
• cdir_unit_qualities определяет качество юнитов в разных quality_configs и привязывает этих юнитов к quality_group из cdir_unit_quality_groups. Значения качества юнитов относительно других юнитов задаются в quality_group, не против всех юнитов.
• cdir_unit_balance_group_qualities связывает cdir_unit_quality_groups в группу cdir_unit_balance_groups для разных cdir_unit_balance_configs и позволяет quality_groups быть организованной с точки зрения качества в каждом balance_group. Аналогично для таблиц cdir_Unit_qualities значения в поле «quality» для каждого quality_group_key измеряются относительно других, привязанных к тому же самому group_key в рамках config_key
• cdir_unit_balance_templates содержит список всех шаблонов армий/флотов
• cdir_unit_balance_template_junctions связывает шаблоны с cdir_unit_balance_configs и задает приоритет для каждого шаблона в рамках того config.
• cdir_unit_balances устанавливает сами шаблоны, связывая каждый шаблон с разными balance_groups, заадвая идеальный процент каждого balance_group в шаблоне и min/max количество юнитов, доступных для каждого шаблона.
Баланс
Эта таблица, возможно, наиболее значима во всей системе. Она контролирует какой тип юнитов и в каком количестве входит в каждый балансовый шаблон.
Для каждого шаблона можно добавлять неограниченное количество групп (хотя, общий ideal_pct должен соответствовать 1). Группы, взятые из таблиц cdir_unit_balance_groups (которые связывают их с группами, используемыми вcdir_unit_qualities) и для каждой группы вы можете определить процентное соотношение , насколько тот pct можете варьировать и необходимо ли минимальное значение.
Связь балансовых шаблонов (Balance template)
Эта таблица увязывает балансовые шаблоны с балансовыми конфигурациями и задает приоритет. Есть много различных balance_templates, некоторые из которых с отрицательными приоритетами.
Большое количество шаблонов необходимо для того, чтобы приспособить различные особенности рекрутирования юнитов фракций (например, все додзе разрушены и фракция может рекрутировать только из замков).
Негативные значения используются для того, чтобы сообщить ИИ, что они не идеальны. ИИ проверит, можно ли его заменить шаблоном с большим приоритетом, если да – то воспользуется им. Если нет – то будет применять негативный.
Групповые построения
Следующие построения жестко прописаны в коде, поэтому не удаляйте их. Некоторые построения могут быть использованы игроком при создании группы, другие используются ИИ в определенных типах сражений:
• Multiple Selection Drag Out Land
• Spear Point
• Crane’s Wing
• Flying Geese
• Reclining Dragon
• War of the Tiger
• Bark of the Pine Tree
• Cloud Dragon
• Flying Bird
• Double Line Standard
• Grand Battery
• Cavalry Heavy Right
• Cavalry Heavy Left
• Melee Frontline
• Artillery Crossfire
• Siege Approach Column
• Siege Approach Line
• Ambush Column
• War of the sword
• Bird cloud
• Three day-old moon
• Extended snake
• Boshin Line Astern
• Boshin Line Abreast
• Multiple Selection Naval
Редактор
Рекомендуется Notepad++ или другой xml редактор для обнаружения ошибок во вносимых правках.
Как работают построения
Для примера рассмотрим Double Line Standard. Она выглядит так
В верхней части такие строки:
Приоритете (Priority) – одно значение, помогающее ИИ решить, какое построение использовать. Можно использовать это для создания разных построений для игрока и для ИИ, делая одни доступными только для игрока (AI priority 0.0) и другие для ИИ с большими значениями.
AIPurpose позволяет задавать, какие построения используются при атаке ИИ, какие при обоорне, какие – в обоих случаях, а также используется ли построения для размещения.
Есть дополнительные строки, которые могут быть добавлены после AI строк для помощи ИИ в выборе.
•
Тэги Min и MaxUnitCategoryPercentage могут быть применены для ограничения % юнитов определенного типа, при наличии которого эта формация будет применена ИИ.
Переходим к блокам.
Они выглядят следующим образом
•
•
•
•
•
•
Каждый блок дает преимущества; это помогает ИИ распределять юнитов по блокам построения.
Кроме блока 0, остальные располагаются относительно друг друга (Блок 0 – ContainerAbsolute, все остальные ContainerRelative). Они располагаются по координатам х и у. Так, например, в построении Double Line Standard блоки 0,1 и 2 позиционируются так:
Юниты в блоке могут быть построены в линию или колонну посредством тэга EntityArrangement для каждого блока.
В рамках блока могут быть разные строки, определяющие какие классы юнитов размещать в нем и приоритет для каждого класса юнитов. Сочетание в блоке приритетов класса юнитов, приоритета разных блоков и AIPriority для всего построения влияет на выбор построения ИИ в сражении.
Убедитесь, что в построении есть как минимум один блок, содержащий запись для EntityDescription=”any”. Так чтобы юниты, полностью не подходящие под критерии других блоков были все-таки размещены. Если этого не будет, ИИ проигнорирует построение.
Помните, ИИ не всегда имеет идеальную армию для большинства построений, поэтому желательно заложить немного гибкости «про запас».
Несколько блоков могут быть сгруппированы вместе в стянутый блок, как показано ниже:
•
•
• 0
• 1
• 2
•
•
Прочие блоки могут быть затем позиционированы относительно стянутого блока, что упростит организацию сложных построений.
Создание Групповых Построений
В ВОВ кликните по Groupformations.pack в working_data и обработка файла запустится.
Тестирование построений в игре.
Простой способ проверить новое построение, добавленное или модифицируемое вами это задать AIPriority всем другим построениям 0.0 (сделайте перед этим резервную копию. Загрузить игру и затем в кастом битве выбрать армию, которая идеально соответствует этому построению.
Возможные проблемы
• Пропущенные скобки, при ручном редактировании случается часто и где Notepad++ особенно эффективен в их выявлении;
• Блоки не по порядку или номер(а) пропущен(ы). Блоки должны начинаться с 0 и далее по порядку.
• В игре юниты располагаются поверх друг друга. Это возможно, если они не расположены в блоке или блоки расположены недостаточно далеко друг от друга по осям х и у.
• Помните, если у ИИ не идеальная армия для построения он попытается заполнить ее наилучшим образом, делайте блоки вашего построения достаточно гибкими, чтобы юниты не были размещены странным образом, если определенные блоки не заполнены.
Структура частей юнитов (пока работает не корректно - вылетает)
Модели и части
На этом уровне иерархии можете использовать любой пункт и уровень информ поддиректорий путем добавления префикса «_». Это полезно для лучшего структурирования частей при работе с ними и при использовании совместных текстур (см.ниже).
Пример.
Asian/ (любая папка schema)
_Heads/
_Indian/
Heads/
Parts – в редакторе они не отличимы от parts из Asian/Heads/
_Chinese/
Heads/
Parts - в редакторе они не отличимы от parts из Asian/Heads/
_ChineseArmours/
Torsos/
Parts - в редакторе они не отличимы от parts из Asian/ Torsos/
Legs/
Parts - в редакторе они не отличимы от parts из Asian/ Legs/
Heads/
Parts
Hats/
Parts
...
Parts
Hats/ (любая папка)
AustrianBearSkin/
Meshes and textures
BelgicShako/
Meshes and textures
...
Меши и текстуры
Допустим есть один меш и один набор текстур.
AustrianBearSkin/
mesh.variant_part_mesh
texture_diffuse.dds
texture_normal.dds
texture_gloss_map.dds
Опционально вы можете группировать эти файлы в подпапки типа этой (с любым именем):
AustrianBearSkin/
WhateverMeshFolder/
mesh.variant_part_mesh
WhateverTextureFolder/
texture_*.dds
or:
AustrianBearSkin/
mesh.variant_part_mesh
WhateverTextureFolder/
texture_*.dds
or:
AustrianBearSkin/
WhateverMeshFolder/
mesh.variant_part_mesh
texture_*.dds
Единственная вещь, которую нельзя менять – это название шаблона файла.
В редакторе, название части будет названием корневой папки. То есть AustrianBearSkin в этих случаях
Случайные текстуры.
Вы можете добавить несколько текстур. Для частей они будут выбираться случайно.
Нормальные случайные текстуры.
texture[01]_*.dds texture[02]_*.dds texture[03]_*.dds ...
В этом случае, движок не смешивает текстуры с разными индексами,
texture[01]_diffuse.dds всегда используется с texture[01]_normal.dds и texture[01]_gloss_map.dds.
То же справедливо и для размещения их в основной папке или опциональной подпапке:
AustrianBearSkin/
texture[*]_*.dds
или
AustrianBearSkin/
WhateverTextureFolder/
texture[*]_*.dds
Чередующиеся случайные текстуры
WhateverTextureFolder_i/
texture[01]_*.dds
texture[02]_*.dds
texture[03]_*.dds
...
В этом случае движок смешает диффузную, нормальную и глянцевую (gloss) текстуры в любой комбинации случайно..
Чередующиеся текстуры всегда должны храниться в подпапке, поскольку название папки модержит информацию о чередовании.
Совместно используемые меши и текстуры
Вы можете добавить более одной папки с текстурами и мешами в папке частей. Тогда каждая комбинация папок меша и текстуры будет добавлена как отдельная часть в редакторе.
Пример.
Heads/
Fat/
A/
Texture set #1
B/
Texture set #2
C/
Texture set #3
X/
Mesh #1
Y/
Mesh #2
В этом случае следующие части будут доступны в редакторе:
• Fat_X_A
• Fat_X_B
• Fat_X_C
• Fat_Y_A
• Fat_Y_B
• Fat_Y_C
Подпапки могут быть названы как угодно.
Набор текстур может содержать несколько текстур (texture[*]_*.dds) для случайного использования и называя папку тем же именем отсылает к наборам заменяемым тестур, как было описано выше.
Если используете один меш и одну текстуру, тогда
• Нельзя хранить файлы в подпапке, но вы можете поместить их в Fat/ если хотите (кроме чередующихся текстур, конечно)
• Названия частей в редакторе будут Fat_A, Fat_B, Fat_C or Fat_X, Fat_Y
Совместно используемые текстуры между слотами
Если желаете использовать одни и теже текстуры для частей разных типов следуйте инструкции:
Euro (любая папка schema)
_NakedParts/
texture*.dds
Heads/
Fat/
Mesh
Angry/
Mesh
Hands/
Fat/
Mesh
Slim/
Mesh
Heads/
...
Hands/
...
Что нужно знать об этом:
• См. главу «Слоты» для большей информации о папках, начинающихся на «_»
• Меши частей в _NakedParts/ совместно используются , учитывая, что нет текстур в слот папке в _NakedParts/. Если добавите текстуры к одной из частей, эта определенная часть не будет использовать совместно текстуры, но будет применять те, что вы добавили туда.
• Для файлов текстур процедура та же: можете помместить их в подпапку и можете создать несколько папок текстур и можете применять «_» для совместноиспользуемых.
• Есть опция, позволяющая заставить движок выбрать ту же случайную текстуру для одного слота или для другого, добавив «_» суффикс к названию папки текстур. Это очень удобно в этом конкретном примере, поскольку мы хотим, чтобы цвет кожи головы и рук был одинаков.
Пример.
_NakedParts/
XYZ_s/
Textures
Heads/
...
Hands/
...
Продолжение следует...