Создание корабля

1. Введение

1.1. Цель документации

Эта документация представляет собой исчерпывающее, пошаговое руководство по созданию и интеграции пользовательских кораблей в игру. Оно написано для авторов модов, которые хотят добавить полностью функциональные корабли в морскую систему Bannerlord. Вам не обязательно быть программистом, чтобы следовать этому руководству, но вы должны уверенно работать в редакторе Bannerlord (Bannerlord editor) и понимать базовые концепции сущностей (entities), префабов (prefabs) и скриптов.

Цель — провести вас через весь технический конвейер (pipeline) — от настройки исходной иерархии вложенных префабов (Nested Prefab) до финальной реализации в игре. Следуя описанным здесь рабочим процессам, вы создадите корабль, который будет полностью совместим с физикой игры, навигацией ИИ, абордажем, взаимодействием с экипажем и системами улучшений.

1.2. Обзор конвейера создания корабля

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

Рабочий процесс разделён на три основных этапа:

• Базовая настройка (обязательно): Создание корневой сущности, импорт мешей корпуса и настройка физических объёмов (коллизии и плавучести), чтобы гарантировать, что корабль существует и корректно держится на плаву в физическом движке. Ничего не будет работать, пока этот этап не завершён.
• Игровая интеграция (улучшения): Реализация навигационных систем (рули, паруса, вёсла), механики абордажа, баллист и точек взаимодействия, необходимых для управления игроком и боя. Эти компоненты определяют, как игроки и ИИ взаимодействуют с кораблём.
• Детализация и доработка (косметика): Завершение оформления корабля визуальными улучшениями, эффектами частиц, взаимодействием с водой и декоративными элементами для усиления атмосферы. Эти компоненты чисто визуальны — их удаление не нарушит функциональность корабля.

2. Иерархия корабля и разбор компонентов

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

При создании корабля полная иерархия сущностей должна следовать этой общей структуре:

[ShipName]_ship_nested (корневая сущность)
├── mesh_holder
├── floater_volume_holder
├── control_point_holder
├── climbers_holder
├── attachment_machine_holder
├── barrier_holder
├── spawn_point_holder
├── rudders_holder
├── hull_group
├── shields_group
├── oars_holder
├── sail_holder
├── ship_ballista_holder
├── wetness_decals
├── ship_water_effects (только визуально)
├── ship_burning_system
└── [другие косметические держатели]

Каждый из этих дочерних элементов подробно описан в разделах ниже. Держите эту иерархию в уме во время работы — размещение компонента под неправильным родителем — одна из самых распространённых причин ошибок.

2.1. Обязательные компоненты (критичные)

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

2.1.1. Настройка корневой сущности (dromon_ship_nested)

Эта сущность является родительским контейнером для всего префаба корабля. Каждый другой компонент в этом руководстве размещается как дочерний элемент или потомок этой сущности. На протяжении всей документации мы будем использовать корабль «Dromon» в качестве эталонного примера.

• Соглашение об именовании: Мы рекомендуем использовать формат [ShipName]_ship_nested (например, dromon_ship_nested). Хотя это строго не навязывается движком, следование этому соглашению гарантирует, что ваш корабль легко идентифицировать и что он соответствует существующим ассетам кораблей в игре.

Необходимая настройка и атрибуты:

Настройки префаба (Prefab Settings):

• Enable Nested Prefab: [Включено]
  • Причина: Это критически важно для управления конвейером. Включение Nested Prefab позволяет открывать и редактировать дочерние префабы внутри иерархии (паруса, абордажные машины, вёсла и т.д.) независимо, без необходимости открывать весь корабль целиком. Без этого редактирование любого подкомпонента будет изменять весь файл корабля, что делает итеративную работу медленной и подверженной ошибкам.
• Enable Write Children to Separate XMLs: [Включено]
  • Причина: Это гарантирует, что каждый дочерний префаб сохраняет свои данные в отдельный XML-файл, а не встраивает всё в один большой файл. Это важно для контроля версий и для сохранения модульности корабля — изменения в одном компоненте не рискуют повредить остальные данные корабля.

Трансформация и рабочее пространство (Transform & Workspace):

• Identity Transform: Убедитесь, что корневая сущность создана с общими координатами идентичности (Pos: 0,0,0 | Rot: 0,0,0 | Scale: 1,1,1).
  • Причина: Весь корабль позиционируется и вращается во время выполнения морской физической системой игры. Если у корневой сущности есть какое-либо смещение или вращение, “запечённое” в неё, корабль будет выглядеть смещённым в игре, и все дочерние компоненты также будут смещены.
• Local Space: Для всех последующих дочерних компонентов выполняйте все операции позиционирования и вращения с использованием локальной трансформации (Local Transform).
  • Причина: Дочерние сущности наследуют мировую трансформацию своего родителя. Работа в локальном пространстве гарантирует, что когда корневая сущность движется (а это будет происходить постоянно во время игры), все дочерние элементы двигаются вместе с ней корректно. Работа в мировом пространстве приведёт к тому, что дочерние элементы будут отображаться в правильной позиции в редакторе, но смещаться в неправильные позиции в игре.

Настройка физики (Physics Configuration):

• Physics Shape: Назначьте форму физики типа Convex, которая примерно охватывает весь корпус.
  • Причина: Эта выпуклая (convex) форма служит двум критическим целям. Во-первых, это основное тело коллизии корабля — оно определяет, с чем физически сталкивается корабль в мире. Во-вторых, что более важно для кораблей, это основной движущий элемент системы плавучести. Игровой движок рассчитывает, какая часть этого выпуклого объёма погружена, чтобы определить восходящую силу плавучести. Если эта форма слишком большая, корабль будет плавать слишком высоко. Если она слишком маленькая, корабль будет сидеть слишком низко или тонуть. Всегда используйте меш, который точно следует внешнему корпусу ниже ватерлинии.
  • Примечание: Если предоставленный меш не является выпуклым, движок попытается автоматически аппроксимировать выпуклую оболочку, но это приближение может плохо соответствовать корпусу. Настоятельно рекомендуется предоставлять правильный выпуклый меш.
• Material: Назначьте физический материал wood_ship.
  • Причина: Материал wood_ship определяет, как физическое тело корабля реагирует на столкновения — его трение, упругость (отскок) и пороги урона. Использование неправильного материала (или его отсутствие) приведёт к некорректному поведению корабля при столкновении с местностью, другими кораблями или снарядами.
• Mass: Введите правильный физический вес корабля.
  • Предупреждение: Это значение напрямую влияет на то, как корабль плавает и реагирует на физику воды. Слишком лёгкий корабль будет хаотично подпрыгивать на волнах. Слишком тяжёлый корабль будет сидеть слишком низко в воде или полностью тонуть. Используйте существующие корабли как эталон для подходящих значений массы относительно их размера.
