Total war attila как изменить характеристики юнитов

Я не нашёл туториала на русском по тому, как добавлять новых юнитов.
Есть английский туториал:
]]>
http://www.twcenter….m-unit-with-PFM
]]>

И я решил его частично перевести, частично добавить от себя.
Допустим, вы хотите добавить юнита в уже существующий мод.
Начнём:

1. Что нам понадобиться.

2. Допустим, мы хотим добавить серпоносную колесницу к юнит-паку для Этрусской лиги.
Unit_variants.
Первым делом открываем программой PFM нужный юнит-пак и «data_rome2.pack», в группе «db» находим таблицу «unit_variants».
В «data_rome2.pack» видим вертикальную строку «unit», щёлкаем по стрелочке и в открывшемся списке ищем юнита, который больше и лучше всего по-характеристикам и всем другим параметрам подходит для того юнита, которого хотите создать вы. Для меня это Gre_Scythed_Chariots — Серпоносная колесница. (Чтобы узнать имя юнита по ключю, нужно заглянуть в русик, об этом в конце).
Соответственно щёлкая по Gre_Scythed_Chariots этот юнит отсеивается и остаётся единственным в таблице.
Следующим шагом открываем юнит-пак, заходим в таблицу «unit_variants и unit_card» и щёлкаем по «Add Row», добавляется строка. И мы просто копируем написанное в строчках «unit, height_variation и height_scale» из «data_rome2.pack» в юнит-пак. Далее, в строках «name, variant» пишем новое название юнита — ключ (Любое, но на англ). Например можно прописать «Rom_Chariot» или «Athens_Chariot», но у меня это будет «Etr_Chariot».
А в строке «faction» нужно указать принадлежность юнита к фракции, ведь мы заимствуем его из ванилы. К примеру, я добавляю юнит к Этрусской Лиге, нужно указать «rom_etruscan», также и для других фракций (Пункт 5)

Land_units.
Сначала посложнее, открываем в «data_rome2.pack» и юнит-паке таблицу «land_units» и также отсеиваем нужный юнит в «data_rome2.pack».
Следующий шаг, это создать новую строку щелчком по «Add Row» (Не волнуйтесь, если выскочит ошибка, это пустяк) скопировать значение всех строчек из «data_rome2.pack» в юнит-пак, таких как «accuracy, ammo…» и так далее, исключая строку «key». В «key» мы скопируем тот самый ключ, который указали в «unit_variants», а у меня это — «Etr_Chariot»
Насчёт строк, думаю и так понятно за что большинство отвечает. По-крайней мере, можно сравнить данные из таблицы и из описания юнита в игры. По некоторым строкам:

Main_units.
Следующая таблица, это «main_units». Также ищем эту таблицу в обоих паках, создаём строчку тыком на «Add Row» (Если ошибка возникнет — забейте) и копируем все характеристики в соответствующие строчки, кроме «key», там мы пропишем уже известный ключ — «Etr_Chariot»
Если в строке «key», вы прописали ключ, который сами же и выдумали, то в строке «land_unit» нужно указать изначальный юнит, который лёг в основу, для меня это Серпоносная колесница — Gre_Scythed_Chariots.

Далее легче.
Таблица «units_custom_battle_permissions».
Открываем, создаём строку, пишем Ванильное название юнита в строке «unit».
В строке «Faction» указываем фракцию.

Таблица «land_units_to_units_ability_junctions»
Она отвечает за активные и активируемые способности юнита, такие как: Натиск, фаланга, черепаха и так далее.
Ability — Умения.
Land_unit — Юнит.
Указываем придуманый нами ключ юнита в «land_unit» и указываем желаемые способности юниту. Чтобы указать более одной способности (Пункт 5), нужно для каждой создавать новую строку и указывать ключ.

Unit_set_to_units_junctions.
Необходимо открыть таблицу в обоих паках (Вы же не закрыли «data_rome2.pack»?) и скопировать в соответствующие строки.
Беда в том, что я не знаю, за что отвечает эта таблица. Надеюсь подскажут мне, чтобы я мог дополнить.

Units_to_groupings_military_permissions.
И с этим пунктом беда.
Просто копируйте строки. В «military_group» нужно вставить параметр, который указан у юнитов юнит-пака или же найти юнитов той фракции, для которой вы добавляете юнита и скопировать то, что там указано.

