deep_strike_ext — определяет возможность диспстрайка (десантирования) отрядов.
area_effect — когда такая дура сверху падает, всякое может произойти. Вот здесь мы и описываем, что будет происходить. Полностью аналогично параметру оружия. deep_strike_object_name — вариант десантной капсулы. delay — задержка перед десантом в секундах.
research_ext — определяет доступные в здании исследования.
research_limit — предельное количество исследований, которое можно сделать.
research_table — таблица доступных исследований.
Список всех возможных исследований прописан в attrib\research.
spawner_ext — дает возможность производить сквады. Можно прикрутить такую возможность и юниту, но обычно речь идет о здании.
can_rally_point — определяет наличие точки сбора.
spawner_space_offset_for_new_unit_position — смещение пространственных координат
произведенного юнита относительно здания.
squad_table — таблица доступных для производства сквадов.
squad_hold_ext — дает возможность сажать отряды в здания (взгляни на большинство зданий имперской гвардии).
acceptable_type_x — тип сквада, доступного для посадки. Совпадает с типом отряда,
доступного для транспортировки в технике, и описанного в squad_transportable_ext у
сквада.
Полный список возможных типов доступен в attrib\ type_transportable.
holds_produced_squads — определяет, будет ли произведенный в здании сквад
автоматически в него посажен, или сквад будет выплюнут на поверхность.
modifiers_no_squads, modifiers_squad_x — определяют модификаторы, изменяющиеся при
нахождении в здании сквадов. Гвардейским зданиям щедро выдается оружие при
нахождении в нем защитников. Рекомендую обратить на данные ветки самое пристально
внимание.
nr_available_spots — количество доступных слотов.
underground_tunnel — есть ли подземные переходы, позволяющие юнитам перемещаться
внутри по зданиям.
unload_delay — задержка при перемещении по тоннелям.
structure_buildable_ext — описывает некоторые мелочи.
build_menu_priority — позиционирование иконки здания при строительстве. power_gift, requisition_gift — бонус энергии/влияния после строительства здания. return_power_percent, return_requisition_percent — какую часть средств на строительство игра вернет при уничтожении кнопкой delete после строительства.
return_power_unbuilt_percent, return_requisition_unbuilt_percent — какую часть средств на строительство игра вернет при уничтожении кнопкой delete, если здание было недостроенным.
structure_ext — описывает влияние на возможность застройки.
control_structure_is — является ли зданием, вокруг которого возможна застройка.
control_structure_radius — радиус возможной застройки.
control_structure_use — требуется ли для постройки данного здания контролируемая
территория.
Модификаторы
— Видишь модификатор?
— Нет.
— И я не вижу. А он есть…
Пожалуй, модификаторы — наиболее интересный и сложный раздел непосредственного редактирования ветки attrib. Модификаторы — это те невидимые нити, благодаря которым мы можем менять свойства объектов прямо во время игрового процесса.
Чтобы сразу включиться в процесс, найдем у Тау в юнитах pathfinder'a. Как ты помнишь, у него
оружие имеет свойство замедлять противника. Сейчас мы разберемся как в полевых условиях
разгадать секрет работы винтовки Следопыта. В файле tau_pathfinder.rgd в ветке
combat_ext\hardpoints\hardpoint_01\weapon_table\weapon_01 находим оружие юнита под
названием tau_pulse_rifle_pathfinder.
Теперь в attrib\weapons находим tau_pulse_rifle_pathfinder.rgd.
Залезаем в него и в ветке area_effect\weapon_damage находим подветку modifiers. Вот они,
родимые — модификаторы.
Щелкаем в первом же модификаторе modifier_01, где видим некий
modifiers\speed_maximum_modifier.
Как нетрудно догадаться, модификатор влияет на максимальную скорость юнита.
В ветке modifier_01 сразу обрати внимание на параметр max_lifetime — он определяет время
действия модификатора в секундах. В нашем случае действие будет длиться 2.5 секунды.
На подветку modifier обратим самое пристальное внимание:
| в | Properties | |
| Name | modifier | |
| Data Type | Table | |
| Reference | modifiers \speed_maximum_modifier.lua | |
| в | Table Children | |
| application_type | typejnodifierapplica ton type \tp_mod_apply_to_squad. lua | |
| exclusive | False | |
| modifier_dass_name | type_modifier \tp_modifier. lua | |
| probability _of_applying | ||
| target_type_name | ||
| usage_type | typejnodifierusagetype \tp_mod_usage_multiplication. lua | |
| value | 0.92 |
Сразу смотрим на Reference, где указан исходный модификатор. Все модификаторы игры
хранятся в attrib\modifiers, если понадобится сделать что-то специфическое можно попробовать
поискать именно там.
Следующая строка application_type определяет объект, к которому будет применен модификатор.
Бывают следующие полезные варианты:
tp_mod_apply_to_squad — к скваду. Эффект распространяется на весь отряд.
tp_mod_apply_to_entity — к сущности. То есть к одиночному объекту (здание, юнит).
tp_mod_apply_to_player — к игроку. Например, модификаторы, изменяющие приток ресурсов.
Полный список находится в ветке игры attrib\type_modifierapplicationtype.
Исключительно важный параметр usage_type определяет способ работы модификатора:
tp_mod_usage_enable — модификатор включает или выключает что-то.
tp_mod_usage_multiplication — изменяет определенное численное значение (у нас — скорость).
Полный список находится в ветке игры attrib\type_modifierusagetype.
И, наконец, параметр value определяет численное значение изменяемого параметра. В нашем
случае винтовка пасфайндера снижает скорость передвижения на 8 процентов от исходной
(умножает 1 на 0.92).
Абилки
Как уже сообщалось ранее, абилки — особые способности юнитов.
Подразделяются на активные и пассивные, отличаются по способу применения (не себя, на врага,
на поверхность).
Все абилки находятся в ветке attrib\abilities, в файле юнита прописываются в ability_ext\abilities.
Сразу попробуем сделать что-нибудь простенькое, одновременно пояснив некоторые моменты.
Редактировать будем осколочные гранаты тактикалов.
Находим юнита тактикалов — space_marine_tactical_bolter.rgd, у него в абилках находим
abilities\marines_frag_grenades.
Соответственно пулей летим в abilities, где лежит marines_frag_grenades.rgd.
Параметры абилки
activation — тип активации абилки. Бывают всякие разные:
tp_ability_activation_always_on — работает постоянно, подходит для пассивных абилок.
tp_ability_activation_targeted — работает по указанной мишени (наш случай).
tp_ability_activation_toggled — переключается в режимы вкл/выкл. area_effect — определяет воздействие на цель. Все полностью аналогично оружию. В нашем случае рекомендую обратить внимание на то, что граната имеет радиус действия, небольшой разбрасывающий эффект, типы поражаемой брони ограничиваются пехотой (остальные просто отсутствуют, то есть получают min_damage_value повреждений), фильтр настроен на врагов.
caster_damage — определяет какой вред будет нанесен кастующему абилку юниту. child_ability_name — дочерняя абилка. Ты наверняка обращал внимание на Орбитальную бомбардировку ФК и на возможность выпустить весь боезапас у Скайрея Тау. Так вот, многочисленные, повторяющиеся с незначительным изменением параметров абилки реализованы именно с помощью серии дочерних абилок.
Механизм несложный. Самая первая (родительская) абилка определяет для следующих, например, точку на поверхности. Дочерние абилки ориентируются по этой точке и с некоторым случайным разбросом. При этом каждая последующая абилка имеет свою дочернюю абилку, организуя тем самым череду событий.
child_activation_percent — вероятность активации дочерней абилки (1 = 100%). duration_time — определяет длительность воздействия абилки. fire_cost — стоимость применения абилки.
initial_delay_time — время подготовки к применению абилки. range — дальность действия способности. recharge_time — время перезарядки способности.
recharge_timer_global — глобальность перезарядки. Например, ФК (форс коммандер) имеет способность орбитальной бомбардировки, но время перезарядки у нее больше, чем время строительства ФК. Если ФК применит абилку, а потом умрет, новый ФК не сможет применить абилку, пока она не перезарядится. Если есть возможность строить несколько юнитов, имеющих подобную абилку, то применить ее сможет только один — остальные будут ждать, пока она перезарядится.
requirements — условия доступности абилки. target_ground — работает по поверхности.
target_leader_in_squad — действует на командира отряда (не обязательно сквад-лидера, может быть прикрепленный). Если командира нет — целью становится любой юнит. target_self — применяется на себя.
Теперь что касается внешнего вида всего нашего хозяйства на панели инструментов. Как и везде, ветки и параметры, включающие UI, так или иначе определяют визуализацию. Все вроде бы наглядно.
Начнем с абилок.
Параметр ui_ext\ui_info\icon_name определяет иконку способности на панели.
Если в параметре activation стоит tp_ability_activation_always_on, то иконка не отображается, ибо способность пассивная. Капеллан имеет лечащую ауру, но кроме как в текстовом описании это нигде не указано.
Если в параметре activation стоит tp_ability_activation_targeted, то иконка должна находится в папке Data\art\ui\ ingame \tau_icons — активная иконка, в Data\art\ui\ ingame_disabled \tau_icons — неактивная иконка.
Значению tau_icons/tau_skyray_missile_barrage_icon в поле icon_name соответствует файл tau_skyray_missile_barrage_icon.tga в папках активных и неактивных иконок.
Если в параметре activation стоит tp_ability_activation_toggled, то а папках иконок должно находиться по два файла с постфиксами _on и _off в имени. Рассмотрим на примере способности «Рабский труд» у раба Хаоса.
Активные иконки: forcedlabor_icon _on. tga, forcedlabor_icon _off. tga Неактивные иконки: forcedlabor_icon _on. tga, forcedlabor_icon _off. tga
ui_index_hint — определяет место иконки на панели, как и у юнитов.
Теперь о юнитах, сквадах и зданиях.
Иконки юнитов, сквадов и зданий хранятся в тех же папках, что и все остальные иконки. Они
точно также бывают активными и неактивными.
Но есть одна тонкость — апгрейды на оружие. Ты наверняка замечал, что при возможности
вооружить сквад различным оружием рамочка вокруг иконки сквада меняла цвет.
Вот на примере отряда тактикалов мы и научимся грамотно управляться с иконками. Никому ведь не хочется любоваться на заглушку противного розового цвета?:)
Названия файлов не будут отличаться для активной (ingame) и неактивной (ingame_disabled)
папок. Поэтому я приведу пример для папки ingame.
Иконка сквада прописывается в ui_ext\ui_info\icon_name.
Стандартному оружию (болтеру) соответствует файл tacticalmarine_icon.tga.
Как только мы апгрейдом выдаем новое оружие, очень важно название оружия, которое выдается
по weapon_table. Дело в том, что название этого оружия необходимо прописать через двойное
нижнее подчеркивание в названии файла иконки!
Заглянем в weapon_table\weapon_02, где прописан огнемет space_marine_flamer_tactical.
В папке data\art\ui\ingame\space_marine_icons ему соответствует
tacticalmarine_icon__space_marine_flamer_tactical.tga.
Хэвиболтеру соответствует tacticalmarine_icon__space_marine_heavy_bolter_tactical.tga.
Ракетнице — tacticalmarine_icon__space_marine_missile_launcher_tactical.tga.
Плазмагану — tacticalmarine_icon__space_marine_plasma_gun.tga.
Если сквад вооружен различными видами оружие, ему автоматически соответствует иконка tacticalmarine_icon__multi.tga.
ui_index_hint — определяет место иконки на панели, как и у абилок.
Как видно на картинке, неактивные иконки выглядят одинаково, поэтому можно просто сделать несколько копий одной иконки под разными именами.
Каждой активной иконке в идеале обязательно должна соответствовать неактивная. В некоторых случаях можно обойтись без неактивной. Скажем, абилка переключающегося типа и дается юниту без requirements. Но лучше перестраховаться, чем потом позориться из-за собственной лени:)
Боевые построения
Построение указывается у сквада в ветке squad_formation_ext параметром idle_formation, в котором содержится референс (ссылка) на папку формаций.
Сами формации находятся в Data\attrib\formations в виде обычного rgd -файла.
В нем параметр scale отвечает за плотность строя. То есть насколько близко будут друг к другу
соседние ячейки построения.
Все это хозяйство должно синхронизироваться неким образом с entity_blueprint_ext\scale_x в
параметрах юнита.
Если сделать слишком маленький scale построения, получится каша из юнитов.
Ветка spots с подветками spot_x как раз содержит относительные координаты юнитов в
построении.
Тут следует принят во внимание ветку spawner_ext\spawner_space_offset_for_new_unit_position
с параметрами x, y, z у юнита или здания, которое производит наш сквад.
Именно эти координаты будут нулевыми у формации.
Сама ветка spot_x содержит следующие параметры:
pos_x, pos_y — координаты юнита относительно центра построения. Для первого юнита в
построении там стоят нули.
priority — приоритет появления нового юнита в скваде при реинфорсе в процентах. То есть если
стоит 100, то сначала будут заполняться ячейки с этим приоритетом, потом 90, 70, 50 и так далее.
Кстати, всего предусмотрено не более 17 ячеек для юнитов в скваде. Но, добавляя ветки spot_x инкрементом (увеличением) x, можно теоретически сделать сколько угодно.
Локализация мода
При создании новых юнитов, сквадов, оружия и абилок их непременно захочется переименовать
на свой лад. Такая возможность реализована в игре исключительно удобно.
Найдем в юнитах tau_crisis_suit.rgd — экзоскелет «Кризис» у Тау.
В ветке ui_ext\ui_info обрати внимание на параметр screen_name_id, в котором стоит непонятная
кракозябла $706200.
Что это такое? Это референс (ссылка) на файл локализации, где содержится описание в виде
именованных строк.
S16021390 Exorcist
S16021392 - Priest detached by the Ecdesiarchy to the Inquisition.
S160 2139 3 - Increases morale in nearby units.
0 - Decreases recharge time between two uses of special abilities.
1 - Rather good melee combat capacities.
Действительно, представь, во что бы превратилась локализация игры, если бы каждая строка описания юнита правилась непосредственно в редакторе. Поэтому разработчики изначально создают средства для быстрого доступа ко всей текстовой информации игры.
Файлы локализации для английской версии игры хранятся в папке мода Example_Mod\Locale\English, а для русской — Example_Mod\Locale\Russian
Файлы локализации имеют расширение .UCS.
Сейчас в нашем моде в этих папках ничего нет. Откуда же тогда игра подставляет значение
строкового параметра для Кризиса? Отвечаю: из архивов игры.
Сейчас мы создадим собственный файл локализации и там пропишем свои строки, на которые потом можно будет ссылаться.
Перейди на параметр screen_name_id и щелкни один аз мышкой на текстовом поле — там появится кнопка с тремя точками. И это совершенно не значит, что нас хотят послать на три буквы!:)
Вот на нее нужно нажать. Появится диалоговое окно.
Поскольку у нас еще нет файлов локализации, оно пустое. Поэтому жмем кнопку New.
Нас попросят ввести название мода. Оставим по умолчанию Example_Mod.ucs.
И жмем ОК.
Потом, когда захочется воспользоваться своим файлом, жмем Load и выбираем.
В этом окне и будет происходить редактирование строковых переменных. Плюсиком добавляем строку (номер добавляется автоматически, счетчиком). Дискеткой или кнопкой Save сейвим файл.
Кнопка Send selected entry to RGD позволяет подставить выделенный строковый параметр в поле игры, а Back to RGD просто возвращается в редактор, ничего не изменив.
Таким образом, изменение строковых параметров сводится к работе с файлом локализации, что очень удобно.
Если в начале загрузки мода мы выбрали English, то файл локализации сохраниться в английской папке Example_Mod\Locale\English. Если файл уже создан в английской папке, а игра русская, то нужно просто перенести Example_Mod.ucs в русскую папку.
Так можно поменять любые строковые параметры в редакторе, где бы они не были. Юниты, сквады, абилки, исследования — редактируются здесь.