• Body Flags: Убедитесь, что следующие флаги ВКЛЮЧЕНЫ:
  • ✅ Dynamic — позволяет физическому движку перемещать это тело в ответ на силы.
  • ✅ Movable — требуется для кинематической системы, синхронизирующей движение корабля с пассажирами и установленными объектами.
  • ✅ Use Convex Hull — указывает физическому движку использовать выпуклую форму для коллизии.
  • ✅ Do Not Collide with Camera — предотвращает блокировку камеры физическим телом корабля.
  • ✅ Do Not Collide with Ray Cast — предотвращает блокировку игровых рейкастов (таких как прицеливание) физическим телом корпуса.

Важно: Любое физическое тело, добавленное к дочерним сущностям этого корня, также должно быть помечено как Movable в своих флагах. Это требуется, потому что корень использует кинематическую физическую систему — дочерние физические тела, не помеченные как Movable, не будут двигаться вместе с кораблём и отделятся в неправильные мировые позиции.

2.1.2. Скрипты

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

• MissionShip: Основной скрипт, который регистрирует эту сущность как корабль в системе миссий игры. Без этого скрипта игра не распознает сущность как корабль, и ни одна из морских игровых систем не активируется.
  • Важно: Вы должны назначить имя NavMesh в поле NavMeshPrefabName. NavMesh — это отдельный ассет, который определяет, где агенты ИИ могут ходить по палубе вашего корабля. Запекание NavMesh подробно рассматривается в разделе attachment_machine_holder (2.1.7).
• Volume_generator: Обрабатывает генерацию объектов плавучего объёма, которые система плавучести использует, чтобы удерживать корабль вертикально и стабильно на поверхности воды.
  • Лучшая практика: Выполняйте этот шаг после добавления меша корпуса в mesh_holder, поскольку генератору нужен меш для оценки правильного расположения объёма.
  • Включите Mock Generation, чтобы предварительно просмотреть, где будут размещены поплавки, перед подтверждением.
  • Цель: Сведите количество плавучих объектов к минимуму, регулируя Current Volume Count или Floater Volume Width. Больше объёмов даёт более стабильное плавание, но стоит больше производительности.
  • Убедитесь, что сгенерированные объёмы максимально соответствуют форме корпуса корабля.
  • Нажмите Generate Volumes, чтобы создать дочерние объёмы под floater_volume_holder.
• ShipFloatsamManager: Обрабатывает появление и поведение обломков и плавника при уничтожении корабля. Гарантирует, что сломанные доски, бочки и другие объекты появляются на поверхности воды после затопления корабля.
• ShipClothFixer: Управляет системами симуляции ткани на корабле (в основном паруса и знамёна). Без этого скрипта тканевые объекты на корабле могут вести себя хаотично или вообще не симулироваться при движении корабля.
• ShipColorAssigner: Управляет окрашиванием корабля в цвета фракции.
  • Factor Color: применяется к элементам улучшений, таким как сиденья и вёсла, окрашивая их в цвета владеющей фракции.
  • Ram Debris Color: применяется к декалям повреждений от столкновений, которые появляются, когда корабль таранит другое судно.
• EditorShipPhysics: Служебный скрипт, используемый только внутри редактора. Он позволяет симулировать и предварительно просматривать физику плавучести корабля без необходимости запускать игру, экономя значительное время итераций.
• NavalPhysics: Обрабатывает основную логику плавания и плавучести во время выполнения. Этот скрипт работает совместно с объёмами поплавков, чтобы удерживать корабль правильно ориентированным и движущимся по поверхности воды.
• EditorShipUpgradeViewer: Служебная программа редактора, позволяющая предварительно просмотреть, как различные элементы улучшений (паруса, щиты, носовые фигуры и т.д.) будут выглядеть на корабле без запуска игры.
• ShipAttachmentMachineConnectionLogic: Обрабатывает логику соединения между кораблями во время абордажа. Он управляет состоянием абордажных мостиков — определяет, когда два корабля достаточно близко, запускает анимацию развёртывания мостика и связывает NavMesh двух кораблей.

2.1.3. mesh_holder

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

• Transform: Должна оставаться в состоянии Identity (0,0,0 | 0,0,0 | 1,1,1). mesh_holder никогда не должен иметь смещения относительно корневой сущности. Всё позиционирование отдельных мешей должно выполняться на дочерних сущностях внутри этого держателя.
• Physics: Любое физическое тело, добавленное дочернему элементу mesh_holder, должно иметь включённый флаг Movable. См. примечание в разделе 2.1.1 для причины.

Необходимые теги на основном меше корпуса:

• rope_physics_body — помечает эту сущность как физическую точку привязки для динамических симуляций верёвок на корабле (такелаж, завязывание линий и т.д.). Верёвки, прикреплённые к кораблю, используют эту помеченную сущность в качестве корневой точки крепления.
• body_mesh — идентифицирует эту сущность как основной визуальный корпус. Несколько систем движка (включая ShipWaterEffects) используют этот тег для выполнения рейкастов относительно корпуса для автоматического вычисления позиций частиц, высоты ватерлинии и других визуальных параметров. Этот тег должен существовать, а сущность должна иметь действительный MetaMesh с точным ограничивающим прямоугольником (bounding box).
• hull_water_mesh — помечает меш, используемый специально системой симуляции воды внутри корпуса. Этот меш определяет визуальную внутреннюю поверхность, на которой отображается симулированная вода на палубе.

Настройка воды на палубе (Deckwater Setup): Создайте дочерний объект с именем deckwater внутри mesh_holder и назначьте ему тег render_to_depth.

• Причина: Тег render_to_depth указывает системе водных эффектов корабля включить этот меш в рендер глубины сверху вниз, используемый для определения того, где на палубе может скапливаться симулированная вода. Любой меш с этим тегом (включая сиденья гребцов и другую мебель палубы) вносит вклад в текстуру глубины. После добавления или изменения мешей с тегом render_to_depth нажмите Re-render Depth Texture в скрипте ShipWaterEffects, чтобы обновить симуляцию.

2.1.4. floater_volume_holder

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

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

• Видимость: Отключите видимость этой сущности в инспекторе сущностей (Entity Inspector), как только проверите объёмы. Объекты объёма чисто функциональны и не должны быть видны во время обычного редактирования, так как они загромождают вьюпорт.

2.1.5. control_point_holder

Эта сущность содержит механизм управления рулём корабля. Тип используемого здесь префаба управления зависит от физического дизайна корабля.

• ShipControl_nested: Используйте этот префаб для высоких кораблей или любого корабля, где руль физически не достигает поверхности воды, или где управление не выполняется видимым рулём в мире (например, управление абстрагировано). Этот префаб обрабатывает логику управления без необходимости физического взаимодействия с мешем руля.
• ShipControlRudder_nested: Используйте этот префаб для более низких кораблей, где руль физически уходит в воду и управляется вручную агентом. Это более физически реалистичный вариант.
  • Настройка: Назначьте меш руля и физическое тело дочерней сущности контроллера как metamesh. Форма физики руля должна точно соответствовать его визуальному мешу, так как агенты будут физически взаимодействовать с ним.