Таблица «buildings_units_allowed» отвечает за то, какие здания позволяют нанимать отряд.
Пишем ванильный ключ «Gre_Scythed_Chariots» в строке «unit».
В строке «building» указываем здание. Важно, необходимо прописать столько строк, сколько есть развитий у здания (1-ый левел — марсово поле, 2-ой и т.д.), иначе, если вы пропишите только марсово поле, этот юнит не будет наниматься при 2-ом и далее уровнях казарм.
Важно, в строке «key» указать уникальный номер. Можно взять цифру на пару тысяч больше или же на одну. К примеру, последняя запись в таблице имеет номер 1998095, можно указать 200000 и выше или 1998096.

Таблицы по желанию:

3. Параметры, отвечающие за текст. Необходимо, если нужно сделать название и описание юнита уникальными. (Пункт 5)
land_units.loc. Что находится в «Textdb».
Открываем, создаём строку и вписываем в «Taq» параметр без скобочек: «land_units_onscreen_name_Здесь будет написан Ваш ключ». Например: «land_units_onscreen_name_Etr_Chariots»
Во второй строке пишем название юнита, какое хотим, но на английском.
Если это морской юнит, то вместо «land_units.loc» открываем «naval_units.loc» и далее как выше.

В «Etru_unit_description_short_texts.loc» также добавляем строку с записями «unit_description_short_texts_text_Ваш ключ юнита_Tooltip» и во второй строке описание. Наверное, на английском должно быть, потому что я точно не знаю не будет ли проблем, если строка будет заполнена русскими буквами.
К сожалению, есть вероятность, что название не будет отображаться. Для этого нужно добавить его в русскую локализацию, либо в мод-руссификатор, который можно скачать здесь: http://totalwars.ru/…showtopic=45977
Смотреть пункт 5.

4. Итак, вы добавили юнит в компанию, он спокойно нанимается и всё хорошо, но вот беда, юнит-то выглядит соответствующе своей изначальной фракции, но не новой. Я имею в виду вооружение и доспехи.
Чтобы это поправить, нужно открыть в «data_rome2.pack» и юнит-паке «variantmeshesvariantmeshdefinitions».
В «data_rome2.pack» находим нужный юнит (Пункт 3), щёлкаем правой кнопкой мыши по нему и выбираем «ExtractExtract Selected».
Файл сохранился на компьютере. Мы перенесём юнит в наш юнит-пак.
Но прежде, нужно переименовать юнит в соответствии с ранее придуманным ключом, для меня это «Etr_Chariot».
Щёлкаем в юнит-паке по «variantmeshes» правой кн. мыши: AddDirectory, нажимаем «Browse» и ищем папку с сохранёным юнитов. Щёлкаем окей и юнит добавиться.
Далее щёлкаем ПКМ но добавленному юниту: OpenOpen as text и здесь мы увидим всё снаряжение и вооружение юнита. Напомню, что лошади и анимация меняются в «land_units»
Чтобы разобраться тому, кто ранее не имел дело с переодеванием юнита, есть отличный туториал: http://totalwars.ru/…showtopic=44239 (Переодевание юнитов в Рим 2.)
Важно, после такого добавления юнита в юнит-пак, необходимо прописать его в «Variants_tables». Создаём строку и указываем Наш ключ.

5. Как узнать ключ фракции, юнита, способности, а также описания к этому?
Открываем PFM «local_ru_rome2» или «local_ru» в папке «data»: «textlocalisation.loc». Вверху видим кнопку «Export TSV», нажимаем и сохраняем куда захотите.
Открываем блокнотом и копируем в поисковик (ctrl+f) ключ того, перевод которого хотите узнать.
Или же русское название юнита, фракции, способности, если вам нужно выяснить ключ.

И так, нам нужно, чтобы название юнита отображалось в русской версии.
Открываем PFM «local_ru_rome2» в папке «data» или же мод-руссификатор. Идём: «textlocalisation.loc».
Создаём 2 новые строки.
И в «Taq» первой строки вписываем, без скобочек: «unit_description_short_texts_text_Ваш ключ юнита_Tooltip». Напротив этой записи пишите перевод, описание юнита. Оно будет отображаться в минимизированном окне с параметрами.
Во второй «Taq» вписываете «land_units_onscreen_name_Ваш ключ юнита». Напротив — Русское название юнита.

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

Сообщение отредактировал AkrDai: 14 Март 2014 — 13:08

Обновлено: 09.02.2023

Выкладываю туториал для мододелов по игре Аттила тотал вар. Им, думаю, можно пользоваться и для других игр ТОТал вар, в которых используются файлы RMV2.

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

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

Сообщество Империал: Важная информация по моддингу Total War: Attila — Сообщество Империал

ПС Кто использует более раннюю

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

Только на переходе хода вылет. но это понятное дело, так и должно быть.

может найдутся и еще какие элементы

еще нужно в campaign_model/human_factions проставить номер новой играбельной фракции. как я понимаю, это номер блока players_array+1 или же номер этот находится в первой строке титульной закладки конкретной фракции:

Заметил одну вАжную вещь на счёт скоупов (областей применения):
Если в одной таблице прописать две строки с одинаковым эффектом (например, для технологии), но выставить разную область применения (скоуп), то эффект будет работать в двух областях применения (скоупах).

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

Чтобы информация выводилась адекватно, СА сделали несколько идентичных скоупов с разными локализациями или вообще без локализации (скрытые).
1. general_to_force_own
2. general_to_force_own_horde
3. general_to_force_own_unseen
Например: это три скоупа-клона, у которых одно и то же назначение «персонаж при командовании армией». Разница только в локализации.
Первый выводит на экран «(подчинённые войска)», второй «(подчинённая орда)», третий без локализации.

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

Вот такие финты ради того, чтобы адекватно вывести инфу на экран об эффектах и скоупах. И вот такие ошибки, если это не учитывать.

Похоже, что при создании файла старпос в АкиТе учитываются правки, сделанные только в таблицах старпос. Другие таблицы по боку, к сожалению.

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

Акит — сволочь такая )))

Как делать трейты

Работа с трейтами распадается на два блока: работа с таблицами в ПФМе для создания трейта и работа в ПФМе со скриптами для редактирования/создания триггера (это набор условий, при котором происходит проверка на получение трейта).
Нужна ли нам будет вторая часть, если мы используем ванильный триггер? Толком протестировать я это не
смог, но думаю, что да — всё равно придётся дописывать кое-что в скриптах.
Замечу, что также нет смысла приниматься за дело без АКита, поскольку жизненно важная таблица trait_triggers (нужная не для создания трейта как такового, но для получения информации о триггере) в ПФМе просто недоступна.
Я опишу полный цикл создания трейта, включая создание нового триггера. Думаю, после этого работа со старыми трейтами и триггера станет понятна и так.

Итак, вот полный перечень задействованных таблиц:
character_traits
trait_info
trait_to_included_agents
trait_to_antitraits
character_trait_levels
trait_level_effects
trigger_effects

В character_traits создаётся именно трейт, названия колонок в общем и целом понятны. Обращает на себя внимание no_going_back_level. Видимо, именно это имел в виду rawhide. Я с этим, по крайней мере, не экспериментировал. Остаётся загадкой колонка precedence. Никакого влияния от её параметров я не заметил. Короче говоря, ставьте, как в ванили.

Далее прописывается техническая оснастка трейта. В trait_info выдаётся общая цель трейта. В игре это только agent. Хотя есть опции region и unit (остаётся только гадать, как это выглядит на практике). В trait_to_included_agents задаётся конкретная цель трейта — генерал, жрец и т.д. Чисто теоретически можно обойтись без этой таблицы, задав жёсткие условия в скрипте, но, как говорится, лучше перебдеть. В системе трейтов вообще много такого, что кажется дублирующим или излишним, но приходится всё это исполнять, как обряд.

trait_to_antitraits нужна нам, только если мы делаем трейт, противоположный существующему. Или сразу пару противоположных трейтов. Тут всё понятно — указанные в паре трейты будут друг друга заменять, не встречаясь одновременно. Как понимаю, нужно прописывать отдельно и пару трейтА — трейтБ, и пару трейтБ — трейтА, иначе замена будет работать только «в одну сторону».