2.1.6. climbers_holder

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

Используйте префабы: longboat_rope_climber_small_nested, longboat_rope_climber_medium_nested или longboat_rope_climber_large_nested в зависимости от высоты поручней корабля над водой.

Каждый префаб верёвочной лестницы (climber) содержит три ключевые дочерние сущности:

• climb_point — позиция на палубе, где агент приземляется после завершения анимации взбирания. Разместите это на поверхности палубы, внутри от поручней.
• end_position — верхняя точка анимации взбирания. Это должно быть на уровне поручней или чуть выше.
• standing_point — нижняя точка анимации взбирания, на уровне воды. Отсюда агент начинает подъём. Вы можете скорректировать точную начальную позицию через скрипт на этой сущности.

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

2.1.7. attachment_machine_holder (система абордажа)

Этот раздел содержит префабы, необходимые для механики абордажа. Это одна из наиболее сложных частей настройки корабля. Есть два основных типа префабов:

• attachment_machine_nested: Содержит все сущности, необходимые как для входящего, так и для исходящего абордажа — то есть обрабатывает как абордаж нашим кораблём вражеского, так и абордаж врагом нашего корабля.
• attachment_point_machine_nested: Содержит сущности, необходимые только для того, чтобы вражеский корабль мог взять на абордаж наш корабль (принимающая сторона абордажа).

a) Структура attachment_machine_nested:

• distance_helper: визуальная сущность в редакторе, показывающая минимальное необходимое расстояние между двумя кораблями, прежде чем абордажный мостик может быть развёрнут. Это предотвращает наложение мостиков друг на друга или прохождение сквозь геометрию.
• attachment_machine (родитель):
  • hook: визуальное представление абордажного крюка, бросаемого агентами при инициировании абордажа. Это должен быть небольшой меш, размещённый в позиции покоя крюка.
  • pilot: сущность без физики, размещённая на палубе прямо над тем местом, где должно начинаться соединение NavMesh абордажного мостика. Игра использует позицию этой сущности для сшивания NavMesh мостика с NavMesh палубы корабля. См. раздел настройки NavMesh ниже.
  • focus_object: физический объект, который агенты должны поразить броском крюка для успешной попытки абордажа. Разместите это на поручнях корабля, где крюк реалистично мог бы зацепиться.
  • pile_holder: родительская сущность, содержащая визуальные верёвки и свисающие элементы абордажной установки. Они чисто визуальны — у них нет физики или взаимодействия.

b) Структура attachment_point_machine_nested:

• hook_attach_point: сущность без физики, указывающая, где вражеский абордажный крюк приземляется на наших поручнях после успешного броска крюка. Разместите это на поверхности поручней.
• pilot: сущность без физики, требующая грани NavMesh под собой для соединения NavMesh мостика. Функционирует идентично pilot в attachment_machine_nested.
• visual (родитель):
  • bridge_target_point: родитель для визуальных объектов без физики, появляющихся на поручнях и палубе после того, как враг устанавливает мостик. Видимость по умолчанию должна быть выключена — игра активирует их, когда мостик установлен.
  • bridge_connection_point: определяет начальную или конечную точку абордажного мостика. Должна быть размещена точно на поручнях, следя за тем, чтобы она не была погружена внутрь физического меша поручней. Если эта точка находится внутри геометрии, мостик будет неправильно отображаться (клиппинг).
  • bridge_source_point: родитель для визуальных объектов без физики, появляющихся после того, как крюк успешно зацепился и мостик начинает разворачиваться. Видимость по умолчанию должна быть выключена.
  • focus_object: физический объект, который должен быть поражён для успешного выстрела крюком с вражеского корабля.
  • capsule_physics_a: физическая капсула, позволяющая агентам взбираться с палубы на высоту поручней, когда мостик активен. Этот объект неактивен, когда мостика нет — его активация при отсутствии мостика позволила бы агентам сходить с корабля в воздух.
  • Требование привязки: верхняя часть этой капсулы должна точно привязываться к bridge_connection_point.
  • Автопривязка: вы можете разместить её вручную, включив визуализацию физики, или использовать кнопку Auto Arrange Bridge Ramp Physics в скрипте Volume_generator корневой сущности, чтобы автоматически привязать все объекты физики капсул одновременно.

• _barrier_ai_04x04m_nested: барьер ИИ, предотвращающий схождение агентов с корабля в точке соединения абордажа, когда мостик отсутствует. Этот барьер автоматически деактивируется, когда мостик установлен, позволяя агентам переходить.

c) Настройка и запекание NavMesh:
NavMesh определяет, где агенты ИИ могут ходить по палубе вашего корабля. Он должен быть корректно запечён, чтобы абордажные мостики функционировали. Система мостиков динамически соединяет NavMesh двух кораблей во время выполнения, и приведённые ниже ID — это то, как она узнаёт, с какой гранью соединяться.

• Уникальные ID: В скрипте ShipAttachmentPointMachine (находится в обоих префабах машин) найдите поле RelatedShipNavmeshOffset. Введите здесь уникальный целочисленный ID для каждой машины. Никакие две машины на одном корабле не должны иметь одинаковый ID.
• ID граней: В NavMesh корабля грань, расположенная непосредственно под сущностью pilot каждой машины, должна иметь тот же ID, что введён в RelatedShipNavmeshOffset. Игра использует этот соответствующий ID, чтобы знать, какая грань NavMesh является точкой соединения для каждого мостика.
• Общая палуба: Всем остальным граням NavMesh на палубе корабля, не являющимся точками соединения мостиков, должен быть назначен ID 0.

Запекание и сохранение:

1. Выберите все грани NavMesh.
2. Перейдите к скрипту MissionShip на корневой сущности.
3. Нажмите SaveNavMeshFromLocal.
4. Введите имя файла и сохраните его в папке модуля вашего мода.
5. Введите это имя файла в поле NavMeshPrefabName в скрипте MissionShip.

2.1.8. barrier_holder

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

Используйте префабы: _barrier_ai_04x04m_nested или _barrier_ai_04x08m_nested. Они функционально идентичны — единственное различие заключается в их размере по умолчанию. Масштабируйте их по мере необходимости для покрытия нужной области.

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

2.1.9. ship_target_point

Эта сущность содержит скрипт ShipTargetMissionObject и должна присутствовать на каждом корабле. Она регистрирует корабль как целевой объект (targetable object) в боевой системе игры — без неё дальнобойное оружие, такое как баллисты, не может захватить корабль в прицел.

Что она делает:

• Помечает корабль как допустимую цель для дальнобойного оружия (TargetFlags.IsShip | TargetFlags.IsMoving).
• Сообщает текущую скорость корабля, чтобы снаряды могли правильно вести прицеливание по движущемуся кораблю.
• Предоставляет значение приоритета цели, которое масштабируется в зависимости от оставшегося количества экипажа и здоровья корпуса корабля. Сильно повреждённый или почти лишённый экипажа корабль автоматически становится целью с более низким приоритетом.
• Когда корабль тонет, добавляется флаг NotAThreat, чтобы дальнобойные подразделения ИИ прекратили целиться в него и перенаправили огонь в другое место.

Настройка: Добавьте вложенный префаб ship_target_point как прямой дочерний элемент корня корабля. Дополнительная настройка не требуется — скрипт автоматически считывает состояние корабля во время выполнения через скрипт MissionShip на корневой сущности.

2.1.10. kinematic_batch_entity

Система kinematic_batch_entity обрабатывает оптимизацию физики для корабля. Без неё каждая дочерняя сущность на корабле с физическим телом симулировалась бы по отдельности, что быстро становится затратным. Эта система объединяет все эти физические формы в единое пакетное тело, которое движется вместе с корнем корабля — за долю стоимости.

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

• simulated — пакетирует формы, используемые для полного физического взаимодействия (реакция на столкновения, ходьба агентов по палубе и т.д.)
• ray_cast — пакетирует формы, используемые только для рейкастов (прицеливание, прямая видимость и т.д.)

Необходимая настройка:
Добавьте kinematic_batch_entity как вложенный префаб непосредственно под корнем корабля. Префаб расположен по пути: NavalDLC/NestedPrefabs/kinematic_batch_entity.xml

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

• Его трансформация является identity (позиция 0,0,0 — без вращения, без смещения масштаба).
• Его флаг тела включает Moveable.
• Он несёт тег batched_physics_entity.
• Должны присутствовать оба дочерних элемента, simulated и ray_cast. Движок выдаст предупреждение, если какой-либо из них отсутствует.

Пометка сущностей для пакетирования: Для каждой дочерней сущности, чья физическая форма должна быть объединена в пакет, включите опцию Move To Batched Kinematic в её свойствах физики.

В панели Physics сущности:

1. Назначьте физическую форму (тело bo_).
2. Включите флаг тела Moveable.
3. Включите Move To Batched Kinematic.

Что пакетировать: меш корпуса, структуры палубы, держатели мачт, варианты обшивки корпуса, фиксированную структурную геометрию.
Что НЕ пакетировать: сам корень корабля, kinematic_batch_entity и его дочерние элементы, сущности барьеров ИИ, физику верёвок/ткани, а также любые сущности, которые анимируются или отсоединяются независимо во время выполнения.
Варианты улучшений: Если у вашего корабля несколько вариантов корпуса под слотом улучшения, для каждого варианта можно включить Move To Batched Kinematic. Движок включает только формы, которые активны при инициализации корабля — убедитесь, что при запуске активен ровно один вариант на слот.

Распространённые ошибки проверки:

• Не найдена сущность с тегом batched_physics_entity → “Ship Prefab must contain a root batched physics entity!“
• kinematic_batch_entity не имеет identity-трансформации → “Batched physics entity should have identity matrix frame!“
• Отсутствует дочерний элемент simulated или ray_cast → “Ships should have a ‘kinematics’/‘raycast’ batch entity!“

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

2.1.11. spawn_point_holder

Эта сущность определяет все места появления (spawn) для игроков и отрядов ИИ на корабле. Система миссии игры считывает эти точки, чтобы определить, где разместить агентов в начале морского сражения.

• sp_troop_inner_deck_nested: точки появления для отрядов внутренней палубы — агентов, размещённых вдали от краёв корабля, обычно в центре или под палубой.
• sp_troop_outer_deck_nested: точки появления для отрядов внешней палубы — агентов, размещённых возле поручней и краёв, таких как лучники и моряки.
• sp_troop_captain_nested: точка появления капитана корабля.
• sp_troop_crew_spawn_nested: точки появления, используемые для подкреплений, прибывающих во время боя.

rally_point: Создайте пустую сущность и разместите её в передней части корабля, на поверхности NavMesh.

• Назначьте тег rally_point этой сущности.
• Переименуйте сущность в rally_point для ясности.
• Причина: это точка сбора, к которой агенты ИИ движутся при получении приказа о сборе. Без точки сбора агенты ИИ не будут иметь определённого места сбора и могут вести себя неадекватно при приказе перестроиться.

2.1.12. rudders_holder

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

• Размещение: Разместите эту сущность в самой задней части корабля, как можно ближе к поверхности воды.
• Настройка: Добавьте пустую сущность в качестве дочернего элемента, назовите её rudder_stock и назначьте ей тег rudder_stock.
• Причина: физическая система использует тег rudder_stock, чтобы определить точку руления корабля. Неправильное размещение (слишком далеко вперёд или слишком высоко) приведёт к нереалистичному поведению корабля при управлении — он может поворачивать слишком быстро, слишком медленно или вращаться вокруг неправильной точки.

2.1.13.oars_holder

Этот держатель содержит системы вёсел корабля. Вёсла являются игровым улучшением — они определяют скорость корабля при плавании без ветра. Префаб oar_deck обрабатывает как визуальные меши вёсел, так и систему посадки агентов для гребцов.

• Настройка корня: создайте пустую сущность в Identity и назовите её oars_holder.
• Добавьте префаб oar_deck как дочерний элемент. Переименуйте его в зависимости от типа:
  • oar_deck_upper: гребцы сидят на открытой палубе, видимой игроку.
  • oar_deck_lower: гребцы сидят внутри корпуса, не видны напрямую.

a) oar_deck_upper (видимые гребцы):

• Настройка: выберите сущность oar_deck_upper и нажмите ManageOarMachines в скрипте ShipOarDeck.
• Начальная настройка: не отмечайте Override Prefabs при создании в первый раз.
• Набор префабов: выберите набор, соответствующий размеру вашего корабля (UpperDeck 4m, 6m или 8m — число означает расстояние между позициями вёсел).
• Позиционирование: используйте значения Count, Span и Offset, чтобы выровнять позиции вёсел с корпусом. Это требует итерации — настройте значения, нажмите apply и визуально проверьте позиции. Кончики вёсел должны чисто входить в воду, а рукоятки должны естественно располагаться в руках агентов.
• Высоты сидений (критично): используйте функцию Adjust Seat Heights после позиционирования. Это обязательно. Анимация гребли фиксирована, и сиденья должны быть на правильной высоте, чтобы анимация совпадала со скамьями. Если высоты сидений неправильные, гребцы будут визуально проваливаться сквозь или парить над своими местами.