Теперь переходим к содержимому трейта. В character_trait_levels мы создаём уровни трейта, создавать уровень нужно даже в том случае, если он у трейта единственный. Тут плюс-минимум всё тоже понятно по названиям колонок. Есть, правда, пустые колонки с манящими названиями вроде epithet_text (уж не кличка ли это?), но они ещё ждут своего исследователя. В этой таблице, однако, задаётся самый загадочный и едва ли не самый главный аспект трейта — threshold (порог). Опытным путём было выявлено, что это количество успешных проверок, которые должен пройти трейт, чтобы получить данный уровень. Т.е., скажем, если у первого уровня threshold = 2, а условие получение трейта, скажем, — выиграть в битве, вероятность же получения = 100%, то персонаж должен получить трейт только после второй выигранной битвы.
В целом при назначении threshold стоит ориентироваться на ванильные показатели. По крайней мере, поначалу.
Отмечу, что локализация трейта привязывается именно к его уровням (как название, так и описание — coloured text). Никакого общего названия для трейта не существует.

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

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

В trigger_effects мы приписываем трейт к определённому триггеру (придумываем, соответственно, новый). Судя по тестам, колонка value — это тот показатель, который добавляется к threshold после успешного прохождения проверки. Другими словами, если у вас threshold = 3 и value = 1, то трейт появится у персонажа после трёх успешных проверок. А если value = 3, то после первой же успешной проверки. Это проще всего понаблюдать, создав трейт, выдаваемый каждый ход всем персонажам с вероятностью 100, и запустив новую кампанию. В первом случае трейт будет получен на третий ход (каждый ход срабатывала успешная проверка), во втором – на первом же ходу, как только мы запустили кампанию.
Ну а вероятность, как нетрудно догадаться прописывается здесь же, в колонке chance.

На этом с таблицами мы покончили, можно приступать к скриптам, но сперва нам надо поучиться.
Идём в АКите в trait_triggers — это, своего рода, скриптовый файл, разложенный в табличном виде. Настольный учебник по созданию трейтов. Разобравшись в том, что и как там написано, мы усвоим азы синтаксиса скриптов.
Итак, тут у нас есть триггер, список ивентов, при которых триггер срабатывает (там выпадающий список, интуитивно понятный — наступление нового хода, рождение персонажа, взросление персонажа и т.п.). И самое главное — conditions, условия. Это условия, при которых происходит на получение трейта.
Тут задаётся контекст — какие персонажи, каких фракций, религий, культур, субкультур, на какой территории и при каких других условиях будут проходить проверки на получение данного трейта.

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

Переводится это так:
Персонаж — генерал с армией И имя фракции — «Римская экспедиция» И фракция персонажа открыла технологию gloria_romanorium И НЕ кампания-пролог И НЕ гранд-кампания
Т.е. трейт выдаётся генералам и губернаторам Римской экспедиции в кампании Велизария после открытия определённой техи. Всё просто.
Команды типа context:character():faction():name() – это тот самый технический текст. Мы можем присваивать им ключи, взятые из таблиц – названия фракций, религий и прочего (в данном случае — bel_fact_byzantine_expedition).
Есть и самостоятельные функции, например, char_is_general_with_army. На самом деле, под этой функцией уже закодирован определённый контекст, который нам не нужно прописывать (контекст, в общем-то, ясен из названия).
NB. Если открыть пак data через ПФМ, то по адресу lua_scripts / lib_export_triggers.lua можно найти своеобразный сборник этих самых функций. Не могу сказать, что я нашёл там что-то экстраординарное, но для человека, который уже разобрался в trait_triggers, может быть полезно.

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

—[[ <Название скрипта, думаю, чисто для красоты> ]]—

function <Название триггера>_impl (context)
return <набор контекстов>
end

Нетрудно догадаться, что всё, что не вошло в скобки <>, трогать не стоит.

Но самое сердце (и источник всех глюков) трейтового скрипта — это набор условий, или контекстов.
Синтаксис его довольно прост — его мы уже наблюдали в trait_triggers. Ровно те же самые команды и функции мы из него и берём.
У нас есть несколько логических операторов (капсом — для наглядности):
— AND — «и»
— OR — «или»
— NOT — оператор отрицания для функций (у которых нет значка присвоения ==). Обычно идёт в комбинации с AND или OR. Т.е. если мы хотим задать условие «все, кроме генералов, командующих армией», то мы пишем not char_is_general_with_army(context:character())
—

= — оператор отрицания для команд со значком присвоения ==. Собственно, этот значок он и заменяет. Т.е., если мы хотим задать условие «любая фракция, кроме фракции гаутов», то мы пишем context:character():faction():name()

= «att_fact_gauti». Ни в коем случае не используйте NOT в данном случае. Весь скрипт просто перестанет работать.
— и наконец, обычные скобки (). Как в формулах Экселя. С помощью них можно задавать довольно сложные условия, группируя контексты. Скажем, условие вида

(context:character():is_faction_leader() and context:character():faction():name() == «att_fact_mauri») or context:character():faction():name() == «att_fact_gaetuli»

— позволяет нам воздействовать конкретно на лидера фракции мавров ИЛИ на всех персонажей фракции гетулов. Но не на рядовых персонажей фракции мавров.
Тут логика — наше всё. Короче говоря, если вы не понимаете, каковы будут последствия у условия ЕСЛИ (А И Б), а какие — у условия ЕСЛИ (А ИЛИ Б), то лучше вообще не подходите к трейтам.

На закуску ряд полезных условий для создания трейта (из тех, что я лично проверял или использовал):
— context:character():is_faction_leader() — персонаж — лидер фракции
— char_is_general(context:character()) — персонаж — генерал (любой не женский персонаж и не агент)
— char_is_governor(context:character()) — персонаж — губернатор
— context:character():faction():name() == «ВАШ ТЕКСТ» — фракция персонажа
— context:character():model():campaign_name(«ВАШ ТЕКСТ») — определить кампанию (пролог, основная, Велизарий, Карл)
— context:character():faction():state_religion() == «ВАШ ТЕКСТ» — гос. религия персонажа
— context:character():has_trait(«ВАШ ТЕКСТ») — персонаж имеет определённый трейт
— context:character():faction():culture() == «ВАШ ТЕКСТ» — культура фракции персонажа
— context:character():faction():subculture() == «ВАШ ТЕКСТ» — субкультура фракции персонажа
— context:character():age() > ВАШ ТЕКСТ — возраст персонажа больше заданного числа (ну или меньше, если знак перевернуть)
А есть ещё контексты, связанные с битвами.

Сообщество Империал: [Статья] Туториал по моддингу Аттила Тотал Вар (rigid_model_v2) — Сообщество Империал

Как создать мод к 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».

Глянем на папку 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

Совместно используемые текстуры между слотами
Если желаете использовать одни и теже текстуры для частей разных типов следуйте инструкции:
Euro (любая папка schema)
_NakedParts/
texture*.dds
Heads/
Fat/
Mesh
Angry/
Mesh
Hands/
Fat/
Mesh
Slim/
Mesh
Heads/
.
Hands/
.
Что нужно знать об этом:
• См. главу «Слоты» для большей информации о папках, начинающихся на «_»
• Меши частей в _NakedParts/ совместно используются , учитывая, что нет текстур в слот папке в _NakedParts/. Если добавите текстуры к одной из частей, эта определенная часть не будет использовать совместно текстуры, но будет применять те, что вы добавили туда.
• Для файлов текстур процедура та же: можете помместить их в подпапку и можете создать несколько папок текстур и можете применять «_» для совместноиспользуемых.
• Есть опция, позволяющая заставить движок выбрать ту же случайную текстуру для одного слота или для другого, добавив «_» суффикс к названию папки текстур. Это очень удобно в этом конкретном примере, поскольку мы хотим, чтобы цвет кожи головы и рук был одинаков.

[Статья] Туториал по моддингу Аттила Тотал Вар (rigid_model_v2)

[Статья] Туториал по моддингу Аттила Тотал Вар (rigid_model_v2)

So in your case just right click on the viewport and press «Unhide All». Then should make the bosses visible so you can delete them.

Вчера случилось то чего мы ждали давно. СА расщедрились и дали страждущим мододелам инструменты для моддинга Total War: Shogun 2 — Assembly Kit. А сегодня мы начинаем публиковать перевод инструкции по работе с этим набором. Читайте и создавайте моды!

Читайте также:

  

• Как сделать мод для dishonored

  

• Как стать богом в майнкрафте мод

  

• Чем больше опыта тем больше рост майнкрафт мод

  

• Как писать моды для minecraft на python

  

• Как открыть моды в айзеке