• Углы: отрегулируйте активный (в воде) и убранный (поднятый) угол вёсел в соответствии с геометрией вашего корпуса.
• Зеркалирование: как только одна сторона правильно настроена, используйте функцию Mirror, чтобы скопировать все настройки на противоположную сторону.

b) oar_deck_lower (внутренние гребцы):

• Настройка: следует тому же процессу, что и oar_deck_upper, но выберите набор префабов Lower Deck.
• Регулировка высоты сиденья не требуется для гребцов нижней палубы.
• Убедитесь, что вёсла выровнены и чисто выходят через весельные порты в меше корпуса. Смещённые вёсла будут визуально проходить сквозь корпус.
• Убранное состояние: убедитесь, что угол убранного весла размещает вёсла полностью внутри корпуса. Вёсла, торчащие наружу в убранном состоянии, будут проходить сквозь корпус и выглядеть некорректно.*

c) Интеграция с системой улучшений:

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

2.1.14. sail_holder (система War Sails)

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

Существует два типа парусов: прямой (Square) (прямоугольные паруса, подвешенные на рее) и латинский (Lateen) (треугольные паруса на наклонной гике). Каждый тип имеет три варианта размера (малый, средний, большой), что в сумме даёт шесть префабов парусов.

a) Подготовка ассетов:

• Меш симуляции ткани: меш паруса, используемый для симуляции ткани, должен помещаться в границы 15м × 15м × 15м в своём состоянии по умолчанию (полностью открытом). Сущность префаба может быть масштабирована в игре, но исходный меш должен оставаться в пределах этого ограничения.
• Топология: плотность полигонов и поток рёбер меша управляют тем, как деформируется ткань. Более плотная топология в областях, которые должны вздыматься, даст более детализированное движение ткани.

Ограничения вершин (критично — с использованием каналов цвета вершин, Vertex Color):

• Альфа-канал \= 0: вершины, которые не должны двигаться (прикреплённые к мачте или гику). Без этого парус отсоединится от своего крепления во время симуляции.
• Красный канал \= 0: вершины, соединённые с левой контрольной костью.
• Зелёный канал \= 0: вершины, соединённые с правой контрольной костью.
• Синий канал \= 0: вершины в сшитых областях (швах). Эти области симулируют натяжение между панелями.
• В игре: включите Create Stitching Constraints в настройках ткани, чтобы сшивание вступило в силу.

b) Такелаж и скелет:

• Скелет управляет контрольными костями, которые регулируют натяжение паруса и угол реи.
• Прямой парус (Square Sail): использует 2 контрольные кости (по одной для каждого конца реи).
• Латинский парус (Lateen Sail): использует 1 контрольную кость (конец гика).
• Имена костей должны точно совпадать с именами, показанными на эталонных изображениях иерархии, даже если сам объект скелета имеет другое имя.

c) Анимация и состояния:

• Анимация морфинга: требуется 200-кадровая анимация морфинга, представляющая переход паруса из полностью открытого в полностью закрытое состояние. Тот же морфинг воспроизводится в обратном порядке для анимации разворачивания. Эта анимация управляет последовательностью сворачивания и разворачивания, которую игроки видят при отдаче приказа о парусах.
• Закрытое состояние: когда парус полностью убран, меш ткани заменяется статическим мешем, представляющим собранный парус. Симуляция ткани неактивна в этом состоянии.
• Состояние горения: если парус загорается, он переходит в свободно висящий меш, симулирующий рваный, горящий парус. Этот меш не требует скелета или ключей морфинга — это чисто визуальная ткань без управления.

d) Настройка префаба (на примере sail_square_medium_nested):

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

Основные дочерние элементы:

• pulley_systems_holder: содержит все визуальные системы верёвок.
  • stability_ropes: верёвки, соединяющие контрольные кости с палубой (ванты и штаги). Тег каждой сущности верёвки должен совпадать с именем кости, к которой она подключена.
  • static_ropes_parent: статические декоративные верёвки. Тег attached_to_yard для верёвок, соединяющихся с реей; тег big_rope для верёвок, идущих от реи вниз к корпусу.
  • sail_fold_pulley_parent: верёвки, собирающие парус при сворачивании. Пометьте каждую сущность верёвки именем кости, которой она управляется.
  • sail_rotate_pulley_parent: верёвки, отвечающие за вращение реи для улавливания угла ветра.
• force_center_entity: должна иметь тег force_center_entity. Определяет точку, в которой сила ветра прикладывается к парусу для расчётов физики. Разместите это в центре площади поверхности паруса.
• sail_mast: разместите все визуальные сущности меша мачты под этим дочерним элементом.
• yaw_rotation_entity: должна иметь тег yaw_rotation_entity. Разместите ваши подготовленные ассеты паруса и реи под этой сущностью. Эта сущность вращается, чтобы симулировать поворот реи навстречу ветру.
• sail_upgrade_slot: сущность слота улучшения для улучшений уровня паруса.

2.2. Компоненты улучшений и геймплея

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

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

• ship_slots.xml: определяет все типы слотов улучшений, доступные для кораблей. Каждый тип элемента улучшения, используемый вашим кораблём, должен иметь соответствующую запись здесь. ID, определённые в этом файле, используются другими XML-файлами ниже.
• ship_upgrade_pieces.xml: определяет отдельные элементы улучшений — их характеристики, визуальные эффекты, описания и к какому ID слота они принадлежат.
• mission_ships.xml: регистрирует ваш корабль как используемый корабль в миссиях. Содержит ID корабля, имя префаба, массу и другие свойства уровня миссии.
• ship_hulls.xml: определяет статистику миссии корабля (здоровье, скорость, манёвренность и т.д.) и указывает, какие слоты улучшений доступны для этого типа корпуса.

2.2.1. hull_group

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

• Размещение: добавьте вложенный префаб hull_group к корневой сущности корабля в Identity (0,0,0).
• Структура: префаб содержит 5 дочерних сущностей, каждая из которых соответствует разному материалу корпуса или уровню улучшения.
• Настройка: добавьте подготовленный меш корпуса как MetaMesh к дочерней сущности, соответствующей правильному имени материала.
• Теги: необходимые теги для распознавания системой улучшений состояний корпуса предопределены на дочерних элементах префаба. Если вы создаёте новый тип корпуса, вы можете скопировать существующие теги улучшения корпуса из XML-файлов или удалить те, что не актуальны для вашего корабля.

2.2.2. shields_group

Этот вложенный префаб добавляет декоративные щиты вдоль поручней корабля, которые также служат для защиты отрядов на палубе от входящих дальнобойных атак.

• Размещение: добавьте вложенный префаб shields_holder в корневой Identity (0,0,0) корабля.
• Настройка: количество отображаемых щитов можно увеличить или уменьшить, редактируя соответствующий XML корабля или изменяя MetaMesh на дочерних сущностях.
• Цвета фракции (критично): каждая дочерняя сущность щита имеет тег banner_with_faction_color. Этот тег заставляет игру применять геральдику и цвета владеющей фракции к щитам во время выполнения.
  • Важно: вы также должны назначить тег banner_with_faction_color самому ассету MetaMesh и всем его вариантам LOD в браузере ресурсов (Resource Browser). Если тег есть на сущности, но не на ассете меша, цвета фракции не появятся.

2.2.3. cam_holder_nested

Этот префаб гарантирует, что элементы улучшений корабля корректно отображаются в интерфейсе City Port, где игроки покупают и просматривают улучшения.

• Размещение: добавьте префаб cam_holder_nested в Identity корабля. Лучшая практика — добавлять его после того, как все элементы улучшений размещены, чтобы камеру можно было расположить так, чтобы видеть весь корабль.
• Настройка: держатель содержит одну дочернюю сущность для каждого типа элемента улучшения, связанную с помощью тегов, которые считывает система интерфейса. Переместите каждую дочернюю сущность, чтобы расположить её над соответствующим элементом улучшения на корабле.
• Экземпляр камеры: переместите дочерний элемент Camera_Instance в позицию, которая даёт широкий, чёткий обзор всего корабля с выгодного ракурса.
  • Совет: установите вьюпорт редактора на желаемый угол камеры, затем щёлкните правой кнопкой мыши по Camera_Instance и выберите Assign Frame From Camera. Точные настройки (поле зрения, ближняя/дальняя отсечка) можно выполнить через скрипт на дочернем элементе экземпляра камеры.

2.2.4. roof_group

Этот префаб добавляет структуру крыши над ахтеркастлем (aftercastle) — приподнятой задней частью корабля — и над любым полубаком (forward castle), если это требуется дизайном корабля.

• Размещение: добавьте префаб roof_group к корневому Identity (0,0,0) корабля.
• Структура: префаб содержит 15 различных вариантов крыши и опций платформы. Добавьте подходящий для вашего корабля меш платформы как MetaMesh к дочерней сущности платформы, затем расположите варианты крыши в соответствии с вашей геометрией.

Окрашивание и теги:

• Тканевые элементы (навесы, тентовые крыши): назначьте тег sail_mesh_entity. Это приводит к тому, что ткань окрашивается в соответствии с цветом паруса фракции.
• Деревянные структурные элементы: назначьте тег auto_factor_color соответствующему деревянному материалу в браузере ресурсов (Resource Browser). Это приводит к тому, что дерево соответствует цвету корпуса, определённому в ShipColorAssigner на корневой сущности.
• Другие тканевые элементы: назначьте тег faction_color в браузере ресурсов (применить ко всем LOD). Это применяет общий оттенок цвета фракции.

2.2.5. figurehead_group

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

• Размещение: добавьте префаб figurehead_group в координаты Identity корабля.
• Структура: префаб содержит 17 стандартных вариантов носовых фигур, а также дочерние элементы base и platform для состояния корабля по умолчанию (без улучшения). Назначьте подходящий меш как MetaMesh дочерним элементам base и platform, если вы хотите, чтобы носовая фигура по умолчанию была видна до применения любых улучшений.
• Добавление новых типов: новые варианты носовых фигур должны добавляться как дочерние элементы основного префаба, а их характеристики и описания должны регистрироваться в ship_upgrade_pieces.xml и ship_slots.xml.
• Видимость: в отличие от большинства других элементов улучшений, носовые фигуры обнаруживаются посредством исследования игрового мира, а не покупаются в порту. Тем не менее, они по-прежнему отображаются в предпросмотре улучшений редактора при использовании EditorShipUpgradeViewer.

2.2.6. battlements_holder_aft

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

• Настройка: создайте пустую сущность с именем battlements_holder_aft в Identity под корнем корабля.
• Добавьте вложенный префаб battlement_shield_group_aft как дочерний элемент.
• Настройка: можно добавить несколько экземпляров. Каждый экземпляр префаба battlement содержит разные визуальные состояния для разных уровней улучшения и состояний разрушения. Частицы разрушения можно добавить как дополнительные дочерние элементы внутри каждого экземпляра, следуя той же структуре, что используется в основной системе горения корабля.

2.2.7. deck_upgrade_holder

Эта сущность содержит вложенный префаб deck_upgrade_assets_nested, который обрабатывает интерактивные и пассивные ассеты, появляющиеся на палубе на более высоких уровнях улучшения.

• Размещение: добавьте вложенный префаб deck_upgrade_assets_nested как дочерний элемент под этим держателем. Можно разместить несколько экземпляров в разных местах на палубе.
• Ограничение NavMesh: поскольку эти ассеты имеют физические тела, под ними не должен быть запечён NavMesh. Запекание NavMesh под физическими объектами вызывает ошибки поиска пути ИИ.

Разбор компонентов:

• Интерактивные ассеты: дочерние элементы с именами deck_ammo_1, deck_ammo_2, deck_ammo_3, deck_javelin_2 и deck_javelin_3 являются интерактивными объектами. Игроки и агенты ИИ могут взаимодействовать с ними, чтобы пополнить запасы стрел и метательного оружия во время боя.
• Пассивные ассеты: все остальные дочерние элементы внутри префаба являются чисто визуальными декорациями улучшения без взаимодействия.

2.2.8. ship_ballista_holder

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

• Размещение: добавьте этот префаб непосредственно под корневой сущностью.
• Теги: назначьте основной сущности держателя как тег upgrade_slot, так и тег fore. Тег upgrade_slot регистрирует её в системе улучшений; тег fore идентифицирует её как оружие, направленное вперёд, и делает её взаимоисключающей с battlements_holder_fore (корабль не может одновременно иметь баллисту и передние боевые щиты).

Разбор дочерних элементов:

• ballista_platform: приподнятая палубная платформа, дающая оператору баллисты лучший обзор для стрельбы. Эта платформа активна только тогда, когда установлено улучшение баллисты.
  • Тег: назначьте этой дочерней сущности тег platform.
  • Ограничение NavMesh: эта платформа не должна быть выше 1,5 метра над запечённым NavMesh палубы. Игра не генерирует отдельный приподнятый NavMesh для этой платформы, поэтому агенты должны иметь возможность заступить на неё с существующего NavMesh палубы. Если она слишком высокая, агенты не смогут добраться до баллисты.
• Дочерние элементы типа боеприпасов: каждый из оставшихся дочерних элементов представляет разный тип боеприпасов (стандартные болты, огненные болты и т.д.). Все дочерние элементы боеприпасов должны быть размещены в совершенно одинаковых координатах — игра переключается между ними, переключая видимость в зависимости от того, какой тип боеприпасов загружен. Каждый дочерний элемент должен иметь уникальный тег, идентифицирующий его тип боеприпасов.

2.2.9. battlements_holder_fore

Оборонительные щиты на полубаке (forecastle) — приподнятой передней части корабля.

• Настройка: создайте пустую сущность с именем battlements_holder_fore в Identity.
• Добавьте вложенный префаб battlement_shield_group_fore как дочерний элемент.
• Взаимное исключение: этот компонент взаимоисключающий с ship_ballista_holder. Корабль не может одновременно иметь передние боевые щиты и баллисту. Убедитесь, что теги на этом держателе используют обозначение fore, чтобы система улучшений корректно обеспечивала это исключение.

2.2.10. ram_group

Таран — это усиленное удлинение носа, используемое для тарана вражеских кораблей, нанося урон корпусу при столкновении.

• Размещение: добавьте вложенный префаб ram_group в Identity корабля.
• Структура: префаб содержит 8 предопределённых вариантов тарана и 1 меш-адаптер. Разместите и сориентируйте 8 вариантов тарана в соответствии с формой носа вашего корабля, затем добавьте подходящий меш расширения палубы или платформы носа как MetaMesh к сущности адаптера.
• Теги: все необходимые теги для систем улучшения и урона предопределены на дочерних элементах префаба тарана. Новые варианты тарана можно добавить к префабу и зарегистрировать в соответствующих XML-файлах, следуя существующим шаблонам.

2.3. Косметические компоненты и компоненты VFX

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

2.3.1. wetness_decals

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

• Настройка: создайте пустую сущность как прямой дочерний элемент корня корабля (не внутри mesh_holder или ship_water_effects). Назовите её wetness_decals и назначьте ей тег wetness_decals.
• Добавьте дочерние сущности под ней. Каждый дочерний элемент должен иметь компонент Decal с назначенным нужным материалом влажности.
• Расположите и сориентируйте каждую декаль относительно поверхности корпуса. Локальная ось “вверх” декали используется как её нормаль поверхности — убедитесь, что она направлена наружу, в сторону от поверхности корпуса, иначе система не сможет корректно определить, находится ли частица брызг достаточно близко, чтобы активировать декаль.
• Поведение: декали проявляются, когда активные частицы брызг находятся рядом с той же стороны корпуса, а затем постепенно исчезают примерно через 6 секунд бездействия.

2.3.2. rudder_objects

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

• Настройка: добавьте подходящий меш руля как MetaMesh дочерней сущности этого держателя.
• Тег: назначьте тег rudder_rotation_entity сущности, содержащей меш. Игра считывает этот тег, чтобы найти визуальный руль и синхронизировать угол его вращения с текущим вводом управления кораблём.

2.3.3. ship_water_effects

ShipWaterEffects (ship_water_effects) — это компонент-скрипт, который добавляет все визуальные эффекты, связанные с водой, на корабль. Он чисто визуальный и не влияет на физику или игровую логику.

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

Скрипт прикрепляется к дочерней сущности корня корабля — не к самому корню. Создайте дочернюю сущность с именем ship_visual_only и добавьте к ней скрипт ship_water_effects. Тег ship_visual_only ограничивает этот скрипт чисто визуальными сущностями, отделяя его от физики и игровой логики.

[ship_root]
└─ [ship_visual_only] ← здесь находится скрипт ShipWaterEffects

Обзор функций:

Примечание: вам не нужно вручную размещать какие-либо сущности частиц. Все позиции частиц вычисляются автоматически при запуске с помощью рейкастов относительно сущности body_mesh. Убедитесь, что body_mesh существует и имеет действительный MetaMesh с точным ограничивающим прямоугольником. Если у корабля есть таран, полоса частиц носа автоматически расширяется, чтобы покрыть кончик тарана — дополнительная настройка не требуется.

Настраиваемые параметры:

Симуляция воды внутри корпуса:

• Water Simulation Bounding Box (по умолчанию: 1,1,1) — размеры XYZ ограничивающего объёма. Используйте Reset Water Simulation Bounding Box для автоматического вычисления на основе мешей render_to_depth.
• Hull Water Simulation Resolution Scale (по умолчанию: half) — варианты: one, half, quarter, one_eight, one_sixteenth. Меньшие значения повышают производительность.
• Hull Water Splash Water Multiplier (по умолчанию: 1.75) — масштабирует интенсивность смещения волны внутри корпуса при событиях брызг.
• Ship Hull Height Type (по умолчанию: Small) — используйте Large для судов с высокими бортами. Варианты: Small, Medium, Large.

Частицы движения:

• Movement Particle Type (по умолчанию: Small) — используйте Small для маленьких лодок, Medium или Large для более крупных кораблей.
• Movement Particle Height Offset (по умолчанию: 0.34) — вертикальное смещение в метрах от вычисленной ватерлинии.
• Movement Particle Surface Distance Offset (по умолчанию: 0.7) — расстояние от поверхности корпуса для источников частиц.

Частицы брызг:

• Splash Particle Height Offset (по умолчанию: 0.4) — вертикальное смещение от ватерлинии для размещения частиц брызг.
• Splash Particle Surface Distance Offset (по умолчанию: 0.7) — расстояние от поверхности корпуса для источников частиц брызг.

Инструменты отладки редактора (только в редакторе, не влияют на финальные сборки игры):

• Reset Water Simulation Bounding Box — автоматически вычисляет ограничивающий объём на основе мешей render_to_depth.
• Re-render Depth Texture — принудительно перерендеривает текстуру глубины после изменения мешей render_to_depth.
• Reset In-Hull Water — сбрасывает симуляцию воды внутри корпуса в исходное состояние.
• Show Water Simulation Bounding Box — отображает ограничивающий объём во вьюпорте.
• Show Movement Particles / Show Splash Particles — отображает отладочные маркеры в каждом источнике частиц.
• Show Water Balance Plane — визуализирует вычисленную ватерлинию в виде красной плоскости.
• Show Wetness Decal Values / Force Wetness Decal To Full — инструменты для проверки размещения и непрозрачности декалей влажности.

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

2.3.4. ship_burning_system

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

a) Иерархия размещения частиц:

Префабы ship_burning_node отсортированы по определённым родительским сущностям, определяющим, где может появиться огонь. Эти родители должны существовать внутри сущности ship_burning_system:

• railing_parent: размещайте узлы горения вдоль поручней.
• ship_deck_parent: размещайте узлы горения в случайных позициях по открытой палубе.
• deck_upgrade_parent: размещайте узлы горения на и вокруг ассетов улучшений палубы.
• mast_parent: размещайте узлы горения на палубе в области под каждой мачтой.

b) Настройка BurningNode:

Каждый префаб ship_burning_node содержит скрипт BurningNode и дочерний элемент системы частиц.

• Node Index (критично): значение Node Index в скрипте BurningNode управляет порядком, в котором распространяется огонь. Назначьте последовательные уникальные целые числа (0, 1, 2, 3…) соседним узлам вдоль логического пути распространения — например, нумерация узлов поручней от кормы к носу заставит огонь визуально перемещаться вдоль поручней по порядку.
• Ограничение звука (важно): удалите все пути звуковых файлов из систем частиц, используемых внутри узлов горения. Система горения имеет собственное выделенное управление звуком через sound_parent. Оставление звуков на отдельных частицах вызывает множественные перекрывающиеся источники звука и громкий, некорректный звуковой ландшафт.

c) Освещение и звук:

• light_parent: содержит сущности точечного света. Разместите их рядом с скоплениями узлов горения, чтобы создать убедительное освещение от огня. Свет автоматически проявляется и затухает в зависимости от значений прогресса огня в скрипте ShipBurningSystem.
• sound_parent: содержит префабы burning_sound_node. Разместите от 2 до 6 таких узлов вокруг корабля в зависимости от его размера. Эти узлы запускают звуки огня только тогда, когда активны частицы огня в их непосредственной близости.

d) Скрипт ShipBurningSystem (корневые настройки):

• Start Fire / Stop Fire: кнопки редактора для предварительного просмотра полной последовательности горения без запуска игры.
• Spread Rate: контролирует, как быстро огонь распространяется по кораблю. Более высокие значения вызывают более быстрое, более агрессивное горение.
• All Fire Mode: активирует все частицы огня одновременно, полезно для визуальной проверки расположения узлов.
• Small Hit Debug: при включении наведитесь на корабль и нажмите среднюю кнопку мыши, чтобы симулировать небольшое локализованное попадание огня.
• Min/Max Fire Progress For Light: контролирует временную шкалу активации света.
  • Min: значение прогресса огня (0–1), при котором точечные источники света начинают проявляться.
  • Max: значение прогресса огня, при котором свет достигает пиковой интенсивности.
• Max Light Intensity: максимальное значение яркости, которого достигнет свет под light_parent при пиковой интенсивности огня.

2.3.5. rope_cosmetics_holder

Этот держатель содержит декоративные верёвки, которые завязаны между точками на корабле — такелажные линии, швартовочные канаты и другие атмосферные детали верёвок.

• Префаб: используйте simple_rope_nested для каждой верёвки. Разместите начальную и конечную дочерние сущности каждой верёвки в желаемых точках крепления на корабле.
• Настройка: отрегулируйте следующее через скрипт на начальной дочерней сущности:
  • fixed size: имеет ли верёвка фиксированную длину или провисает в зависимости от расстояния между конечными точками.
  • loose amount: насколько сильно верёвка провисает между своими конечными точками (глубина цепной кривой).
  • default length: естественная нерастянутая длина верёвки.
• Визуальные свойства: толщина верёвки, тайлинг текстуры в зависимости от длины и другие визуальные параметры управляются через пользовательские параметры меша (custom mesh parameters) материала на сущности верёвки.

2.3.6. brazier_holder

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

• Размещение: разместите префабы brazier_b или brazier_d как дочерние элементы под этим держателем в подходящих позициях вдоль краёв или палубы корабля. Теги предопределены на префабе — дополнительная настройка тегов не требуется.
• Можно разместить несколько жаровен, и их позиции должны быть доступны стоящим агентам без необходимости отходить далеко от своих боевых позиций.

2.3.7. ship_water_clip (система SDF)

Система SDF (Signed Distance Field, поле знаковых расстояний) предотвращает визуальное появление океанской воды внутри корпуса корабля — без неё поверхность моря проходила бы сквозь геометрию корпуса, что выглядело бы некорректно.

• Подготовка модели: создайте пользовательский 3D-меш, который точно следует внешней форме корпуса корабля ниже линии палубы, слегка выступая над уровнем палубы, чтобы создать герметичный объём. Этот меш определяет “сухую” внутреннюю зону.
• Соглашение об именовании: имя меша должно начинаться с префикса sdf_ (например, sdf_dromon). Движок автоматически обрабатывает любой меш с этим префиксом как данные SDF при импорте.

Настройка:

1. Добавьте префаб ship_water_clip в иерархию корабля.
2. Найдите скрипт signed_distance_field внутри этого префаба.
3. Назначьте подготовленный ассет меша SDF этому скрипту.

Проверка: включите флажок Visualize SDF в скрипте, чтобы увидеть поле, отображённое во вьюпорте редактора как цветной объём. Проверьте, что объём полностью охватывает внутреннюю часть корпуса ниже палубы.

2.3.8. deckwater (симуляция на основе карты высот)

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

• Ассет: требуется упрощённый меш “фальшивой палубы”. Этот меш используется для генерации текстуры глубины сверху вниз (карты высот), которую считывает симуляция.
• Настройка:
  1. Добавьте этот фальшивый меш палубы как дочернюю сущность под mesh_holder.
  2. Назначьте этой сущности тег render_to_depth. Система водных эффектов включит его (вместе со всеми другими объектами с тегом render_to_depth, такими как oar_seats и мебель палубы) в рендер глубины.
  3. После настройки перейдите к дочерней сущности ship_water_effects и нажмите Re-render Depth Texture в скрипте ShipWaterEffects, чтобы запечь текстуру глубины.
• Отладка: увеличьте значение Water Strength в окне Scene Options и включите Enable Physics в окне Visibility, чтобы наблюдать поведение симуляции воды на палубе в редакторе.

2.3.9. torch_holder

Этот держатель содержит фонари и факелы, обеспечивающие окружающее освещение на корабле ночью и в тёмных сценах.

• Префаб: добавьте nord_lantern_nested как дочерний элемент для каждой позиции источника света.
• Каждый префаб фонаря содержит:
  • collision_sphere: небольшую физическую сферу, используемую для взаимодействий коллизии (например, когда агенты задевают фонарь).
  • swinging_object: часть фонаря, которая физически качается в ответ на движение корабля. Назначьте тег swinging_entity этому дочернему элементу. Этот дочерний элемент содержит как сущность источника света, так и визуально покачивающийся меш фонаря.
  • nord_lantern_part_02: статичный монтажный кронштейн или цепь, которая не качается. Эта часть остаётся фиксированной относительно корабля.

2.3.10. knobs_holder

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

• Тег родителя: назначьте тег knob_points_parent самой сущности knobs_holder. Система парусов использует этот тег для определения всех доступных точек крепления верёвок на корабле.

Доступные префабы:

• bollard_a
  
• cleat_a
  
• belaying_pins_a
  
• belaying_pins_b
  
• Настройка: внутри каждого префаба есть дочерние сущности, служащие точными точками крепления концов верёвки. Назначьте тег knot_point каждой из этих дочерних сущностей. Вы можете дублировать и размещать столько префабов точек крепления, сколько требует ваш дизайн такелажа. Система парусов автоматически будет использовать ближайший knot_point для прокладки визуальных верёвок от контрольной кости каждого паруса.