diff --git a/docs/config.toml b/docs/config.toml index 90bc64fc..69ac2fe6 100644 --- a/docs/config.toml +++ b/docs/config.toml @@ -54,3 +54,53 @@ name = " Contribute on Git identifier = "blgithub" url = "https://github.com/TaleWorlds/Documentations" weight = 40 + +# Russian top-bar menu +[[languages.ru.menu.shortcuts]] +name = " Документация API" +identifier = "blapi" +url = "https://apidoc.bannerlord.com/" +weight = 10 + +[[languages.ru.menu.shortcuts]] +name = " Обсудить на форуме" +identifier = "blforums" +url = "https://forums.taleworlds.com/index.php?forums/the-smithy-mod-development.643/" +weight = 20 + +[[languages.ru.menu.shortcuts]] +name = " Обсудить в Discord" +identifier = "bldiscord" +url = "https://discord.gg/ykFVJGQ" +weight = 30 + +[[languages.ru.menu.shortcuts]] +name = " Участвовать на GitHub" +identifier = "blgithub" +url = "https://github.com/TaleWorlds/Documentations" +weight = 40 + +# Chinese top-bar menu +[[languages.zh_cn.menu.shortcuts]] +name = " API 文档" +identifier = "blapi" +url = "https://apidoc.bannerlord.com/" +weight = 10 + +[[languages.zh_cn.menu.shortcuts]] +name = " 论坛讨论" +identifier = "blforums" +url = "https://forums.taleworlds.com/index.php?forums/the-smithy-mod-development.643/" +weight = 20 + +[[languages.zh_cn.menu.shortcuts]] +name = " Discord 讨论" +identifier = "bldiscord" +url = "https://discord.gg/ykFVJGQ" +weight = 30 + +[[languages.zh_cn.menu.shortcuts]] +name = " 在 GitHub 上贡献" +identifier = "blgithub" +url = "https://github.com/TaleWorlds/Documentations" +weight = 40 diff --git a/docs/content/english/_index.md b/docs/content/english/_index.md index c52f249c..e1607484 100644 --- a/docs/content/english/_index.md +++ b/docs/content/english/_index.md @@ -101,7 +101,51 @@ Upload and update your mod on the Steam Workshop. - **[API Documentation](https://apidoc.bannerlord.com/)**: reference for the Bannerlord code base. - **[Mount & Blade Modding Discord](https://discord.gg/ykFVJGQ)**: ask questions and talk with other modders. -- **[Bannerlord Documentation (community)](https://docs.bannerlordmodding.com/)**: community-written guides, including Gauntlet UI and packaging mods for Vortex. -- **[BannerlordModding.LT (community)](https://docs.bannerlordmodding.lt/)**: a community wiki of modding processes, techniques and tips. +- **[Developer Workshop – Map Editor](https://www.youtube.com/watch?v=ovQiJfeQB8s)**: an official TaleWorlds stream showing how to work with the campaign map editor. - **[TaleWorlds Forums – The Smithy](https://forums.taleworlds.com/index.php?forums/the-smithy-mod-development.643/)**: the official mod development forum. - **[Contribute on GitHub](https://github.com/TaleWorlds/Documentations)**: suggest fixes or new pages for this documentation. + +## Community-Made Resources + +These resources are made and maintained by the community, not by TaleWorlds. Some were made for older game versions, so details may differ in the current version. + +### Documentation & Guides + +- **[Bannerlord Documentation](https://docs.bannerlordmodding.com/)**: community-written guides, including Gauntlet UI and packaging mods for Vortex. +- **[BannerlordModding.LT](https://docs.bannerlordmodding.lt/)**: a community wiki of modding processes, techniques and tips. +- **[Unofficial Bannerlord API Docs (BUTR)](https://bannerlordapi.butr.link/)**: API reference for each game version, generated from the game files. +- **[BUTR Documentation](https://butr.github.io/documentation)**: how-tos for Harmony debugging, crash reports and publishing mods with GitHub Actions. +- **[Documentation & Tutorials forum](https://forums.taleworlds.com/index.php?forums/documentation-tutorials.753/)**: tutorials shared by the community on the TaleWorlds Forums. + +### Community Guides (Google Docs) + +- **[3D Asset Workflow](https://docs.google.com/document/d/1aHBsO3mzkT0JsbCt9aCOh6CWAFATXwKtSaVb__TYIoo/edit)**: preparing 3D assets for Bannerlord. +- **[Asset Import Workflow](https://docs.google.com/document/d/11-J8HzS2FdnwwXfR7JmD_FQSQ6dWaJj_BZr1-vVW9Ks/edit)**: step-by-step workflow for importing assets. +- **[Importing Assets into BL Editor](https://docs.google.com/document/d/1ZnkRjNu6wUx3UM0exMiC8WhE8iDXPJKqYcbZdRh_q0o/edit)**: getting your assets into the Bannerlord editor. +- **[Importing Material Maps in Editor](https://docs.google.com/document/d/1843jpWFYLylJya1-_-wQpkemV58KT3EomEoqUYKpZTo/edit)**: importing textures and material maps. +- **[Basic World Mapping](https://docs.google.com/document/d/1npGJ9p1ySdu2RDU19P_2aE-OCsKWie_G02vcws36UIs/edit)**: an introduction to building your own campaign map. +- **[Adding Custom Scenes to Custom Battle](https://docs.google.com/document/d/1Rwsd9pdv5QA5s3K4oOuJX16_K9A5NaoWh0p78IcUi1w/edit)**: testing your own scenes in Custom Battle. +- **[Adding Flora to flora_kinds](https://docs.google.com/document/d/1VGpct-__3s6hn15GXHo5P1TS-yMrGfDxCed1UZ3AaNI/edit)**: registering new flora in flora_kinds. +- **[Bannerlord Layer Buttons, Options, and Settings](https://docs.google.com/document/d/1EiLvSZEJ_88fnva6d9s8H36XLH13YkVdim6jABe095s/edit)** (partly finished): what the editor's layer buttons, options and settings do. + +### Video Tutorials + +- **[Lesser Scholar – Artisan Workshop Mod](https://www.youtube.com/playlist?list=PLzebdAxJeltRwfJ8jzsNolgHkRvLjoCRC)**: a 19-part C# course covering setup, campaign behaviors, dialogs, Gauntlet UI, Harmony and publishing. +- **[A_Jannik](https://www.youtube.com/playlist?list=PLXLt7zu34iHFzZVDzZpvareujNqbJiypj)**: C# entry points, debugging and Harmony patching. +- **[Danqna & Gispry](https://www.youtube.com/watch?v=duvR9xFvu9Q)**: a 6-part C# series covering Visual Studio setup, dialogue, saving and MCM menus. +- **[Macbeth of Gondor](https://www.youtube.com/@MacbethofGondor)**: a 19-part Scene Editor series covering terrain, flora, navmesh, seasons, prefabs and barriers. +- **[Banner Lab](https://www.youtube.com/playlist?list=PLxhni8XI_dRDjRRDsCzEBZg4eUInzkzQT)**: XML modding without code: troops, items, cultures, kingdoms, heroes and settlements. +- **[Lykon Development](https://www.youtube.com/@LykonDevelopment/videos)**: XML troops, weapons and kingdoms, loading screens and weight painting in Blender. +- **[Adam Dotlačil](https://www.youtube.com/@enpremi)**: custom bows, crossbows and quivers, and hand animations for custom meshes. +- **[BabyLettuce – Skeletons & Races](https://www.youtube.com/watch?v=eXHd8yjoxk0)**: a full tutorial on custom skeletons and races. + +### Tools + +- **[Bannerlord Scene Toolkit](https://github.com/fiefevictionnotice/BannerlordSceneToolkit)** by FiefEvictionNotice: tools that run inside the Scene Editor for material swaps and recolors, prefab creation, distribution and mirroring, scene analysis and backups. See the [tutorial video](https://www.youtube.com/watch?v=f1uzZ-qQm3c). +- **[XBannerlord](https://forums.taleworlds.com/index.php?threads/tool-xbannerlord-an-ai-powered-xml-editor-for-bannerlord-mod-xmls.470278/)** by cookgreen: a Windows XML editor that shows Bannerlord XML files as a tree and lets you edit the selected node by chatting with an AI model. English and Chinese interface. [Source on GitHub](https://github.com/cookgreen/XBannerlord). +- **[Bannerlord Crafting Tool](https://github.com/haterade22/TAOM/releases/tag/crafting-tool-v1.0)** by haterade22: a Windows tool that previews weapon crafting pieces in 2D and 3D, so you can tune their offsets and check weapon length without launching the game. + +### Starter Packs + +- **[Campaign Map Prefab Starter Pack](https://www.nexusmods.com/mountandblade2bannerlord/mods/11608)** by Lemmy1916: a ready-to-use campaign map with pre-built settlements and scripts, to start a new world map. +- **[War Sails Campaign Map Prefab Starter Pack](https://www.nexusmods.com/mountandblade2bannerlord/mods/13602)** by Lemmy1916: the same starter map set up for War Sails. diff --git a/docs/content/russian/Asset Management/Asset Types/animations.md b/docs/content/russian/Asset Management/Asset Types/animations.md index 0d62dcbb..f25130ea 100644 --- a/docs/content/russian/Asset Management/Asset Types/animations.md +++ b/docs/content/russian/Asset Management/Asset Types/animations.md @@ -2,106 +2,107 @@ title = "Анимации" description = "" weight = 1 +ai_translated = true +++ -### Modding the Animation System +### Модификация системы анимаций -#### Exporting Animation for Bannerlord +#### Экспорт анимации для Bannerlord -##### Default Animation Settings +##### Настройки анимации по умолчанию -* Frame rate: 30 FPS(Optimal) or 60 FPS -* Humanoid or Creature Skeleton(Rig) Settings -* Max supported bone count: 64 -* Bones that are not used should contain “_notused” at the end of the string. Also root bone (highest bone in the hierarchy) should contain this only for the animations. +* Частота кадров: 30 FPS (оптимально) или 60 FPS +* Настройки гуманоидного или звериного скелета (Rig) +* Максимальное поддерживаемое количество костей: 64 +* Кости, которые не используются, должны содержать «_notused» в конце строки. Также корневая кость (самая верхняя в иерархии) должна содержать это только для анимаций.  -##### FBX export settings (Autodesk Maya) -These settings are applied to Maya. Similar kind of software might contain the same settings. When we export the new rig for the first time, the exported FBX file should contain the skeleton and the mesh. +##### Настройки экспорта FBX (Autodesk Maya) +Эти настройки применяются в Maya. Похожее программное обеспечение может содержать такие же настройки. Когда мы экспортируем новый риг впервые, экспортированный FBX-файл должен содержать скелет и меш. -##### First time setup (Skeleton + Mesh) +##### Первоначальная настройка (скелет + меш)   -##### Exporting Animation Only Settings -We make sure to disable mesh and skin related options before we export the animations. ”Use scene name” is very important to check when exporting for both animations and rigs. Also make sure that the root bone contains “_notused” at the end of the string. +##### Настройки экспорта только анимации +Мы обязательно отключаем параметры, связанные с мешем и скином, перед экспортом анимаций. «Use scene name» очень важно проверить при экспорте как анимаций, так и ригов. Также убедитесь, что корневая кость содержит «_notused» в конце строки.  -We make sure that we don’t send any kind of “Constraints and Skeleton Definitions”. Constraints, Connections and Unit settings should be set as the image below. Our engine also uses the “Z” as the up axis. +Мы убеждаемся, что не отправляем никаких «Constraints and Skeleton Definitions» (ограничений и определений скелета). Constraints, Connections и Unit settings должны быть установлены так, как на изображении ниже. Наш движок также использует ось «Z» в качестве направления вверх.  -##### Defining New Animations -After exporting your animation, to reference it in the game, you need to add new animation clips from the resources browser which references that animation. To do so, you should use the "Animation Clip" button inside the " Create" parent build. Most important properties of these clips are: - -* id: ID(unique name) of the anim clip to be used in other systems -* source1: Start keyframe of the animation clip -* source2: End keyframe of the animation clip -* anim_data_name: The source animation resource that was imported to the engine for this clip -* duration: Duration of this animation clip in seconds - -A typical animation contains some optional attributes as well. Most common one is blend_in_period, which sets the duration for blending to the existing animation and reaching 100% weight. blend_out_period is the opposite of this blending, but it has an important difference. Blending out actually means that the animation ends earlier than the given duration, and the rest of the animation will only be used for blending out to another animation. But blend duration is only set by blend_in_period. Having a longer blend_out_period than the next animation’s blend_in_period doesn’t extend this blend duration. It just helps the blend to look smoother, since during that blend, if both animations play at the same time, it looks visually more appealing. An animation with 0 blend_out_period simply pauses during the blending to the next animation, and it causes a sudden stop/velocity change in bone rotations. - -An animation has several more optional attributes: - -* priority: Priority simply allows/disallows animations to be played as an interrupt while another animation is in progress. Higher priority animations are played over lower or equal priorities as interrupts. -* param1, param2, param3: Params are used in cases when the engine requires additional data. They may have quite different meanings. -* sound_code: Plays a sound when the animation is played. -* step_points: These are step points for sound. -* voice_code: Plays a voice when the animation is played. -* facial_anim_id: Morphs the face to this when the animation is played. -* left_hand_pose, right_hand_pose: These morph the hands to their values when the animation is played. -* combat_parameter_id: This gives an additional set of information to the engine (see combat_parameters.xml) -* blends_with_action: This attribute references another action (warning: action, not animation) to blend the animation with. This is valid only when the engine requires two animations to be blended with (i.e. shield blocking up/down, weapon swings requiring balanced and unbalanced versions etc.). -* continue_to_action: This attribute calls another action (warning: action, not animation) to be played soon after this animation is finished. Animation is considered to be finished always when the duration (blend_out_period) is reached. - -Animations usually contain two other nodes: flags and clip_usage_data. clip_usage_data is a common data pointer that may refer to blend_data, displacement_data, bipedal_movement_and_ik_data, and quadrupedal_movement_data. Their usage is mostly for specific cases and their details are out of this explanation’s scope. Flags are used for nearly all animations though and require some explanation. Possible flags that can be used for an animation are: - -* disable_agent_agent_collisions: Disables collisions between agents. -* ignore_all_collisions: Disables all collisions. -* Ignore_static_body_collisions: Disables collisions with static bodies. -* use_last_step_point_as_data: 4th step point is considered as data instead of a sound point. -* make_bodyfall_sound: Creates a fall sound when the body touches the ground. -* client_prediction: Prevents animations from being sent through the network. -* keep: Doesn’t end the animation when it is finished and keeps it as paused instead. -* restart: Forces the animation to start from the beginning if the same animation is already being played by that skeleton. -* client_owner_prediction: Prevents animations from being sent through the network only for the agents that are controlled by that client. -* make_walk_sound: Plays hardcoded walk sounds. -* disable_hand_ik: Prevents hand inverse kinematics to be applied during the animation. -* blends_according_to_look_slope: Allows animation to be blended with another animation according to the look slope, with this one being downward. -* synch_with_horse: Plays the animation without using its original duration, it instead matches the progress with the mount’s animation. -* use_left_hand_during_attack: Allows the combat system to check the left hand as the collider during an attack. -* lock_camera: Prevents players from controlling the camera during this animation. -* lock_movement: Prevents agents to move during this animation. -* synch_with_movement: Plays the animation without using its original duration, it instead matches the progress with the agent’s movement animations. -* enable_hand_spring_ik: Allows a spring-like inverse kinematics to be applied to hands for applying lower body movement’s forces on them. -* enable_hand_blend_ik: Allows inverse kinematics to try to keep the hands a bit at the starting location when this animation starts by blending the original position and the animation position. -* synch_with_ladder_movement: Plays the animation without using its original duration, it instead matches the progress with the agent’s movement on the ladder. -* do_not_keep_track_of_sound: Prevents engine from holding a reference to a sound when it is played. -* reset_camera_height: Reduces the additional camera height for this animation. -* disable_auto_increment_progress: Prevents the animation from being played and keeps it paused at the current progress instead. Progress might have to be set manually from the code. -* enforce_lowerbody: Prevents previous channel and movement animations to be played during this animation. -* enforce_all: Valid for channel 0 only. Prevents channel 1 and movement animations to be played during this animation. -* cyclic: Animation loops and never ends. -* enforce_root_rotation: Abdomen (root) rotation is taken from this animation instead of the previous channel or movement animation for internal calculations. -* allow_head_movement: Allows agent’s head to move according to look direction. -* disable_foot_ik: Disables foot inverse kinematics for this animation. -* affected_by_movement: Allows movement adder animations to be added on top of this animation to give a better shaky feeling. -* update_bounding_volume: Disables bounding box optimization, should be used when the agent moves outside its regular boundaries with this animation. -* align_with_ground: Aligns agent's frame with the ground during this animation. -* ignore_slope: Prevents quadruped agents to align with the ground during this animation. -* displace_position: Updates world position of the agent during the animation using the displacement data. -* enable_left_hand_ik: Forces the left hand to stay on this animation’s target frame even during blending with other animations using inverse kinematics. -* ignore_scale_on_root_position: Allows abdomen (root) position to stay at the same position with the original scale, allowing the agents to interact with objects better. -* randomization_weight: Randomizes the animation inside its alternative group with this value. Higher value allows the animation to be selected more frequently. - -##### Modifying/Adding New Actions -Agent animations are mapped to action sets as actions. In order to set a new animation to an existing action, first you need to define a new animation clip through the resource browser. Animation clips define the animation start and end seconds, FPS and various properties. Then you need to map it under action_sets.xml for the specific action set. If a new action is needed to be created, first you need to add it as a new line under action_types.xml, and then do the same steps above. - -Non-agent animations are not mapped as actions. For those, you just need to add the animation clips through the resource browser and then start using it in the code. - -Each action has several attributes. These attributes are hardcoded so that the engine can understand certain properties of the action. The attributes are: - -type (default: actt_other): +##### Определение новых анимаций +После экспорта анимации, чтобы сослаться на неё в игре, вам нужно добавить новые клипы анимации из браузера ресурсов, которые ссылаются на эту анимацию. Для этого используйте кнопку «Animation Clip» внутри родительской сборки «Create». Самые важные свойства этих клипов: + +* id: ID (уникальное имя) клипа анимации, используемого в других системах +* source1: Начальный ключевой кадр клипа анимации +* source2: Конечный ключевой кадр клипа анимации +* anim_data_name: Исходный ресурс анимации, импортированный в движок для этого клипа +* duration: Продолжительность этого клипа анимации в секундах + +Типичная анимация также содержит несколько опциональных атрибутов. Самый распространённый — blend_in_period, который задаёт продолжительность смешивания с существующей анимацией и достижения 100% веса. blend_out_period — это противоположность этому смешиванию, но с важным отличием. Смешивание на выходе на самом деле означает, что анимация заканчивается раньше заданной продолжительности, а оставшаяся часть анимации используется только для смешивания с другой анимацией. Но продолжительность смешивания задаётся только через blend_in_period. Наличие более длинного blend_out_period, чем blend_in_period следующей анимации, не увеличивает эту продолжительность смешивания. Это просто помогает смешиванию выглядеть более плавным, так как во время этого смешивания, если обе анимации проигрываются одновременно, это выглядит визуально более привлекательно. Анимация с 0 blend_out_period просто приостанавливается во время смешивания со следующей анимацией, что вызывает резкую остановку/изменение скорости во вращениях костей. + +Анимация имеет ещё несколько опциональных атрибутов: + +* priority: Priority просто разрешает/запрещает проигрывание анимаций в качестве прерывания, пока проигрывается другая анимация. Анимации с более высоким приоритетом проигрываются поверх анимаций с более низким или равным приоритетом в качестве прерываний. +* param1, param2, param3: Параметры используются в случаях, когда движку требуются дополнительные данные. Они могут иметь совершенно разное значение. +* sound_code: Проигрывает звук при проигрывании анимации. +* step_points: Это точки шага для звука. +* voice_code: Проигрывает голос при проигрывании анимации. +* facial_anim_id: Преобразует лицо в это выражение при проигрывании анимации. +* left_hand_pose, right_hand_pose: Преобразуют позы рук в заданные значения при проигрывании анимации. +* combat_parameter_id: Передаёт движку дополнительный набор информации (см. combat_parameters.xml) +* blends_with_action: Этот атрибут ссылается на другое действие (внимание: действие, а не анимация), с которым нужно смешать анимацию. Это актуально только тогда, когда движку требуется смешать две анимации (например, поднятие/опускание блока щитом, взмахи оружием, требующие сбалансированной и несбалансированной версий и т. д.). +* continue_to_action: Этот атрибут вызывает другое действие (внимание: действие, а не анимация), которое проигрывается вскоре после завершения этой анимации. Анимация считается завершённой всегда, когда достигается продолжительность (blend_out_period). + +Анимации обычно содержат два других узла: flags и clip_usage_data. clip_usage_data — это общий указатель на данные, который может ссылаться на blend_data, displacement_data, bipedal_movement_and_ik_data и quadrupedal_movement_data. Их использование в основном предназначено для специфических случаев, и их детали выходят за рамки данного объяснения. Флаги же используются практически для всех анимаций и требуют некоторого объяснения. Возможные флаги, которые можно использовать для анимации: + +* disable_agent_agent_collisions: Отключает столкновения между агентами. +* ignore_all_collisions: Отключает все столкновения. +* Ignore_static_body_collisions: Отключает столкновения со статическими телами. +* use_last_step_point_as_data: 4-я точка шага считается данными, а не звуковой точкой. +* make_bodyfall_sound: Создаёт звук падения, когда тело касается земли. +* client_prediction: Предотвращает отправку анимаций через сеть. +* keep: Не завершает анимацию по окончании, а оставляет её на паузе. +* restart: Принудительно запускает анимацию с начала, если та же анимация уже проигрывается этим скелетом. +* client_owner_prediction: Предотвращает отправку анимаций через сеть только для агентов, управляемых этим клиентом. +* make_walk_sound: Проигрывает жёстко закодированные звуки ходьбы. +* disable_hand_ik: Предотвращает применение обратной кинематики рук во время анимации. +* blends_according_to_look_slope: Позволяет смешивать анимацию с другой анимацией в зависимости от угла наклона взгляда, причём эта является нисходящей. +* synch_with_horse: Проигрывает анимацию без использования её исходной продолжительности, вместо этого синхронизируя прогресс с анимацией коня. +* use_left_hand_during_attack: Позволяет боевой системе проверять левую руку как коллайдер во время атаки. +* lock_camera: Предотвращает управление камерой игроком во время этой анимации. +* lock_movement: Предотвращает движение агентов во время этой анимации. +* synch_with_movement: Проигрывает анимацию без использования её исходной продолжительности, вместо этого синхронизируя прогресс с анимациями движения агента. +* enable_hand_spring_ik: Позволяет применять пружинную обратную кинематику к рукам для передачи на них сил движения нижней части тела. +* enable_hand_blend_ik: Позволяет обратной кинематике пытаться удерживать руки немного в начальном положении при старте этой анимации, смешивая исходное положение и положение анимации. +* synch_with_ladder_movement: Проигрывает анимацию без использования её исходной продолжительности, вместо этого синхронизируя прогресс с движением агента по лестнице. +* do_not_keep_track_of_sound: Предотвращает удержание движком ссылки на звук, когда он проигрывается. +* reset_camera_height: Уменьшает дополнительную высоту камеры для этой анимации. +* disable_auto_increment_progress: Предотвращает проигрывание анимации и удерживает её на паузе на текущем прогрессе. Прогресс может потребоваться устанавливать вручную из кода. +* enforce_lowerbody: Предотвращает проигрывание предыдущего канала и анимаций движения во время этой анимации. +* enforce_all: Актуально только для канала 0. Предотвращает проигрывание канала 1 и анимаций движения во время этой анимации. +* cyclic: Анимация зацикливается и никогда не заканчивается. +* enforce_root_rotation: Вращение живота (корня) берётся из этой анимации вместо предыдущего канала или анимации движения для внутренних расчётов. +* allow_head_movement: Позволяет голове агента двигаться в соответствии с направлением взгляда. +* disable_foot_ik: Отключает обратную кинематику ног для этой анимации. +* affected_by_movement: Позволяет накладывать анимации-добавки движения поверх этой анимации для создания более качественного эффекта тряски. +* update_bounding_volume: Отключает оптимизацию ограничивающего объёма, следует использовать, когда агент выходит за пределы своих обычных границ с этой анимацией. +* align_with_ground: Выравнивает систему координат агента с землёй во время этой анимации. +* ignore_slope: Предотвращает выравнивание четвероногих агентов с землёй во время этой анимации. +* displace_position: Обновляет мировую позицию агента во время анимации, используя данные смещения. +* enable_left_hand_ik: Заставляет левую руку оставаться в целевой позиции этой анимации даже во время смешивания с другими анимациями с помощью обратной кинематики. +* ignore_scale_on_root_position: Позволяет позиции живота (корня) оставаться в том же положении с исходным масштабом, позволяя агентам лучше взаимодействовать с объектами. +* randomization_weight: Рандомизирует анимацию внутри её альтернативной группы с этим значением. Более высокое значение позволяет анимации выбираться чаще. + +##### Изменение/добавление новых действий +Анимации агентов сопоставляются с наборами действий (action sets) как действия (actions). Чтобы назначить новую анимацию существующему действию, сначала нужно определить новый клип анимации через браузер ресурсов. Клипы анимации определяют начальную и конечную секунды анимации, FPS и различные свойства. Затем нужно сопоставить его в action_sets.xml для конкретного набора действий. Если необходимо создать новое действие, сначала нужно добавить его как новую строку в action_types.xml, а затем выполнить те же шаги, что и выше. + +Анимации, не относящиеся к агентам, не сопоставляются как действия. Для них просто нужно добавить клипы анимации через браузер ресурсов, а затем начать использовать их в коде. + +Каждое действие имеет несколько атрибутов. Эти атрибуты жёстко закодированы, чтобы движок мог понимать определённые свойства действия. Атрибуты: + +type (по умолчанию: actt_other): * actt_other, * actt_defend_fist, @@ -153,7 +154,7 @@ type (default: actt_other): * actt_strike_knock_back, * actt_mount_strike -usage_direction (optional): +usage_direction (опционально): * ud_attack_up, * ud_attack_down, @@ -167,7 +168,7 @@ usage_direction (optional): * ud_attack_any -action_stage (optional): +action_stage (опционально): * as_attack_ready, * as_attack_quick_ready, @@ -178,10 +179,9 @@ action_stage (optional): * as_defend_parry -Using the modified actions is pretty straightforward, you just need to change the action to animation mapping under action_sets.xml and that will probably be enough. But if you want to create a new action, or create a new behavior for an existing action, possible ways of integrating it within the game would be: - -* Calling the action from the code: Agent class has the necessary functions to do that. For performance reasons, make sure to cache the index of the action using the ActionIndexCache class. -* Using it in movement_sets.xml: This file contains two sets: movement_sets and full_movement_sets. A movement_set contains all the animations required for a character to move in all directions in a single stance and state. A full_movement_set contains a group of movemen_sets in order to satisfy all stances and all states: walking, running, crouch walking and crouch running with left and right stances. Please keep in mind that crouch does not have a left stance, and as such some weapon usages enforce only right stance to be used in all cases (i.e. ranged weapons in Native). full_movement_sets contain their conditions as attributes: left_stance and movement_mode. -* Using it in item_usage_sets.xml: new combat actions should be given from here as long as they don't require a combat system change. Idle, guard, weapon usage, kick usage actions can be set from here for every item with certain conditions. In addition to that the actions defined under movement_sets.xml are also referenced from here. There are too many conditions and attributes for the usage_sets to explain them here, but the existing examples should help you understand how everything works. One important and not so straightforward detail is that, all of the usages defined here are traversed from top to bottom, and the first usage that satisfies the condition is used. So it is important to keep the usages that have more limits at the top of the list, and fallback usages at the bottom. -* Using it in monster_usage_sets.xml: Just like item_usage_sets.xml, this file contains possible actions that agents can do without depending on an item type. Those can be strikes, jumps, falls and mountings. For quadruped agents there are a few more possibilities: upper_body_movements, movements and movement_adders. This file requires a closer explanation, but its structure is similar to item_usage_sets.xml and the examples shown there should be self explanatory. Again for all cases, usages are traversed from the top and first usage that satisfies the conditions is used. Since the conditions vary a lot for different conditions of actions, sometimes a condition can be used outside of its meaning (i.e. meaning of is_heavy becomes a speed condition for quadruped falls and strikes). And some directions may not be applied for certain conditions (some actions check 4 directions, some check front_left and front_right instead of front, and some check only cross directions: front_left, front_right, back_left and back_right), so it is advised that you experiment a bit if you try to go beyond what the Native code gives you. For the full possible body_parts, please check bone_body_types.xml, which mainly holds some attributes for body parts related to combat collision checks. +Использование изменённых действий довольно простое — вам просто нужно изменить сопоставление действия с анимацией в action_sets.xml, и этого, вероятно, будет достаточно. Но если вы хотите создать новое действие или новое поведение для существующего действия, возможные способы интеграции его в игру могут быть следующими: +* Вызов действия из кода: класс Agent имеет необходимые функции для этого. Из соображений производительности обязательно кэшируйте индекс действия с помощью класса ActionIndexCache. +* Использование в movement_sets.xml: этот файл содержит два набора: movement_sets и full_movement_sets. movement_set содержит все анимации, необходимые персонажу для движения во всех направлениях в одной стойке и состоянии. full_movement_set содержит группу movement_set, чтобы удовлетворить все стойки и все состояния: ходьба, бег, ходьба и бег в приседе с левой и правой стойкой. Пожалуйста, учтите, что присед не имеет левой стойки, и поэтому некоторые варианты использования оружия предписывают использовать только правую стойку во всех случаях (например, дальнобойное оружие в Native). full_movement_sets содержат свои условия в виде атрибутов: left_stance и movement_mode. +* Использование в item_usage_sets.xml: новые боевые действия следует задавать отсюда, если они не требуют изменения боевой системы. Простой, стража, использование оружия, действия удара ногой можно задать отсюда для каждого предмета с определёнными условиями. Кроме того, действия, определённые в movement_sets.xml, также упоминаются отсюда. Для usage_sets существует слишком много условий и атрибутов, чтобы объяснять их здесь, но существующие примеры должны помочь вам понять, как всё работает. Одна важная и не самая очевидная деталь заключается в том, что все варианты использования, определённые здесь, обходятся сверху вниз, и используется первый вариант, удовлетворяющий условию. Поэтому важно держать варианты с большим количеством ограничений в верхней части списка, а резервные варианты — внизу. +* Использование в monster_usage_sets.xml: как и item_usage_sets.xml, этот файл содержит возможные действия, которые агенты могут выполнять независимо от типа предмета. Это могут быть удары, прыжки, падения и посадки верхом. Для четвероногих агентов есть ещё несколько возможностей: upper_body_movements, movements и movement_adders. Этот файл требует более подробного объяснения, но его структура похожа на item_usage_sets.xml, и примеры, показанные там, должны быть понятны сами по себе. Опять же, во всех случаях варианты использования обходятся сверху, и используется первый, удовлетворяющий условиям. Поскольку условия сильно различаются для разных состояний действий, иногда условие может использоваться вне своего смысла (например, значение is_heavy становится условием скорости для падений и ударов четвероногих). А некоторые направления могут не применяться для определённых условий (некоторые действия проверяют 4 направления, некоторые проверяют front_left и front_right вместо front, а некоторые проверяют только перекрёстные направления: front_left, front_right, back_left и back_right), поэтому рекомендуется немного поэкспериментировать, если вы пытаетесь выйти за рамки того, что даёт вам код Native. Полный список возможных body_parts можно найти в bone_body_types.xml, который в основном содержит некоторые атрибуты для частей тела, связанных с проверками боевых столкновений. diff --git a/docs/content/russian/Asset Management/Asset Types/shaders.md b/docs/content/russian/Asset Management/Asset Types/shaders.md new file mode 100644 index 00000000..c59c3c40 --- /dev/null +++ b/docs/content/russian/Asset Management/Asset Types/shaders.md @@ -0,0 +1,17 @@ ++++ +title = "Шейдеры" +description = "" +weight = 1 +ai_translated = true ++++ + +Шейдеры — это программные фрагменты, которые выполняются на ядрах GPU. Они определяют методы рендеринга. + +##### Флаги материального шейдера и комбинации шейдеров +Шейдеры определяют флаги материала, которые можно настраивать для каждого материала. Каждый флаг материального шейдера изменяет часть кода шейдера, чтобы изменить внешний вид материала. Например, при включении флага "USE_PROCEDURAL_WIND_ANIMATION" материал начинает анимироваться по фиксированной оси в зависимости от ветра в сцене. + +##### Кэш шейдеров +Каждый материал определяет новую комбинацию флагов шейдера, что, в свою очередь, определяет новый код шейдера, который необходимо скомпилировать. Игра поставляется с кэшем шейдеров, который содержит все уникальные комбинации шейдер + флаги материального шейдера, присутствующие в базовой игре. + +##### Массовая компиляция шейдеров для модов +Если модуль добавляет значительное количество новых комбинаций, компиляция шейдеров во время выполнения (runtime) может существенно нарушить ход игры. Чтобы избежать этого, владельцу мода следует скомпилировать уникальные комбинации шейдер + материал, введённые в этом модуле. Для этого во время публикации модуля через функцию "Publish Module" в редакторе должен быть отмечен флажок "Compile Shaders". Кэш шейдеров будет сохранён в папку "Modules/'ModuleName'/Shaders/D3D11". Обратите внимание, что игровые шейдеры могут изменяться в некоторых обновлениях версий, хотя это происходит не очень часто; в таких случаях старый файл кэша шейдеров станет недействительным и использоваться не будет. Чтобы избежать этого, рекомендуется пересоздавать кэш шейдеров перед каждой загрузкой нового мажорного обновления игры. Система компиляции шейдеров в значительной степени распараллелена и может завершить работу примерно за 30–60 минут, в зависимости от многоядерной производительности процессора. diff --git a/docs/content/russian/Asset Management/how_to_add_custom_fonts.md b/docs/content/russian/Asset Management/how_to_add_custom_fonts.md index 0195c154..811ed1a7 100644 --- a/docs/content/russian/Asset Management/how_to_add_custom_fonts.md +++ b/docs/content/russian/Asset Management/how_to_add_custom_fonts.md @@ -1,162 +1,154 @@ +++ -title = "Как добавить собственные шрифты" +title = "Как добавить пользовательские шрифты" weight = 15 +ai_translated = true +++ -#### Вступление -В этой документации будут выполняться следующие шаги: +#### Введение + +Этот документ проведёт вас через следующие шаги: * Настройка файлов и путей * Генерация шрифтов * Размещение файлов в папке модуля -* Создание таблиц спрайтов +* Генерация спрайт-листов (Sprite Sheets) * Как использовать шрифты в Bannerlord -#### Предварительные условия +#### Предварительные требования -* TrueTypeFont file for the font. E.g. (OpenSans-Regular.ttf) -* Mount & Blade II: Bannerlord - Modding Kit downloaded from steam -* Knowledge on generating UI Spritesheets (see: [Generating and Loading UI Sprite Sheets]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}})) +* Файл TrueTypeFont для шрифта. Например (OpenSans-Regular.ttf) +* Mount & Blade II: Bannerlord - Modding Kit, загруженный из Steam +* Знания о генерации UI-спрайт-листов (см.: [Generating and Loading UI Sprite Sheets]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}})) #### Настройка файлов и путей -* Go to Mount & Blade II Bannerlord\GUI\GauntletUI\Fonts\. -* Make sure the two files below exist in the directory. We will use them to generate our font data. +* Перейдите в Mount & Blade II Bannerlord\GUI\GauntletUI\Fonts\. +* Убедитесь, что в каталоге присутствуют два файла ниже. Мы будем использовать их для генерации наших данных шрифта. * **GenerateFont.bat** * **GenerateFontSettings.txt** -* Move your **.ttf** font file to the directory. -* For our example, we will use a font file named **OpenSansRegular.ttf**. -* Open the file: "**GenerateFontSettings.txt**". -* "**GenerateFontSettings.txt**" default values are: - -```text --fontpath {FONT\_PATH.ttf} --outputpath {OUTPUT\_PATH.png} --atlassize 2048 2048 --size 64 --angle 8 --range 16 --padding 16 --smooth 0 --smoothingConstant 0.5-mode 1 -``` - -* Here, we need to change the placeholder variables **{FONT\_PATH.ttf}** and **{OUTPUTPATH.png}** with actual paths. -* The paths here are relative to the directory: **…\bin\Win64_Shipping_wEditor** directory unless you specify a full path. -* Please note that if you want to use paths that contain spaces, you need to put them inside quotes. -* Setting -fontpath: - * In our example, the variable should be: **-fontpath OpenSansRegular.ttf**. -* Setting -outputpath: - * This variable determines where the **.png** file should be placed. We should use a **.png** file path to a non-existent file which will be created in the process of generating atlas. - * In our example we set the -outputpath variable as: **-outputpath OpenSansRegular.png**. -* The contents of **GenerateFontSettings.txt** should now look like this: - -```text --fontpath OpenSansRegular.ttf --outputpath OpenSansRegular.png --atlassize 2048 2048 --size 64 --angle 8 --range 16 --padding 16 --smooth 0 --smoothingConstant 0.5-mode 1 -``` +* Переместите файл вашего шрифта **.ttf** в этот каталог. +* В нашем примере мы будем использовать файл шрифта под названием **OpenSansRegular.ttf**. +* Откройте файл: "**GenerateFontSettings.txt**". +* Значения по умолчанию для "**GenerateFontSettings.txt**": + + -fontpath {FONT\_PATH.ttf} + -outputpath {OUTPUT\_PATH.png} + -atlassize 2048 2048 + -size 64 + -angle 8 + -range 16 + -padding 16 + -smooth 0 + -smoothingConstant 0.5-mode 1 + +* Здесь нам нужно заменить переменные-заполнители **{FONT\_PATH.ttf}** и **{OUTPUTPATH.png}** на фактические пути. +* Пути здесь указываются относительно каталога: **…\bin\Win64_Shipping_wEditor**, если вы не указываете полный путь. +* Обратите внимание, что если вы хотите использовать пути, содержащие пробелы, вам нужно заключить их в кавычки. +* Настройка -fontpath: + * В нашем примере переменная должна быть: **-fontpath OpenSansRegular.ttf**. +* Настройка -outputpath: + * Эта переменная определяет, куда должен быть помещён файл **.png**. Мы должны использовать путь к файлу **.png**, который ещё не существует и будет создан в процессе генерации атласа. + * В нашем примере мы устанавливаем переменную -outputpath как: **-outputpath OpenSansRegular.png**. +* Содержимое **GenerateFontSettings.txt** теперь должно выглядеть так: + + -fontpath OpenSansRegular.ttf + -outputpath OpenSansRegular.png + -atlassize 2048 2048 + -size 64 + -angle 8 + -range 16 + -padding 16 + -smooth 0 + -smoothingConstant 0.5-mode 1 _Если сгенерированный файл .png не содержит всех символов для вашего шрифта, рассмотрите возможность увеличения_ **-atlassize**. #### Генерация шрифтов -* Теперь, когда файлы добавлены и установлены правильные пути для генератора, запустите **GenerateFont.bat**. -* Если все настроено правильно, программа не выдаст никаких ошибок и сгенерирует 3 файла в каталоге, который вы определили в **-outputpath**. - * В нашем примере это 3 файла: +* Теперь, когда файлы добавлены и правильные пути для генератора настроены, запустите **GenerateFont.bat**. +* Если всё настроено правильно, программа не выдаст никаких ошибок и сгенерирует 3 файла в каталоге, который вы определили как ваш **-outputpath**. + * В нашем примере эти 3 файла: * **OpenSansRegular.fnt** * **OpenSansRegular.bfnt** * **OpenSansRegular.png** -* If you see any errors in the batch script, make sure that the **-fontpath** and **-outputpath** variables are set correctly. -* В нашем примере 3 сгенерированных файла расположены в каталоге **...\bin\Win64_Shipping_wEditor**, поскольку мы указываем относительный путь. +* Если вы видите какие-либо ошибки в скрипте bat-файла, убедитесь, что переменные **-fontpath** и **-outputpath** заданы правильно. +* В нашем примере 3 сгенерированных файла находятся в каталоге **…\bin\Win64_Shipping_wEditor\**, поскольку мы указали относительный путь. #### Размещение файлов в папке модуля -* На предыдущем шаге мы создали 3 файла. Теперь нам нужно поместить эти файлы в наш модуль. +* На предыдущем шаге мы сгенерировали 3 файла. Теперь нам нужно разместить эти файлы в нашем модуле. ##### Файлы шрифтов -* Go to **{YOURMODULE}\GUI\Fonts** folder. If your module doesn't have a **Fonts** folder, create it. -* Move the generated **.fnt** and **.bfnt** files to the **Fonts** folder, in our example they are named **OpenSansRegular.fnt** and **OpenSansRegular.bfnt**. +* Перейдите в папку **{YOURMODULE}\GUI\Fonts**. Если в вашем модуле нет папки **Fonts**, создайте её. +* Переместите сгенерированные файлы **.fnt** и **.bfnt** в папку **Fonts**; в нашем примере они называются **OpenSansRegular.fnt** и **OpenSansRegular.bfnt**. ##### Файл изображения -* Go to **{YOURMODULE}\GUI\SpriteParts** folder. If your module doesn't have any **GUI** or **SpriteParts** folders, create them. -* In the **SpriteParts** folder, create an empty folder named **ui\_custom\_fonts**. -* If you don't have a **Config.xml** in your **SpriteParts** folder, create it too. -* At this stage, **SpriteParts** folder should have a folder named **ui\_custom\_fonts** and a file named **Config.xml**. -* Now we can move our **.png** file to the ui\_custom\_fonts folder. In our example, the file is named **OpenSansRegular.png**. +* Перейдите в папку **{YOURMODULE}\GUI\SpriteParts**. Если в вашем модуле нет папок **GUI** или **SpriteParts**, создайте их. +* В папке **SpriteParts** создайте пустую папку с названием **ui\_custom\_fonts**. +* Если у вас нет файла **Config.xml** в папке **SpriteParts**, создайте и его. +* На этом этапе папка **SpriteParts** должна содержать папку с названием **ui\_custom\_fonts** и файл с названием **Config.xml**. +* Теперь мы можем переместить наш файл **.png** в папку ui\_custom\_fonts. В нашем примере файл называется **OpenSansRegular.png**. ##### Конфигурация -* Чтобы иметь возможность использовать наш шрифт в игре, нам нужно указать в нашем **Config.xml** файле, что наш шрифт должен загружаться автоматически. +* Чтобы иметь возможность использовать наш шрифт в игре, нам нужно указать в нашем файле **Config.xml**, что наш шрифт должен загружаться автоматически. * Содержимое Config.xml должно включать этот конфиг: -```xml - - - - - - - - -``` + + + + + + + + -* Note that **ui\_custom\_fonts** here comes from the name of the folder you created in **{YOURMODULE}\GUI\SpriteParts**. +* Обратите внимание, что **ui\_custom\_fonts** здесь взято из названия папки, которую вы создали в **{YOURMODULE}\GUI\SpriteParts**. -#### Генерация таблиц спрайтов +#### Генерация спрайт-листов -* Теперь необходимо сгенерировать таблицы спрайтов шрифта, используя файл **.png**, созданный в последнем процессе. -* Мы кратко расскажем, как добавить новый шрифт в таблицы спрайтов. Подробное объяснение см. [Generating and Loading UI Sprite Sheets]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}}). - * Запустите генератор таблицы спрайтов, просто запустив **Mount & Blade II Bannerlord\bin\Win64\_Shipping\_wEditor\TaleWorlds.TwoDimension.SpriteSheetGenerator.exe**. - * Если все было настроено правильно, вывод генератора таблицы спрайтов должен выглядеть так: - - * Вы должны импортировать шрифт через браузер ресурсов в игре. Что было объяснено в [документе]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}}) выше. +* Теперь необходимо сгенерировать спрайт-листы шрифта, используя файл **.png**, созданный в предыдущем процессе. +* Мы вкратце рассмотрим, как добавить ваш новый шрифт в спрайт-листы. Подробное объяснение см. здесь: [Generating and Loading UI Sprite Sheets]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}}). + * Запустите генератор спрайт-листов, просто запустив **Mount & Blade II Bannerlord\bin\Win64\_Shipping\_wEditor\TaleWorlds.TwoDimension.SpriteSheetGenerator.exe**. + * Если всё было настроено правильно, результат работы генератора спрайт-листов должен выглядеть так: + + * Вам следует импортировать шрифт через обозреватель ресурсов в игре. Это было объяснено в [документе]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}}) выше. #### Использование недавно добавленных шрифтов -* Если мы все сделали правильно, мы сможем использовать наши недавно добавленные шрифты в игре. -* Чтобы использовать шрифт, мы можем объявить его имя в кисти, например: +* Если мы сделали всё правильно, мы должны иметь возможность использовать наши недавно добавленные шрифты в игре. +* Чтобы использовать шрифт, мы можем объявить его название в кисти (brush), например: -```xml - - - - - -``` + + + + + -* Теперь все виджеты, использующие эту кисть, будут отображаться с использованием нашего недавно добавленного шрифта. +* Теперь любые виджеты, использующие эту кисть, будут отрисовываться с использованием нашего недавно добавленного шрифта. -#### Установка шрифтов по умолчанию для языка +#### Настройка шрифтов по умолчанию для языка -* Для некоторых языков вам могут потребоваться собственные пользовательские шрифты. В этом случае вы можете установить шрифт по умолчанию для своего языка. -* To achieve this, create a file named **{YOURMODULE}Languages.xml** and put it in the folder: **{YOURMODULE}\GUI\Fonts** folder. -* Please note that you should give your **\*Languages.xml** file a unique name, and it should always end with " **Languages**" (e.g. _ **MyModuleLanguages.xml** _). For more information please see: [Adding & Overriding Assets]({{< ref "overriding_assets.md" >}}) -* В файле новых языков вы можете определить новый языковой узел, переопределить существующие и изменить язык игры по умолчанию. +* Для некоторых языков вам могут понадобиться собственные пользовательские шрифты. Если это ваш случай, вы можете установить шрифт по умолчанию для вашего языка. +* Чтобы этого достичь, создайте файл с названием **{YOURMODULE}Languages.xml** и поместите его в папку: **{YOURMODULE}\GUI\Fonts**. +* Обратите внимание, что вы должны дать вашему файлу **\*Languages.xml** уникальное название, и оно всегда должно заканчиваться на "**Languages**" (например, _ **MyModuleLanguages.xml** _). Для получения дополнительной информации см.: [Adding & Overriding Assets]({{< ref "overriding_assets.md" >}}) +* В новом файле языка вы можете определить новый узел языка, переопределить существующие и изменить язык игры по умолчанию. * Узлы языка используются для сопоставления встроенных шрифтов с вашими пользовательскими шрифтами. -* Например, если вы хотите установить шрифты по умолчанию для **Турецкого** языка, ваш узел должен выглядеть так: - -```xml - - - - - - - - - - -``` - -* Здесь мы установили шрифт по умолчанию для турецкого языка как "OpenSansRegular". И также сопоставили некоторые встроенные шрифты с нашими пользовательскими. -* После сохранения этого файла должны быть установлены шрифты по умолчанию для вашего языка, и вы должны увидеть правильный шрифт для вашего языка. \ No newline at end of file +* Например, если вы хотите установить шрифты по умолчанию для **турецкого** языка, ваш узел должен выглядеть так: + + + + + + + + + + + + +* Здесь мы установили шрифт по умолчанию для турецкого языка как "OpenSansRegular". А также сопоставили некоторые встроенные шрифты с нашими пользовательскими. +* После сохранения этого файла шрифты по умолчанию для вашего языка должны быть настроены, и вы должны увидеть правильный шрифт для вашего языка. diff --git a/docs/content/russian/Asset Management/implementing_flora.md b/docs/content/russian/Asset Management/implementing_flora.md index 273add1a..cdaa7699 100644 --- a/docs/content/russian/Asset Management/implementing_flora.md +++ b/docs/content/russian/Asset Management/implementing_flora.md @@ -1,132 +1,134 @@ +++ -title = "Implementing Flora" +title = "Реализация флоры" weight = 15 +ai_translated = true +++ -Flora is one of the most important rendering aspects in game engines. It takes up a large portion of the overall rendering task when it comes to performance. While creating a new flora mesh one should make sure that the mesh has a low amount of polygon overdraw. +Флора — один из важнейших аспектов рендеринга в игровых движках. Она занимает значительную часть общей задачи рендеринга, когда дело касается производительности. При создании новой меш-модели флоры следует убедиться, что меш имеет низкий уровень перерисовки полигонов (polygon overdraw). -There is also a tradeoff between empty pixels in texture (which increases overdraw) and the triangle count of the mesh (which increases the polygon count cost). The optimum triangle count and the UV layout may change depending on the specific case. +Существует также компромисс между пустыми пикселями в текстуре (что увеличивает overdraw) и количеством треугольников в меше (что увеличивает стоимость количества полигонов). Оптимальное количество треугольников и раскладка UV могут меняться в зависимости от конкретного случая. -Flora meshes are optimized render objects designed to be drawn in large scale view distances with large amounts of instances. +Меши флоры — это оптимизированные рендер-объекты, предназначенные для отрисовки на больших дистанциях обзора с большим количеством экземпляров (instances). -To be able to add, remove or fix flora assets, first you need to open the “Resource Browser”. +Чтобы иметь возможность добавлять, удалять или исправлять ассеты флоры, сначала нужно открыть «Resource Browser» (Браузер ресурсов). -In the Assets folder, right-click on an empty space and create a new folder within the resource browser. +В папке Assets щёлкните правой кнопкой мыши по пустому месту и создайте новую папку внутри браузера ресурсов. -Open your newly created folder and Import all of your meshes and textures one at a time. +Откройте только что созданную папку и импортируйте все ваши меши и текстуры по одной. -Once imported, to be able to create SDF Alpha from the diffuse texture, you will need to check "Generate SDF Alpha" on the “Texture inspector” panel that opens up on the right side of the screen when a texture file is selected, and click save on the same panel. +После импорта, чтобы иметь возможность создать SDF Alpha из диффузной текстуры, вам нужно будет отметить флажок «Generate SDF Alpha» на панели «Texture inspector» (Инспектор текстур), которая открывается справа от экрана при выборе файла текстуры, а затем нажать «save» на этой же панели. {{% notice tip %}} -SDF Alpha is a technique that we use to improve vegetation alpha performance in our engine. If not applied, the embedded alpha channel of the texture will not be processed. +SDF Alpha — это техника, которую мы используем для улучшения производительности альфа-канала растительности в нашем движке. Если её не применить, встроенный альфа-канал текстуры не будет обработан. {{% /notice %}} -To create a Flora Material, right click on an empty area in the Resource Browser, then click Create>Material and after that you can give a name to your material. +Чтобы создать материал флоры, щёлкните правой кнопкой мыши по пустой области в браузере ресурсов, затем нажмите Create>Material, после чего вы сможете дать имя вашему материалу. {{% notice tip %}} -If you want to use materials that already exist or were created by you in the editor for your newly imported meshes, you can rename the materials of your meshes in the 3d modelling program after the existing materials that you want to use in the editor. After the import, the editor assigns those materials to your meshes automatically. +Если вы хотите использовать материалы, которые уже существуют или были созданы вами в редакторе, для ваших недавно импортированных мешей, вы можете переименовать материалы ваших мешей в программе 3D-моделирования в соответствии с существующими материалами, которые вы хотите использовать в редакторе. После импорта редактор автоматически назначит эти материалы вашим мешам. {{% /notice %}} {{% notice tip %}} -Before diving into “material settings”, please check [Material Editor]({{< ref "material_editor" >}}) for more information. +Прежде чем переходить к «настройкам материала», пожалуйста, ознакомьтесь с [Редактором материалов]({{< ref "material_editor" >}}) для получения дополнительной информации. {{% /notice %}} -Click on the newly created material and select the shader that you want to use on the shader panel on the right. It is important to discern the type of shader you want to use, e.g. if our flora is grass, we need to select the grass shader, for trees and shrubs we select the flora_leaf shader. For the purpose of this documentation we have created grass as a flora and selected the grass_shader. +Нажмите на только что созданный материал и выберите шейдер, который вы хотите использовать, на панели шейдера справа. Важно правильно определить тип шейдера, который вы хотите использовать, например, если наша флора — это трава, нам нужно выбрать шейдер травы (grass shader), а для деревьев и кустарников мы выбираем шейдер flora_leaf. В целях данной документации мы создали траву в качестве флоры и выбрали grass_shader. -After selecting the shader for flora we need to connect (define) our textures to the flora materials. To achieve this, you can search for the texture in the Textures Panel or just drag and drop it to the texture slots from the Resource Browser. The same procedure should be followed for SDF Alphas. +После выбора шейдера для флоры нам нужно подключить (определить) наши текстуры к материалам флоры. Чтобы добиться этого, вы можете найти текстуру на панели Textures или просто перетащить её в слоты текстур из браузера ресурсов. Такую же процедуру следует выполнить и для SDF Alpha. {{% notice warning %}} -Make sure to save your changes by pressing “save” at the bottom of the Material Inspector, otherwise materials return to their default settings. +Обязательно сохраните изменения, нажав «save» внизу инспектора материалов, иначе материалы вернутся к настройкам по умолчанию. {{% /notice %}} -Next we are going to check alpha_test and use_albedo_alpha flags. Do NOT check the use_specular flag for Grass shader in order not to adversely affect performance. +Далее мы проверяем флаги alpha_test и use_albedo_alpha. НЕ отмечайте флаг use_specular для шейдера Grass, чтобы не повлиять негативно на производительность. -Then we move on to the “Transparency” tab and choose “Factor” from the Alpha Blend Mode drop down list and give a value to be used as a cutoff value for the “Alpha Test”. For most cases, a value of 45 would be suitable. +Затем мы переходим на вкладку «Transparency» (Прозрачность) и выбираем «Factor» из выпадающего списка Alpha Blend Mode, а также указываем значение, которое будет использоваться в качестве порогового значения для «Alpha Test». В большинстве случаев подходящим будет значение 45. -For the last step of our material settings we check the “Two Sided” box under the “Others” segment and then save. +На последнем шаге настройки материала мы отмечаем флажок «Two Sided» в разделе «Others» (Прочее), а затем сохраняем. , -Now that the material settings are done, after selecting the related mesh, we can search for the name of the material on the right side of the screen and apply it to the selected mesh and save. Or we can also select/drag/drop. We can then doubleclick on the mesh in the mesh editor and see if the material has been applied or not. +Теперь, когда настройки материала завершены, после выбора соответствующего меша мы можем найти имя материала в правой части экрана, применить его к выбранному мешу и сохранить. Или же мы также можем выбрать/перетащить и отпустить. Затем мы можем дважды щёлкнуть по мешу в редакторе меша и увидеть, был ли применён материал или нет. -## Flora Kind Editor +## Редактор типов флоры (Flora Kind Editor) -The Flora Kind Editor is where we define and manage imported floras. +Редактор типов флоры (Flora Kind Editor) — это место, где мы определяем и управляем импортированной флорой. -### Adding Resources to the Flora Kind Editor +### Добавление ресурсов в редактор типов флоры -To be able to add the flora we created into scenes, we need to define it within the Flora Kind Editor. We can access it from Window>Module Data>Flora Editor. +Чтобы иметь возможность добавить созданную нами флору в сцены, нам нужно определить её в редакторе типов флоры (Flora Kind Editor). Мы можем получить к нему доступ через Window>Module Data>Flora Editor. -Through the Flora Kind Editor we can: +С помощью редактора типов флоры мы можем: -1. Access a list of flora that exist/about to be added into the editor. -2. Name/Rename flora items. -3. Define parameters of flora. -4. View Flora variations according to seasons. -5. Add flora and variations. -6. View mesh information along with viewing or changing body objects and materials. +1. Получить доступ к списку флоры, которая существует/вот-вот будет добавлена в редактор. +2. Назвать/переименовать элементы флоры. +3. Определить параметры флоры. +4. Просматривать вариации флоры в зависимости от времени года. +5. Добавлять флору и вариации. +6. Просматривать информацию о меше, а также просматривать или изменять объекты тела (body objects) и материалы. -To add new flora we can click “Add New Flora” on the top left side and then change its name in the Flora Kind Name text field on the right side of the screen. +Чтобы добавить новую флору, мы можем нажать «Add New Flora» в верхней левой части, а затем изменить её имя в текстовом поле Flora Kind Name справа от экрана. -We define properties of our flora in the properties section. We check the “grass” box if our flora acts as grass. For the flora to snap to flatland or slopes we check the “align with ground” and “align with slope” respectively. If we want our flora to disappear at a certain distance, we check the “fading out” box and fill the “view distance” field right above with the correct amount. In case of using grass, we check the “no shadow” box to maximise the performance. Otherwise we leave that box **unchecked** for evidently larger and more scarcely placed flora objects like trees and shrubbery. +Мы определяем свойства нашей флоры в разделе свойств. Мы отмечаем флажок «grass» (трава), если наша флора ведёт себя как трава. Чтобы флора привязывалась к плоской поверхности или склонам, мы отмечаем «align with ground» (выравнивание по земле) и «align with slope» (выравнивание по склону) соответственно. Если мы хотим, чтобы наша флора исчезала на определённом расстоянии, мы отмечаем флажок «fading out» (затухание) и заполняем поле «view distance» (дальность видимости) чуть выше правильным значением. В случае использования травы мы отмечаем флажок «no shadow» (без тени), чтобы максимизировать производительность. В остальных случаях мы оставляем этот флажок **неотмеченным** для явно более крупных и реже размещаемых объектов флоры, таких как деревья и кустарники. -Click on “Add Variation” that is placed under the Seasons thumbnails in order to add the flora mesh you prepared. Here you can add different flora versions for different seasons so that season-specific flora will be displayed automatically. You can also add multiple flora meshes and create more variety. +Нажмите «Add Variation» (Добавить вариацию), расположенную под миниатюрами времён года (Seasons), чтобы добавить подготовленный вами меш флоры. Здесь вы можете добавить разные версии флоры для разных времён года, чтобы флора, специфичная для сезона, отображалась автоматически. Вы также можете добавить несколько мешей флоры и создать больше разнообразия. -Now that we are done adding our flora to the “Flora Kind Editor” with the desired parameters, the creation can be saved by clicking “Save Flora” or, in case of addition of multiple flora kinds, “Save All”. +Теперь, когда мы закончили добавление нашей флоры в «Редактор типов флоры» (Flora Kind Editor) с желаемыми параметрами, создание можно сохранить, нажав «Save Flora» (Сохранить флору) или, в случае добавления нескольких типов флоры, «Save All» (Сохранить всё). -### Adding Flora to Scenes +### Добавление флоры в сцены -After importing your mesh into the game and entering it into the Flora Kind Editor, we can use the “Flora Paint” to paint our flora into a scene. First we can generate a terrain in our scene. To do so, we can pick the “Select Terrain” tool from the top menu bar and then click “Generate Terrain” on the window that pops up on the right hand side and click ok on the next window to finally generate a terrain. We take these steps solely to create a terrain so that we can then use the Flora Paint tool. +После импорта вашего меша в игру и внесения его в редактор типов флоры, мы можем использовать «Flora Paint» (Покраска флорой), чтобы наносить нашу флору на сцену. Сначала мы можем сгенерировать ландшафт в нашей сцене. Для этого мы можем выбрать инструмент «Select Terrain» (Выбор ландшафта) из верхней панели меню, затем нажать «Generate Terrain» (Сгенерировать ландшафт) в окне, которое появляется справа, и нажать ok в следующем окне, чтобы в конечном итоге сгенерировать ландшафт. Мы выполняем эти шаги исключительно для создания ландшафта, чтобы затем мы могли использовать инструмент Flora Paint. -After a terrain is created, we pick the “Flora Paint” tool from the top bar. We then type in the name of the flora that we previously defined within the Flora Kind Editor and apply it on the scene. +После создания ландшафта мы выбираем инструмент «Flora Paint» на верхней панели. Затем мы вводим имя флоры, которую ранее определили в редакторе типов флоры, и наносим её на сцену. -Another way of adding our flora onto the scene is by putting it into one of the layers we created for terrain painting. To do this we can pick the “Paint Terrain Layer” tool from the top menu bar. Then we add a new layer from the new window that opens up on the right hand side. +Другой способ добавления нашей флоры в сцену — это помещение её в один из слоёв, которые мы создали для покраски ландшафта. Для этого мы можем выбрать инструмент «Paint Terrain Layer» (Покраска слоя ландшафта) на верхней панели меню. Затем мы добавляем новый слой из нового окна, которое открывается справа. -We double click on the new layer and open its properties menu. We then check the “Flora Layer” box and expand the “Flora Meshes” tab. +Мы дважды щёлкаем по новому слою и открываем меню его свойств. Затем мы отмечаем флажок «Flora Layer» (Слой флоры) и разворачиваем вкладку «Flora Meshes» (Меши флоры). -Checking the Flora Layer box will deactivate the textures that are used to paint the terrain, however, the flora that we added will still be visible. If we want to view both flora and the textures that we added to the layers at the same time, this box should be left unchecked. +Отметка флажка Flora Layer деактивирует текстуры, используемые для покраски ландшафта, однако добавленная нами флора по-прежнему будет видна. Если мы хотим одновременно видеть и флору, и текстуры, которые мы добавили в слои, этот флажок следует оставить неотмеченным. -Under the “Flora Meshes” section, click on the dropdown menu next to “Flora” and select the Flora you have prepared, then paint an area of your terrain. +В разделе «Flora Meshes» нажмите на выпадающее меню рядом с «Flora» и выберите подготовленную вами флору, затем закрасьте область вашего ландшафта. - \ No newline at end of file + + diff --git a/docs/content/russian/Asset Management/weapon_smithing.md b/docs/content/russian/Asset Management/weapon_smithing.md index 9646e1f7..1ec88acb 100644 --- a/docs/content/russian/Asset Management/weapon_smithing.md +++ b/docs/content/russian/Asset Management/weapon_smithing.md @@ -1,26 +1,27 @@ +++ -title = "Weapon Smithing & Crafting Pieces" +title = "Кузнечное дело и элементы крафта оружия" weight = 15 +ai_translated = true +++ -#### Introduction -The Smithing screen allows for the creation of all melee and throwing weapons in the game (swords, daggers, throwing knives, throwing axes, maces, polearms, pikes, javelins). +#### Введение +Экран кузницы позволяет создавать всё холодное и метательное оружие в игре (мечи, кинжалы, метательные ножи, метательные топоры, булавы, древковое оружие, пики, дротики). -Picture 1: Fine Steel Cavalry Broadsword being created on Smithing screen. +Рисунок 1: Создание кавалерийского палаша из прекрасной стали на экране кузницы. -#### Adding Weapons to the Smithing System -To be able to create a weapon on the Smithing screen, all the individual weapon parts need to be exported to the game separately. You can find out how to export assets to the editor on [Asset Management]({{< ref "Asset Management" >}}). After the meshes are added to the editor, the mesh name and measurements specific to the added weapon part need to be put into the relevant XML document. Adding weapon parts is explained below by giving sword and dagger parts as examples (other weapon parts can be added to the editor using the same process). +#### Добавление оружия в систему кузницы +Чтобы иметь возможность создавать оружие на экране кузницы, все отдельные детали оружия должны быть экспортированы в игру по отдельности. Узнать, как экспортировать ассеты в редактор, можно в разделе [Asset Management]({{< ref "Asset Management" >}}). После того как меши добавлены в редактор, имя меша и характерные для добавленной детали оружия измерения нужно внести в соответствующий XML-документ. Добавление деталей оружия ниже объясняется на примере деталей меча и кинжала (остальные детали оружия добавляются в редактор по тому же принципу). -#### Swords And Daggers -Five parts are needed to create a sword (similar to daggers). Those are the blade, guard, grip, pommel and optionally scabbard. All meshes’ pivot points need to be at the numeric centre of the object and the position of the object needs to be at the world origin (Picture 2, Picture 3). This way we can export all the parts in a single FBX file or export each part individually using separate FBX files. For example, we export all of the sword blades in a single FBX file. Other parts are also exported together to their respective FBX files (guards, grips, pommels, scabbards). (Picture 4) +#### Мечи и кинжалы +Для создания меча (как и кинжала) требуется пять деталей. Это клинок, гарда, рукоять, навершие и, опционально, ножны. Точки опоры (pivot points) всех мешей должны находиться в геометрическом центре объекта, а положение объекта должно быть в начале координат мира (Рисунок 2, Рисунок 3). Благодаря этому мы можем экспортировать все детали в одном FBX-файле либо экспортировать каждую деталь отдельно, используя отдельные FBX-файлы. Например, мы экспортируем все клинки мечей в один FBX-файл. Остальные детали также экспортируются вместе в соответствующие им FBX-файлы (гарды, рукояти, навершия, ножны). (Рисунок 4) -Picture 2: Example, battania_grip_1 mesh in Blender viewport before exporting. +Рисунок 2: Пример, меш battania_grip_1 в окне просмотра Blender перед экспортом. -Picture 3: All weapon parts positioned neatly at the world origin. +Рисунок 3: Все детали оружия аккуратно размещены в начале координат мира. -Picture 4: Sword parts directory hierarchy. +Рисунок 4: Иерархия директорий деталей меча. -#### CraftingPieces XmlNode Example +#### Пример XML-узла CraftingPieces ``` @@ -55,40 +56,40 @@ Five parts are needed to create a sword (similar to daggers). Those are the blad ``` -##### CraftingPieces/CraftingPiece Node -When a crafting piece is created the following pieces of information should be defined. - -* **id**: Unique string id of the piece. Each piece must have a unique id to differ from other pieces. -* **name**: Name of the piece that will be shown to the players in the game. -* **piece_type**: References to the “CraftingPiece.PieceTypes”. PieceTypes are definitions that are used to label which part the piece belongs to. Each crafting piece is composed of different pieces. -* **mesh**: A unique mesh id is required to define the visual shape of the crafting piece. -* **weight**: Weight of the crafting piece in kilograms. -* **length**: Measured length of the piece in centimeters (Pivot point is always centered). -* **culture (optional)**: Defined culture of the current item. If an item is set for a culture, the item will only be sold on the markets of the same culture. -* **full_scale (optional)**: Defines scaling factors of the piece in dimensions. When set as "true" the piece should scale in all three dimensions. Setting it "false" scales in a single dimension which is the build axis. -* **appearance (optional)**: A value (price) calculation factor. -* **center_of_mass (optional)**: Center of mass percentage of the piece, normally 0.5 (in the middle). -* **tier (optional)**: Defaults as “1”. Tier defines the quality of the crafting piece. Tier helps setting the weapon tier and the crafting difficulty. -* **is_default (optional)**: When set as "true" the piece comes out unlocked for the crafting feature, if the piece is set as "false" the piece must be unlocked through crafting different weapons. -* **is_hidden (optional)**: When set as “true” the piece won’t show up on the crafting feature. Therefore it won’t be usable. When this variable is not set or set as “false” the crafting piece is available for the crafting feature. -* **item_holster_pos_shift (optional)**: Value given to this parameter sets position offset for the holster. -* **excluded_item_usage_features (optional)**: ":" separated values of item usage features which the piece cannot use. For example, when "thrust" is defined as an exclusion on a weapon piece. A weapon with that piece can not make thrust attacks. - -##### CraftingPieces/CraftingPiece/BuildData Node -* **piece_offset**: Given value sets distance adjustment for the piece from the origin of the weapon in centimeters. -* **next_piece_offset**: Given value sets the distance of the next piece in terms of centimeters. When a positive number is set, the distance to the next piece is closer. Negative values can be given to separate the pieces further apart. -* **previous_piece_offset**: Given value sets the distance of the previous piece in terms of centimeters. While the positive values bring pieces together, negative pieces set them further apart. - -##### CraftingPieces/CraftingPiece/Materials/Material Node -Material sets the required number of materials needed to craft the piece. Materials are also used in the smelting formula. Results of the smelting can not be more than material count and can not result in materials that are not listed in the material list. (Current formula in Bannerlord generates 1 lesser quality material of the highest material defined) Multiple materials can be set for specific items. A sword guard might require 3 counts of Iron2 and 1 count of Iron4. - -* **id**: References to the “CraftingMaterials”. CraftingMaterials are definitions used for pieces that generate a crafting piece when combined. -* **count**: Amount of material required to craft the piece. - -##### CraftingPieces/CraftingPiece/Flags/Flag Node -Flags are used for defining different properties that allow crafted items to have different features. There are two different variables when a flag needs to be set; - -**name**: References to the “ItemFlags” or “WeaponFlags”. +##### Узел CraftingPieces/CraftingPiece +При создании детали крафта должна быть определена следующая информация. + +* **id**: Уникальный строковый идентификатор детали. Каждая деталь должна иметь уникальный id, отличающий её от других деталей. +* **name**: Название детали, которое будет показано игрокам в игре. +* **piece_type**: Ссылка на «CraftingPiece.PieceTypes». PieceTypes — это определения, используемые для обозначения того, к какой части относится деталь. Каждая деталь крафта состоит из разных частей. +* **mesh**: Для определения визуальной формы детали крафта требуется уникальный идентификатор меша. +* **weight**: Вес детали крафта в килограммах. +* **length**: Измеренная длина детали в сантиметрах (точка опоры всегда центрирована). +* **culture (опционально)**: Определённая культура текущего предмета. Если предмет установлен для определённой культуры, он будет продаваться только на рынках той же культуры. +* **full_scale (опционально)**: Определяет коэффициенты масштабирования детали по измерениям. При значении "true" деталь должна масштабироваться по всем трём измерениям. Установка "false" масштабирует только в одном измерении — по оси построения. +* **appearance (опционально)**: Коэффициент расчёта стоимости (цены). +* **center_of_mass (опционально)**: Процент центра масс детали, обычно 0.5 (посередине). +* **tier (опционально)**: По умолчанию «1». Tier определяет качество детали крафта. Tier помогает устанавливать уровень оружия и сложность крафта. +* **is_default (опционально)**: При значении "true" деталь по умолчанию доступна для крафта без разблокировки. Если установлено "false", деталь должна быть разблокирована путём создания разного оружия. +* **is_hidden (опционально)**: При значении "true" деталь не будет отображаться в функции крафта. Соответственно, она не будет доступна для использования. Когда эта переменная не установлена или установлена как "false", деталь крафта доступна для функции крафта. +* **item_holster_pos_shift (опционально)**: Значение этого параметра задаёт смещение положения для ножен/кобуры. +* **excluded_item_usage_features (опционально)**: Значения, разделённые символом ":", обозначающие функции использования предмета, которые деталь не может использовать. Например, если для детали оружия в качестве исключения задано "thrust" (колющая атака), оружие с этой деталью не сможет совершать колющие атаки. + +##### Узел CraftingPieces/CraftingPiece/BuildData +* **piece_offset**: Заданное значение устанавливает корректировку расстояния детали от начала координат оружия в сантиметрах. +* **next_piece_offset**: Заданное значение устанавливает расстояние до следующей детали в сантиметрах. При положительном значении расстояние до следующей детали уменьшается. Отрицательные значения можно задать, чтобы отдалить детали друг от друга. +* **previous_piece_offset**: Заданное значение устанавливает расстояние до предыдущей детали в сантиметрах. Положительные значения сближают детали, а отрицательные — отдаляют. + +##### Узел CraftingPieces/CraftingPiece/Materials/Material +Material задаёт необходимое количество материалов, требуемых для создания детали. Материалы также используются в формуле переплавки. Результаты переплавки не могут превышать количество материала и не могут содержать материалы, не указанные в списке материалов. (Текущая формула в Bannerlord генерирует 1 материал более низкого качества из материала наивысшего качества, указанного в списке.) Для конкретных предметов можно задать несколько материалов. Для гарды меча может требоваться 3 единицы Iron2 и 1 единица Iron4. + +* **id**: Ссылка на «CraftingMaterials». CraftingMaterials — это определения, используемые для частей, которые при объединении создают деталь крафта. +* **count**: Количество материала, необходимое для создания детали. + +##### Узел CraftingPieces/CraftingPiece/Flags/Flag +Флаги используются для определения различных свойств, позволяющих созданным предметам иметь разные особенности. Есть две разные переменные, которые необходимо задать при установке флага; + +**name**: Ссылка на «ItemFlags» или «WeaponFlags». * ItemFlags * ForceAttachOffHandPrimaryItemBone @@ -149,9 +150,9 @@ Flags are used for defining different properties that allow crafted items to hav * AmmoBreakOnBounceBackMask * AmmoSticksWhenShot -**type**: “ItemFlags” or “WeaponFlags”. WeaponFlags is the default if omitted. +**type**: «ItemFlags» или «WeaponFlags». Если не указано, по умолчанию используется WeaponFlags. -#### CraftingTemplates XmlNode Example +#### Пример XML-узла CraftingTemplates ``` @@ -205,41 +206,41 @@ Flags are used for defining different properties that allow crafted items to hav ``` -##### CraftingTemplates/CraftingTemplate Node -When generating a crafting template the following values must be defined. +##### Узел CraftingTemplates/CraftingTemplate +При создании шаблона крафта должны быть определены следующие значения. -* **id**: Unique string id of the template. Each template must have a unique id to differ from other templates. -* **item_modifier_group**: A reference to an item modifier group from item_modifier_groups.xml. +* **id**: Уникальный строковый идентификатор шаблона. Каждый шаблон должен иметь уникальный id, отличающий его от других шаблонов. +* **item_modifier_group**: Ссылка на группу модификаторов предмета из item_modifier_groups.xml. -For example both two handed maces and maces fall under the mace category here. +Например, и двуручные булавы, и булавы попадают здесь под категорию "mace". item_modifier_group="mace" -* **item_holsters**: Defines where the item can be holstered. For items of multiple pieces common holsters will be used within the game. Piece types should be separated by ”:”. Separated references can be found from item_holsters.xml. -* **piece_type_to_scale_holster_with**: This defines the piece type to scale the holster mesh (if exists) with. As an example if the “Blade” is set for this parameter, the blade piece will be scaling the holster of the weapon. Other pieces will be disregarded. -* **hidden_piece_types_on_holster**: ":" separated values of “CraftingPiece.PieceTypes” to be hidden in the holster mesh. -* **default_item_holster_position_offset**: Default position offset for the holster. This is set in the format of "x,y,z". Applies to all weapons that are using the template. Further adjustment per piece can be applied from item_holster_pos_shift variable under a crafting piece. -* **use_weapon_as_holster_mesh**: When set as “true”, all weapons using the template will have itself as the holster mesh. The weapon itself will appear in place of the holster. -* **rotate_weapon_in_holster**: When set as “true”, all weapons using the template will be put in the opposite direction in the holster mesh. Useful for javelins to have their blades sticking out. -* **always_show_holster_with_weapon**: When set as “true”, the weapon mesh inside the holster mesh will not be hidden when the weapon is drawn. This feature is most useful for weapons with multiple stacks inside the holster such as quivers. +* **item_holsters**: Определяет, где предмет может быть помещён в ножны/кобуру. Для предметов из нескольких деталей в игре будут использоваться общие ножны. Типы деталей должны разделяться символом «:». Разделённые ссылки можно найти в item_holsters.xml. +* **piece_type_to_scale_holster_with**: Определяет тип детали, по которой масштабируется меш ножен/кобуры (если он существует). Например, если для этого параметра установлено значение «Blade», клинок будет масштабировать ножны оружия. Остальные детали не будут учитываться. +* **hidden_piece_types_on_holster**: Значения «CraftingPiece.PieceTypes», разделённые символом ":", которые нужно скрыть в меше ножен. +* **default_item_holster_position_offset**: Смещение положения ножен по умолчанию. Задаётся в формате "x,y,z". Применяется ко всему оружию, использующему данный шаблон. Дополнительная настройка для каждой детали может быть применена через переменную item_holster_pos_shift у детали крафта. +* **use_weapon_as_holster_mesh**: При значении «true» у всего оружия, использующего шаблон, в качестве меша ножен будет выступать само оружие. Само оружие будет отображаться на месте ножен. +* **rotate_weapon_in_holster**: При значении «true» всё оружие, использующее шаблон, будет помещено в противоположном направлении в меш ножен. Полезно для дротиков, чтобы их наконечники торчали наружу. +* **always_show_holster_with_weapon**: При значении «true» меш оружия внутри меша ножен не будет скрываться, когда оружие вынуто. Эта функция наиболее полезна для оружия с несколькими стопками внутри ножен, например, колчанов. -##### CraftingTemplates/CraftingTemplate/PieceDatas/PieceData Node -Defines which type of pieces can be used with the template and in which order they will be assembled. +##### Узел CraftingTemplates/CraftingTemplate/PieceDatas/PieceData +Определяет, какие типы деталей могут использоваться с шаблоном и в каком порядке они будут собираться. -* **piece_type**: References to the “CraftingPiece.PieceTypes”. -* **build_order**: In which order the piece is going to be built. All weapons are built around the handle pieces. Since all weapons must have handles, the order of a handle should be set to 0. Any piece which is on top of a handle should have incremental positive values and any piece which is on the other side of the handle should have incremental negative values. +* **piece_type**: Ссылка на «CraftingPiece.PieceTypes». +* **build_order**: Порядок, в котором строится деталь. Всё оружие строится вокруг деталей рукояти. Поскольку всё оружие должно иметь рукоять, порядок рукояти должен быть установлен на 0. Любая деталь, расположенная по одну сторону рукояти, должна иметь возрастающие положительные значения, а любая деталь, расположенная по другую сторону рукояти, — возрастающие отрицательные значения. -##### CraftingTemplates/CraftingTemplate/WeaponDescriptions/WeaponDescription Node -A WeaponDescription is simply the primary usage or one of the alternative usages of a weapon. They are defined in weapon_descriptions.xml and referenced in the template. +##### Узел CraftingTemplates/CraftingTemplate/WeaponDescriptions/WeaponDescription +WeaponDescription — это просто основное применение или один из альтернативных вариантов использования оружия. Они определяются в weapon_descriptions.xml и указываются в шаблоне. -* **id**: Unique string id of the description. Each description must have a unique id to differ from other descriptions. +* **id**: Уникальный строковый идентификатор описания. Каждое описание должно иметь уникальный id, отличающий его от других описаний. -##### CraftingTemplates/CraftingTemplate/StatsData Node -This is used for defining which basic stats for the weapon will be shown on the inventory or the crafting screen. +##### Узел CraftingTemplates/CraftingTemplate/StatsData +Используется для определения того, какие базовые характеристики оружия будут показаны в инвентаре или на экране кузницы. -* **weapon_description (optional)**: If specified, given data will be used only for the defined description instead of the template. When at least one StatsData node has this optional attribute defined, either all weapon descriptions referenced in the template must have their own StatsData entries or a default one must be provided before the specific one. +* **weapon_description (опционально)**: Если указано, данные будут использоваться только для определённого описания, а не для шаблона в целом. Если хотя бы один узел StatsData имеет этот опциональный атрибут, то либо все описания оружия, указанные в шаблоне, должны иметь собственные записи StatsData, либо перед конкретным узлом должен быть указан узел по умолчанию. -An example is given below; +Пример приведён ниже; -##### CraftingTemplates/CraftingTemplate/StatsData/StatData Node -* **stat_type**: References to the “CraftingTemplate.CraftingStatTypes”. Defines different characteristics of a weapon. -* **max_value**: Maximum value defines the upper limit a stat can have. +##### Узел CraftingTemplates/CraftingTemplate/StatsData/StatData +* **stat_type**: Ссылка на «CraftingTemplate.CraftingStatTypes». Определяет различные характеристики оружия. +* **max_value**: Максимальное значение определяет верхний предел, который может иметь характеристика. -##### CraftingTemplates/CraftingTemplate/UsablePieces/UsablePiece Node -* **piece_id**: References to the “CraftingPiece.PieceTypes”. +##### Узел CraftingTemplates/CraftingTemplate/UsablePieces/UsablePiece +* **piece_id**: Ссылка на «CraftingPiece.PieceTypes». -Example: In order to enable spear_blade_7 as a javelin part, it must be listed under the “javelin” id. The same piece must also be listed on the weapon_descriptions.xml under the related part. +Пример: Чтобы включить spear_blade_7 в качестве детали дротика, его нужно указать под id «javelin». Та же деталь также должна быть указана в weapon_descriptions.xml в соответствующей части. -#### WeaponDescriptions XmlNode Example +#### Пример XML-узла WeaponDescriptions ``` @@ -287,32 +288,32 @@ Example: In order to enable spear_blade_7 as a javelin part, it must be listed u ``` -##### WeaponDescriptions/WeaponDescription Node -A **Weapon description** is used for defining different usages and features. Defined parts listed under the crafting templates nodes must also be listed under the weapon_descriptions.xml to be used. +##### Узел WeaponDescriptions/WeaponDescription +**Weapon description** используется для определения различных вариантов использования и особенностей. Детали, перечисленные в узлах шаблонов крафта, также должны быть указаны в weapon_descriptions.xml, чтобы их можно было использовать. -* **id**: Unique string id of the WeaponDescription. -* **weapon_class**: References to the “WeaponClass”. This defines which weapon type will be used by the weapon descriptions. -* **item_usage_features**: “:” separated values of item usage features which are available for the description. This is used for defining possible features (“_” separated pieces) of an item_usage_set (from item_usage_sets.xml). +* **id**: Уникальный строковый идентификатор WeaponDescription. +* **weapon_class**: Ссылка на «WeaponClass». Определяет, какой тип оружия будет использоваться данным описанием оружия. +* **item_usage_features**: Значения функций использования предмета, разделённые символом «:», доступные для данного описания. Используется для определения возможных особенностей (частей, разделённых «_») набора item_usage_set (из item_usage_sets.xml). -An example is listed below; +Пример приведён ниже; item_usage_features="onehanded:block:shield:swing:thrust"> -* **rotated_in_hand**: When set as “true”, all weapons using the description will be held 180 degrees rotated in hand. A common use case for this is throwable polearms. -* **use_center_of_mass_as_hand_base**: When set as “true”, instead of the usual handle pivot, the weapon will be held from the calculated center of mass position. This is also used in throwable polearms. +* **rotated_in_hand**: При значении «true» всё оружие, использующее это описание, будет держаться в руке с поворотом на 180 градусов. Обычно это применяется к метательному древковому оружию. +* **use_center_of_mass_as_hand_base**: При значении «true» вместо обычной точки опоры рукояти оружие будет удерживаться за рассчитанное положение центра масс. Это также используется для метательного древкового оружия. -##### WeaponDescriptions/WeaponDescription/WeaponFlags/WeaponFlag Node -Default WeaponFlags used for all weapons for the description. +##### Узел WeaponDescriptions/WeaponDescription/WeaponFlags/WeaponFlag +Флаги WeaponFlags по умолчанию, применяемые ко всему оружию данного описания. -* **value**: References to the “WeaponFlags”. +* **value**: Ссылка на «WeaponFlags». -##### WeaponDescriptions/WeaponDescription/AvailablePieces/AvailablePiece Node -List of available pieces. +##### Узел WeaponDescriptions/WeaponDescription/AvailablePieces/AvailablePiece +Список доступных деталей. -* **id**: A reference to a crafting piece. +* **id**: Ссылка на деталь крафта. -#### Example: Adding crafting pieces to existing weapon templates via XML & XSLT -**Example case**: We have created 8 crafting pieces suitable for one handed swords with the following mesh names in the .fbx files: +#### Пример: Добавление деталей крафта к существующим шаблонам оружия через XML и XSLT +**Пример ситуации**: Мы создали 8 деталей крафта, подходящих для одноручных мечей, со следующими именами мешей в файлах .fbx: * yourforumusername_blade_1 * yourforumusername_blade_2 @@ -323,24 +324,24 @@ List of available pieces. * yourforumusername_pommel_1 * yourforumusername_pommel_2 -We have also created 4 crafting pieces suitable for two handed swords: +Мы также создали 4 детали крафта, подходящие для двуручных мечей: * yourforumusername_blade_3 * yourforumusername_guard_3 * yourforumusername_grip_3 * yourforumusername_pommel_3 -We **haven’t yet created our new module** which is why we launched the Mount & Blade II: Bannerlord Modding Kit, opened the Editor, clicked on File->Create New Module, gave our module a name **“OurModule”** and clicked “Create”. +Мы **ещё не создали наш новый модуль**, поэтому мы запустили Mount & Blade II: Bannerlord Modding Kit, открыли редактор, нажали File->Create New Module, дали модулю название **«OurModule»** и нажали «Create». -We have then added **all of the meshes and materials** to our module with the help of the editor. This requires more than just adding the source files to the AssetSources\element folder. The files then need to be exported to the game via the Resource browser and the module published. +Затем мы добавили **все меши и материалы** в наш модуль с помощью редактора. Для этого недостаточно просто добавить исходные файлы в папку AssetSources\element. Файлы затем нужно экспортировать в игру через браузер ресурсов (Resource browser) и опубликовать модуль. -Now, we want to do the necessary steps for these crafting pieces to **appear in-game**. We need to create a **new XML** file within our module: +Теперь мы хотим выполнить необходимые шаги, чтобы эти детали крафта **появились в игре**. Нам нужно создать **новый XML**-файл в нашем модуле: * Modules\OurModule\ModuleData\Custom_crafting_pieces.xml -We also need to modify the native Crafting_templates.xml and Weapon_descriptions.xml via XSLT. That’s why we need to create these 2 files within our module: +Нам также нужно изменить нативные файлы Crafting_templates.xml и Weapon_descriptions.xml с помощью XSLT. Поэтому нам нужно создать эти 2 файла в нашем модуле: * Modules\OurModule\ModuleData\Crafting_templates.xsl * Modules\OurModule\ModuleData\Weapon_descriptions.xsl @@ -348,7 +349,7 @@ We also need to modify the native Crafting_templates.xml and Weapon_descriptions ##### SubModule.xml -We also need to add the new XML & XSL files to our SubModule.xml: +Нам также нужно добавить новые XML- и XSL-файлы в наш SubModule.xml: @@ -375,7 +376,7 @@ We also need to add the new XML & XSL files to our SubModule.xml: ##### Custom_crafting_pieces.xml -Within the **Custom_crafting_pieces.xml**, we’ll add the 12 crafting pieces. We’ll also define all of the required properties of these pieces as explained in this document above. +В файле **Custom_crafting_pieces.xml** мы добавим 12 деталей крафта. Мы также определим все необходимые свойства этих деталей, как было объяснено выше в этом документе. ``` @@ -596,7 +597,7 @@ Within the **Custom_crafting_pieces.xml**, we’ll add the 12 crafting pieces. W ``` ##### Crafting_templates.xsl -Now, we need to add the crafting pieces to the **Crafting_templates.xsl**: +Теперь нам нужно добавить детали крафта в **Crafting_templates.xsl**: ``` @@ -635,10 +636,10 @@ Now, we need to add the crafting pieces to the **Crafting_templates.xsl**: ``` -The above XSLT code modifies the two native crafting templates “OneHandedSword” and “TwoHandedSword”. The use of XSLT is required in order to modify the existing templates. If we were to add a new template, for example “Firearms”, the use of XSLT wouldn’t be required. Instead, we could simply create a new custom_crafting_templates.xml and add the new template there. +Приведённый выше код XSLT изменяет два нативных шаблона крафта «OneHandedSword» и «TwoHandedSword». Использование XSLT необходимо для изменения существующих шаблонов. Если бы мы добавляли новый шаблон, например «Firearms», использование XSLT не потребовалось бы. Вместо этого мы могли бы просто создать новый custom_crafting_templates.xml и добавить туда новый шаблон. ##### Weapon_descriptions.xsl -We also need to modify the **Weapon_descriptions.xsl** with the following: +Нам также нужно изменить **Weapon_descriptions.xsl** следующим образом: ``` @@ -678,21 +679,8 @@ We also need to modify the **Weapon_descriptions.xsl** with the following: ``` -That’s it. Our crafting pieces will now show up on the crafting screen in-game. - -##### Example Mod Download -If you would like to download the example module presented above [click here](https://download3.taleworlds.com/OurModule.zip). - - - - - - - - - - - - +Вот и всё. Наши детали крафта теперь появятся на экране кузницы в игре. +##### Скачать пример мода +Если вы хотите скачать пример модуля, представленный выше, [нажмите здесь](https://download3.taleworlds.com/OurModule.zip). diff --git a/docs/content/russian/Audio Modding/Adding Custom Sounds.md b/docs/content/russian/Audio Modding/Adding Custom Sounds.md index bced6adf..1a8cdb92 100644 --- a/docs/content/russian/Audio Modding/Adding Custom Sounds.md +++ b/docs/content/russian/Audio Modding/Adding Custom Sounds.md @@ -1,28 +1,29 @@ +++ -title = "Добавление звуков в ваш модуль (Outdated)" +title = "Добавление звуков в ваш модуль (Устарело)" weight = 100 +ai_translated = true +++ -Аудиосистема Bannerlord построена на собственной звуковой системе FMOD. -Чтобы сохранить производительность звукового движка и сделать его доступным для всех, нам потребовалось создать прослойку. +Звуковая система Bannerlord построена на основе проприетарной звуковой системы FMOD. +Чтобы сохранить производительность звукового движка, сделав его при этом доступным для всех, нам понадобилось создать промежуточный слой. ## Ключевые элементы -* `...\Modules\*YOUR_MOD*\ModuleData\module_sounds.xml` файл, в который вы добавляете пользовательские определения для ваших собственных звуков. -* `...\Modules\*YOUR_MOD*\ModuleSounds` папка, в которую вы помещаете аудиофайлы (`.ogg`, `.wav`) +* Файл `...\Modules\*YOUR_MOD*\ModuleData\module_sounds.xml`, куда вы добавляете пользовательские определения для своих собственных звуков +* Папка `...\Modules\*YOUR_MOD*\ModuleSounds`, куда вы помещаете аудиофайлы (`.ogg`, `.wav`) -Вы можете посмотреть пример в модуле 'Native'. +Примеры можно увидеть в модуле 'Native'. -## Основное руководство +## Базовое руководство -1. Скопируйте файлы примеров и папку в свой собственный модуль +1. Скопируйте примеры файлов и папку в свой собственный модуль 2. Добавьте новые звуки в папку ModuleSounds -3. Откройте module_sounds.xml в вашем модуле -4. Вы увидите категории звуков, пример кода для воспроизведения звуков и примеры записей module_sound в исходном файле module_sounds.xml. -5. Добавьте новую запись в файл вашего мода module_sounds.xml -6. Воспроизведите новый звук из кода +3. Откройте файл module_sounds.xml вашего модуля +4. Вы увидите категории звуков, пример кода для воспроизведения звуков и примеры записей module_sound в исходном файле module_sounds.xml +5. Добавьте новую запись в module_sounds.xml вашего мода +6. Воспроизведите новую звуковую запись из кода -## Двигаемся дальше +## Идём дальше ### Использование module_sounds.xml @@ -30,53 +31,53 @@ weight = 100 ``` -* **'name'**: Любое уникальное имя по вашему желанию. Это идентификатор вашего звука. - - Используйте при воспроизведении звука из кода. - - Используйте для воспроизведения звука анимации. Добавьте к анимации атрибут 'sound_code'. -* **'is_2d'**: Если пространственные свойства звука не будут использоваться. 3D-звуки имеют такие свойства, как положение, скорость и т.д. -* **'sound_category'**: Все звуки должны быть отнесены к категории, чтобы они правильно проходили через наши трубы. Доступные категории: - - mission_ambient_bed (2D ambient loops like base wind) - - mission_ambient_3d_big (Sounds that should be heard from long distance, like a burning castle) - - mission_ambient_3d_medium (Sounds that should be heard from medium distance, like bonfires) - - mission_ambient_3d_small (Sounds that should be heard from nearby, like campfires) - - mission_material_impact (Physics material impacts like *metal* sword hitting *stone* wall) - - mission_combat_trivial (Unimportant damage sounds, like low/no damage) - - mission_combat (Damage sounds) - - mission_foley (Swings, movement sounds, animal movements) - - mission_voice_shout (Human/Animal voices that should be heard from long distance like battle yells) - - mission_voice (Human/Animal grunts, knockouts etc.) - - mission_voice_trivial (Quiet vocalizations like climbing, jumping) - - mission_siege_loud (Big siege sounds like boulder hits wall, Catapult fires, Door breaks) - - mission_footstep (Standard footsteps for humans and smaller animals) - - mission_footstep_run (Louder footsteps that could be head from distance when in crowds) - - mission_horse_gallop (Horse, camel gallops) - - mission_horse_walk (Horse, camel single soft footstep) - - ui (2D sounds for UI and notifications) - - alert (Psuedo-3d sounds for alerting the player from mid distance) - - campaign_node (Positional sound nodes for World Map, farms, seas, waterfalls) - - campaign_bed (2D ambient sounds for World Map, desert gusts, pasture winds etc.) -* **'path'**: Звуковой файл для воспроизведения. Путь указывается относительно папки ModuleSounds вашего модуля. Вы можете создавать дочерние папки. +* **'name'**: Любое уникальное имя по вашему выбору. Это идентификатор вашего звука. + - Используется при воспроизведении звука из кода. + - Используется для воспроизведения звука анимации. Добавьте его в атрибут 'sound_code' анимации. +* **'is_2d'**: Указывает, не будут ли использоваться пространственные свойства звука. У 3D-звуков есть такие свойства, как позиция, скорость и т. д. +* **'sound_category'**: Все звуки должны быть отнесены к категории, чтобы правильно маршрутизировать их через наши каналы. Доступные категории: + - mission_ambient_bed (2D-зацикленные окружающие звуки, например базовый ветер) + - mission_ambient_3d_big (Звуки, которые должны быть слышны с большого расстояния, например горящий замок) + - mission_ambient_3d_medium (Звуки, которые должны быть слышны со среднего расстояния, например костры) + - mission_ambient_3d_small (Звуки, которые должны быть слышны с близкого расстояния, например лагерные костры) + - mission_material_impact (Физические удары материалов, например *металлический* меч, ударяющийся о *каменную* стену) + - mission_combat_trivial (Незначительные звуки урона, например при низком/нулевом уроне) + - mission_combat (Звуки урона) + - mission_foley (Звуки размахов, движений, движения животных) + - mission_voice_shout (Голоса людей/животных, которые должны быть слышны с большого расстояния, например боевые кличи) + - mission_voice (Хрюканье/рычание людей/животных, звуки нокаута и т. д.) + - mission_voice_trivial (Тихие вокализации, например при лазании, прыжках) + - mission_siege_loud (Громкие звуки осады, например удар валуна о стену, выстрел катапульты, пробитие двери) + - mission_footstep (Обычные шаги людей и мелких животных) + - mission_footstep_run (Более громкие шаги, которые могут быть слышны издалека при скоплении толпы) + - mission_horse_gallop (Галоп лошади, верблюда) + - mission_horse_walk (Одиночный мягкий шаг лошади, верблюда) + - ui (2D-звуки для интерфейса и уведомлений) + - alert (Псевдо-3D звуки для оповещения игрока со среднего расстояния) + - campaign_node (Позиционные звуковые узлы для карты мира, ферм, морей, водопадов) + - campaign_bed (2D окружающие звуки для карты мира, порывы ветра в пустыне, ветер на пастбищах и т. д.) +* **'path'**: Звуковой файл, который будет воспроизводиться. Путь указывается относительно папки ModuleSounds вашего модуля. Вы можете создавать дочерние папки. -### Воспроизведение звука в примере кода +### Пример воспроизведения звука из кода ```C# int soundIndex = SoundEvent.GetEventIdFromString("example/voice/charge"); //чтобы избежать строковых операций во время выполнения, soundIndex можно кэшировать. if (playOneshot) { - MakeSound(soundIndex, MainAgent.Position, false, true, -1, -1); //воспроизводит звук одного выстрела в позиции с заданными параметрами. + MakeSound(soundIndex, MainAgent.Position, false, true, -1, -1); //воспроизводит одиночный звук в указанной позиции с заданными параметрами. } else { - SoundEvent eventRef = SoundEvent.CreateEvent(soundIndex, Scene); //получить ссылку на звук и обновить параметры позже. + SoundEvent eventRef = SoundEvent.CreateEvent(soundIndex, Scene); //получить ссылку на звук и обновлять параметры позже. eventRef.SetPosition(MainAgent.Position); eventRef.Play(); } ``` -У вас есть два способа воспроизвести звук: +У вас есть два способа воспроизведения звука: -* Один выстрел - Лучшая производительность меньше контроля. Стреляй и забудь. Подходит для звуков, связанных с боем. +* Одиночное воспроизведение (One Shot) + Лучшая производительность, меньше контроля. Запустил и забыл. Хорошо подходит для звуков, связанных с боем. * Создание и хранение ссылки - Хуже производительность. Контролируйте каждый параметр звука, когда захотите. т.е. пауза, обновление позиции. \ No newline at end of file + Худшая производительность. Контроль над каждым параметром звука в любой момент. Например, пауза, обновление позиции. diff --git a/docs/content/russian/Audio Modding/_index.md b/docs/content/russian/Audio Modding/_index.md index 6e3a5ae3..039ff8b3 100644 --- a/docs/content/russian/Audio Modding/_index.md +++ b/docs/content/russian/Audio Modding/_index.md @@ -1,5 +1,5 @@ +++ -title = "Audio Modding" +title = "Моддинг звука" description = "" weight = 5 +++ diff --git a/docs/content/russian/Audio Modding/audio-modding-event-setup.md b/docs/content/russian/Audio Modding/audio-modding-event-setup.md index 52b6a9b3..4145508c 100644 --- a/docs/content/russian/Audio Modding/audio-modding-event-setup.md +++ b/docs/content/russian/Audio Modding/audio-modding-event-setup.md @@ -1,164 +1,165 @@ +++ -title = "Event Setup" +title = "Настройка событий (Event Setup)" weight = 20 +ai_translated = true +++ -_Last updated: April 3, 2026_ +_Последнее обновление: 3 апреля 2026 г._ --- -## Parameters +## Параметры (Parameters) -Parameters in FMOD Studio are variables that control how an event behaves during playback. They can drive changes in volume, pitch, filters, instrument playback, or event logic — making sounds dynamic and responsive rather than static. +Параметры в FMOD Studio — это переменные, которые управляют поведением события (event) во время воспроизведения. Они могут влиять на изменения громкости, высоты тона, фильтров, воспроизведения инструментов или логики события — делая звуки динамичными и отзывчивыми, а не статичными. -Each parameter has a name, a range of values, and a type. During gameplay, your code can set or adjust these values, or they can be driven automatically by game states, distance, velocity, or other inputs. +У каждого параметра есть имя, диапазон значений и тип. Во время игры ваш код может устанавливать или изменять эти значения, либо они могут управляться автоматически состояниями игры, расстоянием, скоростью или другими входными данными. -Parameters are the main bridge between the game and the sound design. They let audio react directly to gameplay, giving you fine-grained, real-time control over how sound evolves. +Параметры — это главный мост между игрой и звуковым дизайном. Они позволяют звуку напрямую реагировать на игровой процесс, давая вам точный, детальный контроль в реальном времени над тем, как развивается звук. -You can use existing parameters or create your own presets. To view existing parameters, go to **Window > Preset Browser** or press **Ctrl+8** to open the Preset Browser. +Вы можете использовать существующие параметры или создавать собственные пресеты. Чтобы просмотреть существующие параметры, перейдите в **Window > Preset Browser** или нажмите **Ctrl+8**, чтобы открыть Preset Browser. -### Adding Parameters +### Добавление параметров (Adding Parameters) -To add a custom parameter, click **New Parameter** or press **Ctrl+P**. This opens the **Add Parameter** dialog. +Чтобы добавить пользовательский параметр, нажмите **New Parameter** или **Ctrl+P**. Откроется диалоговое окно **Add Parameter**. -| Field | Description | +| Поле | Описание | |---|---| -| **Parameter Type** | Defines what kind of values the parameter accepts (see types below) | -| **Parameter Name** | A unique, self-explanatory identifier | -| **Range** | Minimum and maximum values | -| **Labels** | Names for each label, if using a Labeled type | -| **Initial Value** | The default value when the event starts | -| **Parameter Scope** | Local (separate per instance) or Global (shared across all instances) | +| **Parameter Type** | Определяет, какие значения принимает параметр (см. типы ниже) | +| **Parameter Name** | Уникальный, понятный идентификатор | +| **Range** | Минимальное и максимальное значения | +| **Labels** | Имена для каждой метки, если используется тип Labeled | +| **Initial Value** | Значение по умолчанию при запуске события | +| **Parameter Scope** | Local (отдельно для каждого экземпляра) или Global (общее для всех экземпляров) | -**Parameter Types:** +**Типы параметров (Parameter Types):** -| Type | Description | +| Тип | Описание | |---|---| -| User: Continuous | Float values for smooth, gradual changes | -| User: Discrete | Integer values for stepped states | -| User: Labeled | String values for named categories | -| Built-in: Distance | Listener–emitter distance | -| Built-in: Distance (Normalized) | Distance scaled 0–1 by min/max | -| Built-in: Direction | Horizontal angle relative to listener facing | -| Built-in: Elevation | Vertical angle relative to listener | -| Built-in: Event Cone Angle | Emitter's facing direction relative to the listener | -| Built-in: Event Orientation | Difference in facing between listener and emitter | -| Built-in: Speed (Relative) | Emitter speed relative to listener | -| Built-in: Speed (Absolute) | World-space emitter speed | - -**Additional options in the dialog:** - -| Option | Description | +| User: Continuous | Значения с плавающей точкой для плавных, постепенных изменений | +| User: Discrete | Целочисленные значения для ступенчатых состояний | +| User: Labeled | Строковые значения для именованных категорий | +| Built-in: Distance | Расстояние между слушателем и источником звука | +| Built-in: Distance (Normalized) | Расстояние, нормализованное от 0 до 1 по мин/макс значениям | +| Built-in: Direction | Горизонтальный угол относительно направления взгляда слушателя | +| Built-in: Elevation | Вертикальный угол относительно слушателя | +| Built-in: Event Cone Angle | Направление, в котором смотрит источник звука, относительно слушателя | +| Built-in: Event Orientation | Разница в направлении между слушателем и источником звука | +| Built-in: Speed (Relative) | Скорость источника звука относительно слушателя | +| Built-in: Speed (Absolute) | Скорость источника звука в мировом пространстве | + +**Дополнительные параметры в диалоговом окне:** + +| Опция | Описание | |---|---| -| Exposed recursively via event instrument | Makes the parameter accessible through nested event instruments | -| Read-only | The parameter can be monitored but not modified | -| Hold value during playback | Local held parameters can only be set before an event starts or when it is stopped/paused. Global held parameters cannot be changed by the game at all. | +| Exposed recursively via event instrument | Делает параметр доступным через вложенные инструменты событий | +| Read-only | Параметр можно отслеживать, но нельзя изменять | +| Hold value during playback | Удерживаемые локальные параметры можно устанавливать только до начала события или когда оно остановлено/приостановлено. Удерживаемые глобальные параметры вообще не могут изменяться игрой. | --- -### Global Parameters +### Глобальные параметры (Global Parameters) -Global parameters are project-wide variables that exist once, affect any event that references them, and can be read or modified from anywhere. +Глобальные параметры — это переменные уровня всего проекта, которые существуют в единственном экземпляре, влияют на любое событие, ссылающееся на них, и могут читаться или изменяться из любого места. -| Name | Type | Range / Default | Description | +| Имя | Тип | Диапазон / По умолчанию | Описание | |---|---|---|---| -| ArenaIntensity | Discrete | 1–3, default: 1 | Number of people in the arena audience. **1** = Low, **2** = Medium, **3** = High | -| CampaignCameraHeight | Continuous | 0.0–1000.0, default: 0.0 | Camera distance above campaign terrain | -| Daytime | Continuous | 0.0–24.0, default: 12.0 | Time of day in 24-hour format | -| MissionCombatMode | Labeled | default: False | **True** = Scene is in combat, **False** = Scene is non-combat | -| MissionCulture | Labeled | default: None | Culture assigned to the scene: None, Aserai, Battania, Empire, Khuzait, Sturgia, Vlandia, Nord _(War Sails DLC)_, Outlaw, Reserved A, Reserved B | -| MissionProsperity | Labeled | default: None | Prosperity level: None _(e.g. Hideouts)_, Low, Medium, High | -| Rainfall | Continuous | 0.0–1.0, default: 0.0 | Rain presence and intensity. **0.0** = no rain | -| SceneType | Labeled | default: Exterior | **Exterior** = Outdoor scene, **Interior** = Indoor scene | -| Season | Labeled | default: Summer | Summer, Fall, Winter, Spring | -| SlowMotionMode | Labeled | default: False | **False** = Normal speed, **True** = Slow motion enabled | -| SoundPreset | Labeled | default: Speakers | Audio output profile: Speakers, Headphones, TV, Night Mode | -| WaveHeight | Continuous | −10.0–10.0, default: −10.0 | Vertical height of waves | -| WaveStrength | Continuous | 0.0–10.0, default: 0.0 | Intensity of wave motion | -| WindStrength | Continuous | 0.0–10.0, default: 0.0 | Intensity of wind | +| ArenaIntensity | Discrete | 1–3, по умолчанию: 1 | Количество людей на арене среди зрителей. **1** = Низкое, **2** = Среднее, **3** = Высокое | +| CampaignCameraHeight | Continuous | 0.0–1000.0, по умолчанию: 0.0 | Высота камеры над рельефом карты кампании | +| Daytime | Continuous | 0.0–24.0, по умолчанию: 12.0 | Время суток в 24-часовом формате | +| MissionCombatMode | Labeled | по умолчанию: False | **True** = Сцена находится в бою, **False** = Сцена не боевая | +| MissionCulture | Labeled | по умолчанию: None | Культура, назначенная сцене: None, Aserai, Battania, Empire, Khuzait, Sturgia, Vlandia, Nord _(War Sails DLC)_, Outlaw, Reserved A, Reserved B | +| MissionProsperity | Labeled | по умолчанию: None | Уровень процветания: None _(например, Hideouts)_, Low, Medium, High | +| Rainfall | Continuous | 0.0–1.0, по умолчанию: 0.0 | Наличие и интенсивность дождя. **0.0** = нет дождя | +| SceneType | Labeled | по умолчанию: Exterior | **Exterior** = Сцена на открытом воздухе, **Interior** = Сцена в помещении | +| Season | Labeled | по умолчанию: Summer | Summer, Fall, Winter, Spring | +| SlowMotionMode | Labeled | по умолчанию: False | **False** = Обычная скорость, **True** = Включён замедленный режим | +| SoundPreset | Labeled | по умолчанию: Speakers | Профиль аудиовывода: Speakers, Headphones, TV, Night Mode | +| WaveHeight | Continuous | −10.0–10.0, по умолчанию: −10.0 | Высота волн по вертикали | +| WaveStrength | Continuous | 0.0–10.0, по умолчанию: 0.0 | Интенсивность движения волн | +| WindStrength | Continuous | 0.0–10.0, по умолчанию: 0.0 | Интенсивность ветра | --- -### Local Parameters +### Локальные параметры (Local Parameters) -Local parameters belong to a specific event instance. Each instance keeps its own value and changes don't affect any other event. +Локальные параметры принадлежат конкретному экземпляру события. Каждый экземпляр хранит собственное значение, и изменения не влияют на другие события. -| Name | Type | Range / Default | Description | +| Имя | Тип | Диапазон / По умолчанию | Описание | |---|---|---|---| -| agent_state | Labeled | default: nothing | Awareness level of agents during stealth missions. **nothing** = unaware, **neutral** = briefly noticed, **cautious** = detected signs, **super_cautious** = actively searching, **alarmed** = located and alerted | -| Alert Distance | Built-in: Distance | 0.0–10.0 | Distance at which mission alerts trigger relative to the player | -| Armor Type | Continuous | 0.0–0.5, default: 0.0 | Armor worn by player/agent. **0.0–0.15** = Cloth, **0.15–0.25** = Leather, **0.25–0.35** = Chain mail, **0.35–0.5** = Plate mail | -| ArmySize | Continuous | 0.0–20.0, default: 0.0 | Size of an army on the campaign map | -| battle_size | Continuous | 0.0–4.0, default: 0.0 | Total troop count in a campaign map battle | -| Crowd Size | Continuous | 0.0–1000.0, default: 0.0 | Number of troops gathered at a location | -| Depth | Continuous | 0.0–1.0, default: 0.0 | Water depth | -| Direction | Built-in: Direction | −180.0–180.0 | Angle between listener facing and line to emitter. **0** = in front, **±90** = to the side, **±180** = behind | -| Distance Ambient 20 | Built-in: Distance | 0.0–50.0 | Distance of 3D ambient events within 50 m | -| Distance Campaign Node | Built-in: Distance | 0.0–30.0 | Distance of 3D campaign node events within 30 m | -| Distance Combat 500 | Built-in: Distance | 0.0–500.0 | Distance of combat sound events within 500 m | -| Distance Gallop 500 | Built-in: Distance | 0.0–500.0 | Distance of mount gallop events within 500 m | -| Distance Horse Walk 35 | Built-in: Distance | 0.0–35.0 | Distance of mount walking events within 35 m | -| Distance Human Walk 150 | Built-in: Distance | 0.0–150.0 | Distance of human walking events within 150 m | -| Distance Impact 75 | Built-in: Distance | 0.0–75.0 | Distance of impact events within 75 m | -| Distance Siege 500 | Built-in: Distance | 0.0–500.0 | Distance of siege events within 500 m | -| Distance Siege Med 250 | Built-in: Distance | 0.0–250.0 | Distance of siege events within 250 m | -| Distance Tavern Music | Built-in: Distance | 0.0–100.0 | Distance of tavern/street music events within 100 m | -| Distance Voice Long | Built-in: Distance | 0.0–500.0 | Distance of voice events within 500 m | -| Distance | Built-in: Distance | 0.0–80.0 | Generic distance parameter (default 80 m) | -| Event Cone Angle | Built-in: Event Cone Angle | 0.0–180.0 | How far the listener is from the emitter's forward direction. **0** = directly in front, **90** = to the side, **180** = directly behind | -| Event Orientation | Built-in: Event Orientation | −180.0–180.0 | Difference in facing between listener and emitter. **0** = same direction, **±90** = perpendicular, **±180** = opposite | -| Force | Continuous | 0.0–0.1, default: 0.57 | Instant physical force applied to an object | -| ForceContinuous | Continuous | 0.0–1.0, default: 0.0 | Continuous physical force applied to an object | -| impactModifier | Continuous | 0.0–0.6, default: 0.0 | Defensive block modifier. **0.0** = None, **0.1** = Active block, **0.2** = Chamber block, **0.3** = Crush through | -| isMissile | Continuous | 0.0–1.0, default: 0.0 | Whether the object is a projectile | -| isPlayer | Continuous | 0.0–1.0 | Whether the agent is the player. **0.0** = NPC, **1.0** = Player | -| Loop | Continuous | 0.0–1.0, default: 0.0 | Whether an event loops (music/video) | -| mpMusicSwitcher | Continuous | 0.0–1.0, default: 0.0 | Multiplayer state music. **0.0** = Main menu, **1.0** = Loading state | -| Occlusion | Continuous | 0.0–1.0, default: 0.0 | Degree of sound occlusion. **0.0** = None, **1.0** = Full | -| Size | Continuous | 0.0–1.0, default: 0.0 | Mass of an object (affects water collision sounds) | -| Speed | Built-in: Speed (Relative) | 0.0–10.0 | Relative speed of a game object | -| VibrationSend | Continuous | 0.0–1.0, default: 1.0 | Intensity of controller vibration | +| agent_state | Labeled | по умолчанию: nothing | Уровень осведомлённости агентов во время скрытных миссий. **nothing** = не замечает, **neutral** = ненадолго заметил, **cautious** = обнаружил признаки, **super_cautious** = активно ищет, **alarmed** = обнаружил и поднял тревогу | +| Alert Distance | Built-in: Distance | 0.0–10.0 | Расстояние, на котором срабатывают тревоги миссии относительно игрока | +| Armor Type | Continuous | 0.0–0.5, по умолчанию: 0.0 | Доспехи, надетые на игрока/агента. **0.0–0.15** = Ткань, **0.15–0.25** = Кожа, **0.25–0.35** = Кольчуга, **0.35–0.5** = Латы | +| ArmySize | Continuous | 0.0–20.0, по умолчанию: 0.0 | Размер армии на карте кампании | +| battle_size | Continuous | 0.0–4.0, по умолчанию: 0.0 | Общее количество войск в сражении на карте кампании | +| Crowd Size | Continuous | 0.0–1000.0, по умолчанию: 0.0 | Количество войск, собравшихся в определённом месте | +| Depth | Continuous | 0.0–1.0, по умолчанию: 0.0 | Глубина воды | +| Direction | Built-in: Direction | −180.0–180.0 | Угол между направлением взгляда слушателя и линией до источника звука. **0** = спереди, **±90** = сбоку, **±180** = сзади | +| Distance Ambient 20 | Built-in: Distance | 0.0–50.0 | Расстояние 3D фоновых событий в пределах 50 м | +| Distance Campaign Node | Built-in: Distance | 0.0–30.0 | Расстояние 3D событий узлов карты кампании в пределах 30 м | +| Distance Combat 500 | Built-in: Distance | 0.0–500.0 | Расстояние боевых звуковых событий в пределах 500 м | +| Distance Gallop 500 | Built-in: Distance | 0.0–500.0 | Расстояние событий галопа верхового животного в пределах 500 м | +| Distance Horse Walk 35 | Built-in: Distance | 0.0–35.0 | Расстояние событий ходьбы верхового животного в пределах 35 м | +| Distance Human Walk 150 | Built-in: Distance | 0.0–150.0 | Расстояние событий ходьбы человека в пределах 150 м | +| Distance Impact 75 | Built-in: Distance | 0.0–75.0 | Расстояние событий удара в пределах 75 м | +| Distance Siege 500 | Built-in: Distance | 0.0–500.0 | Расстояние осадных событий в пределах 500 м | +| Distance Siege Med 250 | Built-in: Distance | 0.0–250.0 | Расстояние осадных событий в пределах 250 м | +| Distance Tavern Music | Built-in: Distance | 0.0–100.0 | Расстояние событий музыки в таверне/на улице в пределах 100 м | +| Distance Voice Long | Built-in: Distance | 0.0–500.0 | Расстояние голосовых событий в пределах 500 м | +| Distance | Built-in: Distance | 0.0–80.0 | Общий параметр расстояния (по умолчанию 80 м) | +| Event Cone Angle | Built-in: Event Cone Angle | 0.0–180.0 | Насколько далеко слушатель находится от направления взгляда источника звука. **0** = прямо впереди, **90** = сбоку, **180** = прямо позади | +| Event Orientation | Built-in: Event Orientation | −180.0–180.0 | Разница в направлении между слушателем и источником звука. **0** = одно направление, **±90** = перпендикулярно, **±180** = противоположное направление | +| Force | Continuous | 0.0–0.1, по умолчанию: 0.57 | Мгновенная физическая сила, приложенная к объекту | +| ForceContinuous | Continuous | 0.0–1.0, по умолчанию: 0.0 | Постоянная физическая сила, приложенная к объекту | +| impactModifier | Continuous | 0.0–0.6, по умолчанию: 0.0 | Модификатор защитного блока. **0.0** = Нет, **0.1** = Активный блок, **0.2** = Чамбер-блок (chamber block), **0.3** = Проламывающий удар (crush through) | +| isMissile | Continuous | 0.0–1.0, по умолчанию: 0.0 | Является ли объект снарядом | +| isPlayer | Continuous | 0.0–1.0 | Является ли агент игроком. **0.0** = NPC, **1.0** = Игрок | +| Loop | Continuous | 0.0–1.0, по умолчанию: 0.0 | Зацикливается ли событие (музыка/видео) | +| mpMusicSwitcher | Continuous | 0.0–1.0, по умолчанию: 0.0 | Музыка состояния мультиплеера. **0.0** = Главное меню, **1.0** = Состояние загрузки | +| Occlusion | Continuous | 0.0–1.0, по умолчанию: 0.0 | Степень окклюзии звука. **0.0** = Нет, **1.0** = Полная | +| Size | Continuous | 0.0–1.0, по умолчанию: 0.0 | Масса объекта (влияет на звуки столкновения с водой) | +| Speed | Built-in: Speed (Relative) | 0.0–10.0 | Относительная скорость игрового объекта | +| VibrationSend | Continuous | 0.0–1.0, по умолчанию: 1.0 | Интенсивность вибрации контроллера | --- -### War Sails Parameters +### Параметры War Sails (War Sails Parameters) -These parameters only exist in the War Sails DLC module and are not available without it. +Эти параметры существуют только в модуле дополнения War Sails и недоступны без него. -| Name | Type | Range / Default | Description | +| Имя | Тип | Диапазон / По умолчанию | Описание | |---|---|---|---| -| Campaign Ship Damage | Continuous | 0.0–1.0, default: 0.0 | Damage sustained by the player's ship on the campaign map | -| RowingPower | Continuous | 0.0–500.0, default: 0 | Collective force applied by oarsmen | -| RudderStress | Continuous | 0.0–1.0, default: 0.0 | Stress applied to the ship's rudder during maneuvering | -| SailRotation | Continuous | 0.0–1.0, default: 0.0 | Rotation speed of the ship's mast | -| ShipScrapingStatus | Labeled | default: NotScraping | **Scraping** = Ship is scraping, **NotScraping** = No scraping | -| ShipSpeed | Continuous | 0.0–1.0, default: 0.0 | Current speed of the ship | -| StormIntensity | Continuous | 0.0–2.0, default: 0.0 | Storm intensity on the campaign map. **0.0** = Storm, **1.0** = Thunderstorm, **2.0** = Hurricane | +| Campaign Ship Damage | Continuous | 0.0–1.0, по умолчанию: 0.0 | Повреждения, полученные кораблём игрока на карте кампании | +| RowingPower | Continuous | 0.0–500.0, по умолчанию: 0 | Совокупная сила, прикладываемая гребцами | +| RudderStress | Continuous | 0.0–1.0, по умолчанию: 0.0 | Нагрузка на руль корабля во время манёвров | +| SailRotation | Continuous | 0.0–1.0, по умолчанию: 0.0 | Скорость вращения мачты корабля | +| ShipScrapingStatus | Labeled | по умолчанию: NotScraping | **Scraping** = Корабль скребёт (о поверхность), **NotScraping** = Нет скрежета | +| ShipSpeed | Continuous | 0.0–1.0, по умолчанию: 0.0 | Текущая скорость корабля | +| StormIntensity | Continuous | 0.0–2.0, по умолчанию: 0.0 | Интенсивность шторма на карте кампании. **0.0** = Шторм, **1.0** = Гроза, **2.0** = Ураган | --- -## Effects Presets +## Пресеты эффектов (Effects Presets) -Effect presets are pre-configured DSP setups that cover common use cases without manual configuration from scratch. Instead of building every effect chain yourself, you can apply a preset — such as a compressor, EQ, or reverb — that comes with sensible defaults designed for a specific purpose. +Пресеты эффектов — это предварительно настроенные конфигурации DSP, которые охватывают типичные случаи использования без необходимости ручной настройки с нуля. Вместо того чтобы самостоятельно строить каждую цепочку эффектов, вы можете применить пресет — например, компрессор, эквалайзер или реверберацию — с разумными значениями по умолчанию, предназначенными для конкретной цели. -Presets let you get immediate results and fine-tune from there. They speed up workflow, ensure consistency across the project, and give everyone a shared baseline for commonly used effects. You can also create your own custom presets, or modify the existing ones. +Пресеты позволяют сразу получить результат и затем точно настроить его. Они ускоряют рабочий процесс, обеспечивают согласованность по всему проекту и дают всем общую базовую точку для часто используемых эффектов. Вы также можете создавать собственные пользовательские пресеты или изменять существующие. -To browse presets, go to **Window > Effect Presets** or press **Ctrl+8**. In the Preset Browser, select the **Effects** tab to see all pre-configured presets currently used in **Mount & Blade II: Bannerlord**. +Чтобы просмотреть пресеты, перейдите в **Window > Effect Presets** или нажмите **Ctrl+8**. В Preset Browser выберите вкладку **Effects**, чтобы увидеть все предварительно настроенные пресеты, используемые в настоящее время в **Mount & Blade II: Bannerlord**. -When adding a new preset, you have these options: +При добавлении нового пресета доступны следующие опции: -| Option | Description | +| Опция | Описание | |---|---| -| **New Effect** | Add a single DSP effect and configure it | -| **New Send** | Add and configure a bus send | -| **New Sidechain** | Add and configure a sidechain input | -| **New Effect Chain** | Build a chain of multiple DSP effects and configure them together | +| **New Effect** | Добавить один DSP-эффект и настроить его | +| **New Send** | Добавить и настроить отправку шины (bus send) | +| **New Sidechain** | Добавить и настроить вход sidechain | +| **New Effect Chain** | Построить цепочку из нескольких DSP-эффектов и настроить их вместе | -Once a preset is created, give it a unique, self-explanatory name so it can be easily identified and reused across the project. +После создания пресета дайте ему уникальное, понятное имя, чтобы его было легко идентифицировать и повторно использовать в проекте. -### Effects Preset List +### Список пресетов эффектов (Effects Preset List) -| Name | Type | Driving Parameter(s) | +| Имя | Тип | Управляющий(е) параметр(ы) | |---|---|---| | Alert Nod Spatializer | Spatializer | — | | Alert Spatializer | Spatializer | Alert Distance | @@ -235,53 +236,53 @@ Once a preset is created, give it a unique, self-explanatory name so it can be e --- -## Snapshots +## Снапшоты (Snapshots) -Snapshots let you control the overall mix dynamically based on game states. If you've ever seen a digital mixing console where pressing a button moves all the faders to new positions at once — that's exactly how FMOD snapshots work. +Снапшоты позволяют динамически управлять общим миксом в зависимости от состояний игры. Если вы когда-нибудь видели цифровой микшерный пульт, где нажатие кнопки мгновенно перемещает все фейдеры в новые положения — именно так работают снапшоты FMOD. -### Adding Snapshots +### Добавление снапшотов (Adding Snapshots) -To add a snapshot, open the Mixer window via **Window > Mixer** or press **Ctrl+2**. On the left side of the Mixer, switch to the **Snapshots** tab to see existing snapshots or create new ones. +Чтобы добавить снапшот, откройте окно Mixer через **Window > Mixer** или нажмите **Ctrl+2**. В левой части Mixer переключитесь на вкладку **Snapshots**, чтобы увидеть существующие снапшоты или создать новые. -Right-click on an empty space to create a new snapshot. You'll be asked to choose between two types: +Щёлкните правой кнопкой мыши по пустому месту, чтобы создать новый снапшот. Вам будет предложено выбрать один из двух типов: -| Type | Description | +| Тип | Описание | |---|---| -| **Overriding Snapshot** | Takes full control of the affected mix properties, replacing existing values until released | -| **Blending Snapshot** | Layers its changes on top of the current mix, combining with other active snapshots for smoother transitions | +| **Overriding Snapshot** | Полностью берёт под контроль затронутые свойства микса, заменяя существующие значения до момента освобождения | +| **Blending Snapshot** | Накладывает свои изменения поверх текущего микса, комбинируясь с другими активными снапшотами для более плавных переходов | -When multiple snapshots are active simultaneously, priority is determined by their position in the **Priority List**. Snapshots higher in the list take precedence over those below. For example, `GameMinimized` sits above `CampaignMap` in the priority list, meaning it overrides campaign map audio rules whenever the game is minimized. +Когда одновременно активны несколько снапшотов, приоритет определяется их позицией в **Priority List**. Снапшоты выше в списке имеют приоритет над теми, что ниже. Например, `GameMinimized` находится выше `CampaignMap` в списке приоритетов, что означает, что он переопределяет правила звука карты кампании всякий раз, когда игра свёрнута. -When a snapshot is selected, the faders in the Mixer change color — this signals that any fader you adjust will only apply when that snapshot is active, not in the normal mix. The same applies to DSP effects and bus sends — for example, you can add a single algorithmic reverb to a return bus and adjust its properties per snapshot. +Когда снапшот выбран, фейдеры в Mixer меняют цвет — это означает, что любой фейдер, который вы настраиваете, будет применяться только тогда, когда этот снапшот активен, а не в обычном миксе. То же самое относится к DSP-эффектам и отправкам шин (bus sends) — например, вы можете добавить один алгоритмический ревербератор на возвратную шину (return bus) и настраивать его свойства для каждого снапшота отдельно. -In the `GameMinimized` snapshot, all faders are set to −∞ dB, so that whenever the player minimizes the game window, every sound is muted. Once the snapshot goes out of scope, the faders automatically return to their original positions. +В снапшоте `GameMinimized` все фейдеры установлены на −∞ дБ, поэтому всякий раз, когда игрок сворачивает окно игры, все звуки заглушаются. Как только снапшот выходит из области действия, фейдеры автоматически возвращаются в исходное положение. -### Snapshot Events +### События снапшотов (Snapshot Events) -Snapshots can be triggered by code, but they can also be triggered by events — which is especially useful for reverb zones in a scene. For more on reverb zones, see the [Scene Audio]({{< ref "audio-modding-scene-audio.md" >}}) page. +Снапшоты могут запускаться кодом, но также могут запускаться событиями — что особенно полезно для зон реверберации в сцене. Подробнее о зонах реверберации см. на странице [Звук сцены (Scene Audio)]({{< ref "audio-modding-scene-audio.md" >}}). -To add a snapshot event, first create a **timeline event** (snapshot instruments cannot be placed in action events). Give the event a clear, descriptive name. +Чтобы добавить событие снапшота, сначала создайте **событие временной шкалы (timeline event)** (инструменты снапшотов нельзя размещать в событиях действия (action events)). Дайте событию понятное, описательное имя. -Right-click the track in the timeline where you want to place the snapshot instrument. If a snapshot already exists you'll see it listed; otherwise you can create a new one. For reverb control, always use **blending snapshots**. +Щёлкните правой кнопкой мыши по дорожке на временной шкале, куда вы хотите поместить инструмент снапшота. Если снапшот уже существует, вы увидите его в списке; в противном случае вы можете создать новый. Для управления реверберацией всегда используйте **смешивающие снапшоты (blending snapshots)**. -Once placed, the snapshot instrument appears on the track. You can drag the left and right edges of the instrument to add fade-in and fade-out handles, which smooth the transition into and out of the snapshot. +После размещения инструмент снапшота появляется на дорожке. Вы можете перетаскивать левый и правый края инструмента, чтобы добавить маркеры нарастания и затухания (fade-in и fade-out), которые сглаживают переход в снапшот и из него. --- -## User Properties +## Пользовательские свойства (User Properties) -Events in FMOD Studio can carry **User Properties** — custom variables you define to pass extra information to the game. These act as metadata markers, letting the game code check for them and apply special handling when needed. +События в FMOD Studio могут иметь **пользовательские свойства (User Properties)** — пользовательские переменные, которые вы определяете, чтобы передавать дополнительную информацию в игру. Они действуют как метки метаданных, позволяя игровому коду проверять их наличие и применять специальную обработку при необходимости. -Every User Property has a name and a value. The name is always a string (letters and/or numbers). The value is interpreted automatically: if it's purely numeric, it's treated as a floating-point number; if it contains any non-numeric characters, it's treated as a string. +Каждое пользовательское свойство имеет имя и значение. Имя всегда является строкой (буквы и/или цифры). Значение интерпретируется автоматически: если оно состоит исключительно из цифр, оно рассматривается как число с плавающей точкой; если оно содержит любые нечисловые символы, оно рассматривается как строка. -This system lets sound designers embed flexible, game-relevant data directly inside events, reducing the need for programmers to hard-code rules. User Properties are defined in the event's deck area in FMOD Studio — each row has a name field and a value field. +Эта система позволяет звуковым дизайнерам встраивать гибкие, релевантные для игры данные непосредственно внутрь событий, снижая необходимость для программистов жёстко прописывать правила в коде. Пользовательские свойства определяются в области деки (deck area) события в FMOD Studio — каждая строка имеет поле имени и поле значения. -| Property | Description | +| Свойство | Описание | |---|---| -| **isQuad** | Used for ambient sounds. When set to `True`, the system will use the quadraphonic version of the ambient instead of the stereo fallback. A matching quad setup must exist before enabling this. See [Quadraphonic Ambients]({{< ref "audio-modding-scene-audio.md#quadraphonic-ambients" >}}). | -| **Pausable** | Used by the event-based pausing system. Default is `True`. Set to `False` for persistent events such as ambiences or music that should not be paused. | -| **priorityMultiplier** | Adjusts the relative priority of an event within the priority system — raising or lowering its likelihood of being culled. See [Priority System]({{< ref "audio-modding-systems.md#priority-system" >}}). | -| **maxLength** | Prevents build errors for timeline events without a timeline or instrument. Defines a duration so FMOD has the necessary length data without a timeline track. Not needed for Action events. | -| **battle_ambient_group_id** | Assigns an event to a specific group in the Battle Ambient Sound System (BASS), allowing events to be managed and optimized collectively. See [Battle Ambient Sound System]({{< ref "audio-modding-systems.md#battle-ambient-sound-system" >}}). | -| **customMaxDistance** | Overrides the default maximum audible distance of a 3D event. | -| **ignoreMaxDistance** | Ignores the maximum distance restriction of a 3D event. Accepts `0` (False) or `1` (True). | +| **isQuad** | Используется для фоновых звуков. Когда установлено в `True`, система будет использовать квадрофоническую версию фонового звука вместо стереофонического резервного варианта. Перед включением этой опции должна существовать соответствующая квадро-конфигурация. См. [Квадрофонические фоновые звуки (Quadraphonic Ambients)]({{< ref "audio-modding-scene-audio.md#quadraphonic-ambients" >}}). | +| **Pausable** | Используется системой паузы на основе событий. По умолчанию `True`. Установите `False` для постоянных событий, таких как фоновые звуки или музыка, которые не должны ставиться на паузу. | +| **priorityMultiplier** | Регулирует относительный приоритет события в системе приоритетов — повышая или понижая вероятность его отбрасывания (culled). См. [Система приоритетов (Priority System)]({{< ref "audio-modding-systems.md#priority-system" >}}). | +| **maxLength** | Предотвращает ошибки сборки для событий временной шкалы без временной шкалы или инструмента. Определяет длительность, чтобы у FMOD были необходимые данные о длине без дорожки временной шкалы. Не требуется для событий действия (Action events). | +| **battle_ambient_group_id** | Назначает событие определённой группе в системе Battle Ambient Sound System (BASS), позволяя управлять событиями и оптимизировать их совместно. См. [Battle Ambient Sound System]({{< ref "audio-modding-systems.md#battle-ambient-sound-system" >}}). | +| **customMaxDistance** | Переопределяет максимальное расстояние слышимости по умолчанию для 3D-события. | +| **ignoreMaxDistance** | Игнорирует ограничение максимального расстояния для 3D-события. Принимает значения `0` (False) или `1` (True). | diff --git a/docs/content/russian/Audio Modding/audio-modding-overview.md b/docs/content/russian/Audio Modding/audio-modding-overview.md index 1c1e56a6..480b3b97 100644 --- a/docs/content/russian/Audio Modding/audio-modding-overview.md +++ b/docs/content/russian/Audio Modding/audio-modding-overview.md @@ -1,43 +1,44 @@ +++ -title = "Audio Modding with FMOD Studio" +title = "Моддинг звука с помощью FMOD Studio" weight = 10 +ai_translated = true +++ -_Last updated: April 3, 2026_ +_Последнее обновление: 3 апреля 2026 г._ --- -## Introduction +## Введение -This guide is not a replacement for the official FMOD Studio manual. If you're completely new to FMOD Studio or audio middleware in general, we recommend starting with the official documentation on FMOD's website before diving in here. +Это руководство не заменяет официальное руководство по FMOD Studio. Если вы совершенно новичок в FMOD Studio или в аудио-middleware в целом, мы рекомендуем сначала ознакомиться с официальной документацией на сайте FMOD, прежде чем переходить к этому руководству. -The purpose of this guide is to give you an up-to-date, Bannerlord-specific reference that helps you work efficiently with FMOD. It focuses on workflows, best practices, and performance considerations that are unique to **Mount & Blade II: Bannerlord**. +Цель этого руководства — предоставить вам актуальный справочник, специфичный для Bannerlord, который поможет вам эффективно работать с FMOD. Оно сосредоточено на рабочих процессах, лучших практиках и аспектах производительности, которые уникальны для **Mount & Blade II: Bannerlord**. -With direct FMOD Studio support, modders now have access to nearly all of the tools used internally by the game's audio team. That means you can: +Благодаря прямой поддержке FMOD Studio у моддеров теперь есть доступ почти ко всем инструментам, которые внутренняя аудиокоманда игры использует сама. Это означает, что вы можете: -- Add and configure events -- Create instruments and layers -- Apply automations and modulations -- Build and manage soundbanks -- Add or re-route busses -- Create and tune snapshots -- Define or modify parameters -- Insert DSP effects -- Implement or modify controller vibrations +- Добавлять и настраивать события (events) +- Создавать инструменты и слои +- Применять автоматизации и модуляции +- Создавать и управлять звуковыми банками (soundbanks) +- Добавлять или перенаправлять шины (busses) +- Создавать и настраивать снапшоты (snapshots) +- Определять или изменять параметры +- Вставлять DSP-эффекты +- Реализовывать или изменять вибрацию контроллера -**Mount & Blade II: Bannerlord** is a performance-critical title. Every change you make in FMOD Studio is reflected in real time inside the game, and a poorly optimized setup can hurt both audio quality and overall performance. Because of this, treat optimization as part of your workflow — not something to deal with at the end. +**Mount & Blade II: Bannerlord** — требовательная к производительности игра. Каждое изменение, которое вы вносите в FMOD Studio, отражается в игре в реальном времени, и плохо оптимизированная настройка может навредить как качеству звука, так и общей производительности. Из-за этого относитесь к оптимизации как к части рабочего процесса, а не как к чему-то, что нужно сделать в конце. -A dedicated section of this guide covers performance optimization guidelines. We strongly encourage you to read it before finalizing any FMOD modifications. Following those practices will help you avoid common pitfalls like excessive voice counts, unnecessary DSP load, or inefficient streaming setups. +Отдельный раздел этого руководства посвящён рекомендациям по оптимизации производительности. Мы настоятельно рекомендуем прочитать его перед завершением любых изменений в FMOD. Следование этим рекомендациям поможет вам избежать распространённых проблем, таких как избыточное количество голосов (voice counts), ненужная нагрузка DSP или неэффективная настройка стриминга. --- -## Getting Started +## Начало работы -Before anything shows up in-game, your mod needs to be wired up so that Bannerlord knows where to find your sound data. This involves two steps: registering the required data files in your `.mbproj` file, and generating those files using the FMOD Studio script provided. +Прежде чем что-либо появится в игре, ваш мод должен быть настроен так, чтобы Bannerlord знал, где искать ваши звуковые данные. Это включает два шага: регистрацию необходимых файлов данных в вашем файле `.mbproj` и генерацию этих файлов с помощью предоставленного скрипта FMOD Studio. -### 1. Register Sound Files in Your .mbproj +### 1. Регистрация звуковых файлов в вашем .mbproj -Add the following lines to your mod's `.mbproj` file, inside the `base` scope: +Добавьте следующие строки в файл `.mbproj` вашего мода, внутри области видимости `base`: ```xml @@ -45,44 +46,44 @@ Add the following lines to your mod's `.mbproj` file, inside the `base` scope: ``` -The `name` field specifies the XML file path relative to your mod's directory. The `id` and `type` fields must be kept exactly as shown. +Поле `name` указывает путь к XML-файлу относительно директории вашего мода. Поля `id` и `type` должны оставаться точно такими же, как показано. -### 2. Generate the Data Files +### 2. Генерация файлов данных -All three XML files — along with the associated sound banks — are generated by the **SEDFGen.js** script included with the project. To run it, use the scripting interface inside FMOD Studio: go to **Scripts > Taleworlds**. +Все три XML-файла — вместе с соответствующими звуковыми банками — генерируются скриптом **SEDFGen.js**, входящим в состав проекта. Чтобы запустить его, используйте интерфейс скриптов внутри FMOD Studio: перейдите в **Scripts > Taleworlds**. -The script outputs: +Скрипт выводит: -- XML data files to `ExampleSoundMod/ModuleData/` -- Sound bank files to `ExampleSoundMod/Sounds/` +- Файлы XML-данных в `ExampleSoundMod/ModuleData/` +- Файлы звуковых банков в `ExampleSoundMod/Sounds/` -An example directory structure with all required files is provided for reference. +Для справки предоставлена структура директорий с примером всех необходимых файлов. -### Important: Do Not Include main.bank +### Важно: не включайте main.bank -In `soundfiles.xml`, `main.bank` is intentionally left out. Do **not** add your own `main.bank`. Including it can cause issues such as: +В `soundfiles.xml` файл `main.bank` намеренно не включён. **Не** добавляйте собственный `main.bank`. Его включение может вызвать такие проблемы, как: -- Volume sliders not working correctly -- Sounds not being routed to buses as expected +- Неправильная работа ползунков громкости +- Звуки не маршрутизируются к шинам (buses), как ожидается -You **can** add your own VCAs and buses, as long as you do not modify any of the existing buses and VCAs provided by the base game. +Вы **можете** добавлять собственные VCA и шины, при условии, что вы не изменяете никакие существующие шины и VCA, предоставленные базовой игрой. -### Overriding Existing Sound Events +### Переопределение существующих звуковых событий -To override a sound event that already exists in the game, your event must match the original **exactly** — including the full event path, not just the event name. +Чтобы переопределить звуковое событие, уже существующее в игре, ваше событие должно **в точности** совпадать с оригиналом — включая полный путь события, а не только название события. -For example, to override `event:/mission/combat/sword_hit`, your event must use that exact path. +Например, чтобы переопределить `event:/mission/combat/sword_hit`, ваше событие должно использовать именно этот путь. -### Mod Load Order +### Порядок загрузки модов -If multiple sound mods are active at the same time and any of them define events with identical paths, the **mod loaded last takes priority**. Keep this in mind when publishing your mod or when testing alongside other audio mods. +Если одновременно активно несколько звуковых модов и любой из них определяет события с одинаковыми путями, **приоритет получает мод, загруженный последним**. Учитывайте это при публикации своего мода или при тестировании вместе с другими аудио-модами. --- -## Guide Structure +## Структура руководства -This guide is split into the following pages: +Это руководство разделено на следующие страницы: -- **[Event Setup]({{< ref "audio-modding-event-setup.md" >}})** — Parameters, effects presets, snapshots, and user properties -- **[Scene Audio]({{< ref "audio-modding-scene-audio.md" >}})** — Placing sounds in scenes, reverb zones, animation and particle audio, quadraphonic ambients -- **[Audio Systems & Optimization]({{< ref "audio-modding-systems.md" >}})** — Voice system, physics materials, priority system, battle ambient sound system, and performance guidelines +- **[Настройка событий]({{< ref "audio-modding-event-setup.md" >}})** — параметры, пресеты эффектов, снапшоты и пользовательские свойства +- **[Звук сцены]({{< ref "audio-modding-scene-audio.md" >}})** — размещение звуков в сценах, зоны реверберации, звук анимаций и частиц, квадрафонические амбиенты +- **[Аудиосистемы и оптимизация]({{< ref "audio-modding-systems.md" >}})** — система голосов, физические материалы, система приоритетов, система звукового амбиента боя и рекомендации по производительности diff --git a/docs/content/russian/Audio Modding/audio-modding-scene-audio.md b/docs/content/russian/Audio Modding/audio-modding-scene-audio.md index 7bc91f74..ab47b224 100644 --- a/docs/content/russian/Audio Modding/audio-modding-scene-audio.md +++ b/docs/content/russian/Audio Modding/audio-modding-scene-audio.md @@ -1,52 +1,53 @@ +++ -title = "Scene Audio" +title = "Звук сцены" weight = 30 +ai_translated = true +++ -_Last updated: April 3, 2026_ +_Последнее обновление: 3 апреля 2026 г._ --- -## Adding Sound Entities +## Добавление звуковых сущностей -In our proprietary game engine, placing sounds into a scene is straightforward. Start by creating an **empty entity** in the scene. +В нашем проприетарном игровом движке размещение звуков в сцене выполняется просто. Начните с создания **пустой сущности** (empty entity) в сцене. -Once the entity is added, select it in the scene hierarchy to open the **Inspector Window**. If the Inspector doesn't appear, enable it through **Window > Inspector Window**. +После добавления сущности выберите её в иерархии сцены, чтобы открыть **окно инспектора** (Inspector Window). Если инспектор не появляется, включите его через **Window > Inspector Window**. -In the Inspector, expand the **Scripts** dropdown and choose **Add New Script**. From the dialog, select **AmbientSoundEmitter** to attach a sound emitter script to the entity. +В инспекторе разверните выпадающий список **Scripts** и выберите **Add New Script**. В диалоговом окне выберите **AmbientSoundEmitter**, чтобы прикрепить скрипт излучателя звука к сущности. -The script exposes several options for controlling playback: +Скрипт предоставляет несколько опций для управления воспроизведением: -| Property | Description | +| Свойство | Описание | |---|---| -| **Event Path** | The FMOD event path for the sound to be played in the scene | -| **Play On Startup** | If enabled, the sound plays automatically when the scene loads. Useful for ambiences or persistent sounds | -| **Is Static** | Marks the emitter as fixed in place. Static emitters are cheaper to process since the engine doesn't need to track their position dynamically | -| **Override Sound** | Enables overrides for certain FMOD parameters specifically for 3D sound events | -| **Override Volume Multiplier** | Adjusts playback volume by a multiplier. Use commas (`,`) instead of periods (`.`) for decimal values | -| **Override Max Distance** | Sets a custom maximum audible distance for the event | -| **Override Min Distance** | Sets a custom minimum audible distance for the event | -| **Is Master Sound** | Tags the emitter as a master sound, used for global mix behaviors | -| **Is Master Suppressor** | When active inside a trigger volume, ducks (reduces) any sounds tagged as master sound | -| **Is Triggered** | Configures the emitter as a trigger volume, only playing when the listener enters the defined space | -| **Trigger Shape** | Defines the shape of the trigger volume (box or sphere) | +| **Event Path** | Путь к событию FMOD для звука, который будет проигрываться в сцене | +| **Play On Startup** | Если включено, звук проигрывается автоматически при загрузке сцены. Полезно для амбиентов или постоянных звуков | +| **Is Static** | Помечает излучатель как неподвижный. Статичные излучатели дешевле в обработке, поскольку движку не нужно динамически отслеживать их положение | +| **Override Sound** | Включает переопределения для определённых параметров FMOD, специфичных для 3D звуковых событий | +| **Override Volume Multiplier** | Регулирует громкость воспроизведения с помощью множителя. Используйте запятые (`,`) вместо точек (`.`) для десятичных значений | +| **Override Max Distance** | Задаёт пользовательское максимальное расстояние слышимости для события | +| **Override Min Distance** | Задаёт пользовательское минимальное расстояние слышимости для события | +| **Is Master Sound** | Помечает излучатель как главный звук (master sound), используется для глобального поведения микса | +| **Is Master Suppressor** | Когда активен внутри триггерного объёма, приглушает (уменьшает громкость) любых звуков, помеченных как master sound | +| **Is Triggered** | Настраивает излучатель как триггерный объём, проигрывающийся только когда слушатель входит в заданное пространство | +| **Trigger Shape** | Задаёт форму триггерного объёма (куб или сфера) | --- -## Reverb Zones +## Зоны реверберации -The same process applies when adding reverb zones to a scene. In FMOD, reverbs are snapshot events that can be triggered through trigger volumes, just like standard sound events. +Тот же процесс применяется при добавлении зон реверберации в сцену. В FMOD реверберации являются событиями-снапшотами (snapshot events), которые могут запускаться через триггерные объёмы, так же как и обычные звуковые события. -To set one up: +Чтобы настроить одну из них: -1. Create a new entity in the scene -2. Attach an **AmbientSoundEmitter** script -3. Enter the path to the reverb snapshot event -4. Enable **Is Triggered** -5. Select the appropriate trigger shape -6. Resize the volume using the transform tools to cover the desired area +1. Создайте новую сущность в сцене +2. Прикрепите скрипт **AmbientSoundEmitter** +3. Введите путь к событию-снапшоту реверберации +4. Включите **Is Triggered** +5. Выберите подходящую форму триггера +6. Измените размер объёма с помощью инструментов трансформации, чтобы охватить нужную область -The following snapshot event paths are available out of the box. You're also free to create and add your own snapshots and snapshot events. +Следующие пути событий-снапшотов доступны «из коробки». Вы также можете свободно создавать и добавлять свои собственные снапшоты и события-снапшоты. - `event:/mission/ambient/reverb/alley` - `event:/mission/ambient/reverb/caves` @@ -62,52 +63,52 @@ The following snapshot event paths are available out of the box. You're also fre --- -## Paths +## Пути (Paths) -Paths are routes you can place in a scene for entities to follow. This is useful when you want a sound emitter to move along a defined trajectory relative to the listener — for example, to simulate a river flowing past. +Пути (paths) — это маршруты, которые вы можете размещать в сцене, чтобы сущности следовали по ним. Это полезно, когда вы хотите, чтобы звуковой излучатель двигался по заданной траектории относительно слушателя — например, для имитации реки, протекающей мимо. -### Creating a Path +### Создание пути -1. Click **Add New Path** on the taskbar -2. Assign a name to the path -3. Click **Add Component** -4. Place path points in the scene — they will automatically be connected in order +1. Нажмите **Add New Path** на панели инструментов +2. Присвойте пути имя +3. Нажмите **Add Component** +4. Разместите точки пути в сцене — они будут автоматически соединены по порядку -To attach a sound emitter to a path, select the sound emitter entity, go to the **Scripts** tab, click **Add New Script**, and add the **path_converger** script. This enables the entity to follow the defined path. +Чтобы прикрепить звуковой излучатель к пути, выберите сущность звукового излучателя, перейдите на вкладку **Scripts**, нажмите **Add New Script** и добавьте скрипт **path_converger**. Это позволяет сущности следовать по заданному пути. -The **path_converger** script exposes a few options: +Скрипт **path_converger** предоставляет несколько опций: -| Property | Description | +| Свойство | Описание | |---|---| -| **Path Name** | The name of the path the emitter should follow. Must exactly match the path you created | -| **Rotate To Camera** | If enabled, the emitter rotates to face the listener's camera as it moves along the path | -| **Apply Scale** | Determines whether the emitter inherits scaling transformations from the path | +| **Path Name** | Имя пути, по которому должен следовать излучатель. Должно точно совпадать с именем созданного вами пути | +| **Rotate To Camera** | Если включено, излучатель поворачивается лицом к камере слушателя по мере движения по пути | +| **Apply Scale** | Определяет, наследует ли излучатель трансформации масштабирования от пути | --- -## Modifying Emitter Transforms +## Изменение трансформаций излучателя -To see a sound emitter's trigger volume shape and its min/max distance spheres, you need to enable **Sound Entities** visibility. If the **Visibility** tab isn't visible, open it via **Window > Visibility Window**. +Чтобы увидеть форму триггерного объёма звукового излучателя и его сферы минимального/максимального расстояния, вам нужно включить видимость **Sound Entities**. Если вкладка **Visibility** не отображается, откройте её через **Window > Visibility Window**. -In the **Visibility** tab, go to **Visibility Masks** and check the box next to **Sound Entities**. This enables display of sound-related components in the scene view. Once enabled, the trigger volume (a box or sphere wireframe) and two concentric distance spheres representing the min and max audible range become visible directly in the scene, making it much easier to position and resize emitters accurately. +На вкладке **Visibility** перейдите в **Visibility Masks** и отметьте флажок рядом с **Sound Entities**. Это включает отображение компонентов, связанных со звуком, в виде сцены. После включения триггерный объём (каркас куба или сферы) и две концентрические сферы расстояния, представляющие минимальный и максимальный диапазон слышимости, становятся видимыми прямо в сцене, что значительно облегчает точное позиционирование и изменение размера излучателей. --- -## Adding Sound Events to Animation Clips +## Добавление звуковых событий в клипы анимации -To attach sounds to animation clips, open the **Resource Browser** via **Window > Show Resource Browser**. The Resource Browser lets you browse, filter, and search through project assets. +Чтобы прикрепить звуки к клипам анимации, откройте **браузер ресурсов** (Resource Browser) через **Window > Show Resource Browser**. Браузер ресурсов позволяет просматривать, фильтровать и искать ресурсы проекта. -You can filter by asset class to narrow down results. If you're not sure where an asset is, use the search bar — just make sure you're searching within the correct directory. Once you find the animation clip, select it to open the **Animation Clip Inspector**. +Вы можете фильтровать по классу ресурса, чтобы сузить результаты. Если вы не уверены, где находится ресурс, используйте строку поиска — просто убедитесь, что вы ищете в правильной директории. Найдя клип анимации, выберите его, чтобы открыть **инспектор клипа анимации** (Animation Clip Inspector). -In the **Animation Clip Inspector**, you can view and adjust all parameters linked to the selected clip. For audio, focus on the sound-related parameters: +В **инспекторе клипа анимации** вы можете просматривать и настраивать все параметры, связанные с выбранным клипом. Для аудио сосредоточьтесь на параметрах, связанных со звуком: -| Property | Description | +| Свойство | Описание | |---|---| -| **Step Points** | The X-axis value defines the timing offset within the clip. Set to `−1.00` by default if no sound is attached. Set to `0.00` or adjust to sync sound with animation | -| **Sound Code** | The FMOD event path to attach. Entering a valid path ensures the sound plays at the correct point in the animation timeline | -| **Voice Code** | Combat voice type to attach to the animation. See built-in types below, or add custom types as described in the [Voice System]({{< ref "audio-modding-systems.md#voice-system" >}}) section | +| **Step Points** | Значение по оси X определяет временное смещение в рамках клипа. По умолчанию установлено значение `−1.00`, если звук не прикреплён. Установите `0.00` или скорректируйте значение для синхронизации звука с анимацией | +| **Sound Code** | Путь к событию FMOD для прикрепления. Ввод корректного пути обеспечивает проигрывание звука в нужной точке временной шкалы анимации | +| **Voice Code** | Тип боевого голоса, прикрепляемый к анимации. См. встроенные типы ниже, или добавьте пользовательские типы, как описано в разделе [Voice System]({{< ref "audio-modding-systems.md#voice-system" >}}) | -**Built-in Voice Codes:** +**Встроенные коды голоса:** | Voice Code | |---| @@ -126,66 +127,66 @@ In the **Animation Clip Inspector**, you can view and adjust all parameters link | HorseRally | | Drown | -**Animation sound flags:** +**Флаги звука анимации:** -| Flag | Description | +| Флаг | Описание | |---|---| -| `make_bodyfall_sound` | Triggers a body-fall sound at this animation point | -| `make_walk_sound` | Triggers a footstep sound at this animation point | -| `do_not_keep_track_of_sound` | Stops the engine from tracking the sound's playback state | -| `attach_sound_to_agent` | Attaches the sound directly to the agent rather than the world position | +| `make_bodyfall_sound` | Запускает звук падения тела в этой точке анимации | +| `make_walk_sound` | Запускает звук шага в этой точке анимации | +| `do_not_keep_track_of_sound` | Останавливает отслеживание движком состояния воспроизведения звука | +| `attach_sound_to_agent` | Прикрепляет звук напрямую к агенту, а не к позиции в мире | --- -## Adding Sound Events to Particles +## Добавление звуковых событий в частицы -Just like animation clips, particle assets can be accessed through the **Resource Browser**. Filter the asset list to show only particles, or use the search bar to locate a specific particle within a directory. Once found, double-click it to open the **Inspector Window**. +Как и клипы анимации, ресурсы частиц доступны через **браузер ресурсов**. Отфильтруйте список ресурсов, чтобы показать только частицы, или используйте строку поиска, чтобы найти конкретную частицу в директории. Найдя нужную, дважды щёлкните по ней, чтобы открыть **окно инспектора**. -In the Inspector, you can view the particle's layers, LODs, and parameters. Before attaching audio, make sure you've selected the correct **layer** and **LOD** of the particle. +В инспекторе вы можете просматривать слои, LOD-уровни и параметры частицы. Перед прикреплением аудио убедитесь, что вы выбрали правильный **слой** (layer) и **LOD** частицы. -> Keep in mind: if the effect isn't visually strong enough to justify rendering at a higher LOD, it isn't strong enough to justify a sound either. In those cases, keep audio only at **LOD 0**. +> Имейте в виду: если эффект недостаточно силён визуально, чтобы оправдать рендеринг на более высоком LOD, он недостаточно силён и для звука. В таких случаях оставляйте аудио только на **LOD 0**. -Once the correct layer and LOD are selected, open the **Sound** tab: +После выбора правильного слоя и LOD откройте вкладку **Sound**: -| Property | Description | +| Свойство | Описание | |---|---| -| **Continuous sound** | Use for looping sounds. Enter the FMOD event path of the looped event | -| **One shot sound** | Use for single-playback sounds. Enter the FMOD event path of the one-shot event | -| **Size Parameter** | Applies a multiplier to override the size of a 3D sound event | +| **Continuous sound** | Используется для зацикленных звуков. Введите путь к событию FMOD зацикленного события | +| **One shot sound** | Используется для одноразового воспроизведения звуков. Введите путь к событию FMOD одноразового события | +| **Size Parameter** | Применяет множитель для переопределения размера 3D звукового события | --- -## Quadraphonic Ambients {#quadraphonic-ambients} +## Квадрафонические амбиенты {#quadraphonic-ambients} -**Mount & Blade II: Bannerlord** is a performance-critical title. Adding hundreds of 3D sound emitters into scenes can quickly overwhelm CPU, memory, and disk I/O — especially during large-scale battles with thousands of active agents. To maintain immersion without sacrificing performance, we use **quadraphonic ambients**. +**Mount & Blade II: Bannerlord** — требовательная к производительности игра. Добавление сотен 3D звуковых излучателей в сцены может быстро перегрузить CPU, память и дисковый ввод/вывод — особенно во время масштабных сражений с тысячами активных агентов. Чтобы сохранить погружение без ущерба для производительности, мы используем **квадрафонические амбиенты**. -Quadraphonic is a four-channel surround format that creates the illusion of being surrounded by many emitters while actually using only four channels. Rather than relying on FMOD's built-in quad system, we implemented our own approach. It's a bit more involved to set up, but once you understand it, it's more flexible than FMOD's internal solution. +Квадрафония — это формат четырёхканального окружающего звука, который создаёт иллюзию окружения множеством излучателей, фактически используя лишь четыре канала. Вместо того чтобы полагаться на встроенную квадросистему FMOD, мы реализовали собственный подход. Он немного сложнее в настройке, но после того, как вы его поймёте, он более гибкий, чем внутреннее решение FMOD. -The system spawns **four 3D emitters** around the listener at fixed positions: **0°, 90°, 180°, and 270°** relative to the listener's facing direction. These emitters move with the listener's position, but their distance to the listener stays constant. As the listener turns, they continuously receive different signals from the surrounding emitters — creating the illusion of a dynamic, shifting environment without needing dozens of independent sources. +Система порождает **четыре 3D излучателя** вокруг слушателя в фиксированных позициях: **0°, 90°, 180° и 270°** относительно направления, в котором смотрит слушатель. Эти излучатели двигаются вместе с позицией слушателя, но расстояние до слушателя остаётся постоянным. По мере того как слушатель поворачивается, он непрерывно получает различные сигналы от окружающих излучателей — создавая иллюзию динамичной, меняющейся окружающей среды без необходимости в десятках независимых источников. -### Setting Up Quad Ambients +### Настройка квадро-амбиентов -First, create a **stereo ambient event**. This is **not optional** — it acts as a fallback in case the quad setup fails or isn't found. Without it, ambience may be missing during gameplay. +Сначала создайте **стерео-событие амбиента** (stereo ambient event). Это **не опционально** — оно служит запасным вариантом на случай, если настройка квадро не удалась или не найдена. Без него амбиент может отсутствовать во время игры. -For example, create a 2D event called `plains`. +Например, создайте 2D-событие с именем `plains`. -Next, create a **folder with the same name** as the stereo event (`plains` in this example). This naming is critical — the system matches stereo events to their quad alternatives by name. Events inside this folder will be treated as the quad channels. +Далее создайте **папку с таким же именем**, что и стерео-событие (`plains` в этом примере). Это именование критически важно — система сопоставляет стерео-события с их квадро-альтернативами по имени. События внутри этой папки будут рассматриваться как квадро-каналы. -Inside the folder, create four 3D events named exactly: +Внутри папки создайте четыре 3D-события с точными именами: - `north` - `east` - `south` - `west` -> The names are **case-sensitive** and must be **lowercase**. Event order doesn't matter. +> Имена **чувствительны к регистру** и должны быть **строчными**. Порядок событий не имеет значения. -For each of the four quad events, open the **Spatializer** and **disable distance attenuation**. These emitters should radiate a consistent signal regardless of their distance from the listener. If attenuation is left on, volumes may be incorrectly reduced depending on distance settings. +Для каждого из четырёх квадро-событий откройте **Spatializer** и **отключите затухание по расстоянию** (distance attenuation). Эти излучатели должны излучать постоянный сигнал независимо от расстояния до слушателя. Если затухание оставлено включённым, громкость может быть неправильно уменьшена в зависимости от настроек расстояния. -Finally, go back to the stereo event (`plains`) and set a **User Property**: +Наконец, вернитесь к стерео-событию (`plains`) и установите **пользовательское свойство** (User Property): -| Property | Value | +| Свойство | Значение | |---|---| | `isQuad` | `True` | -This flag tells the system to look for a matching quad setup. If found, the quad version plays; if not, the stereo event plays as a fallback. +Этот флаг указывает системе искать соответствующую квадро-настройку. Если она найдена, проигрывается квадро-версия; если нет, в качестве запасного варианта проигрывается стерео-событие. diff --git a/docs/content/russian/Audio Modding/audio-modding-systems.md b/docs/content/russian/Audio Modding/audio-modding-systems.md index 55dce04e..303d0a36 100644 --- a/docs/content/russian/Audio Modding/audio-modding-systems.md +++ b/docs/content/russian/Audio Modding/audio-modding-systems.md @@ -1,24 +1,25 @@ +++ -title = "Audio Systems & Optimization" +title = "Аудиосистемы и оптимизация" weight = 40 +ai_translated = true +++ -_Last updated: April 3, 2026_ +_Последнее обновление: 3 апреля 2026 г._ --- -## Voice System {#voice-system} +## Система голосов {#voice-system} -Non-dialogue vocalizations for humans, mounts, and animals (grunts, pain sounds, commands, etc.) are not hardcoded into game logic. Instead, they're managed through an external configuration file called `voice_definitions.xml`. This makes it straightforward to add or adjust voices without touching code. All declarations and definitions are written in XML and link directly to FMOD event paths. +Недиалоговые вокализации людей, лошадей и животных (хрюканье, звуки боли, команды и т. д.) не прописаны жёстко в игровой логике. Вместо этого они управляются через внешний конфигурационный файл `voice_definitions.xml`. Это позволяет легко добавлять или изменять голоса без изменения кода. Все объявления и определения записываются в XML и напрямую связываются с путями событий FMOD. -**File path:** +**Путь к файлу:** ``` ..\Modules\Native\ModuleData\voice_definitions.xml ``` -### Voice Type Declarations +### Объявления типов голосов -Before a voice can be used, it must be declared under the `` section. This registers the voice type so it can be referenced later. +Прежде чем голос можно будет использовать, его необходимо объявить в разделе ``. Это регистрирует тип голоса, чтобы на него можно было ссылаться позднее. ```xml @@ -26,11 +27,11 @@ Before a voice can be used, it must be declared under the ` ``` -Here, the voice type `Grunt` is declared and can now be used in one or more definitions. +Здесь объявляется тип голоса `Grunt`, который теперь можно использовать в одном или нескольких определениях. -### Voice Definitions +### Определения голосов -Once a type is declared, a **voice definition** links it to an FMOD event path and defines metadata such as pitch variation and usage restrictions. +После объявления типа, **определение голоса** связывает его с путём события FMOD и задаёт метаданные, такие как разброс высоты тона и ограничения использования. ```xml ``` -### Definition Attributes +### Атрибуты определения -| Attribute | Description | +| Атрибут | Описание | |---|---| -| `name` | Unique identifier for the voice definition | -| `sound_and_collision_info_class` | Class of entity this voice belongs to (e.g. `human`, `horse`) | -| `only_for_npcs` | If `true`, this voice cannot be assigned to the player | -| `min_pitch_multiplier` / `max_pitch_multiplier` | Defines the pitch variation range | +| `name` | Уникальный идентификатор определения голоса | +| `sound_and_collision_info_class` | Класс сущности, которой принадлежит этот голос (например, `human`, `horse`) | +| `only_for_npcs` | Если `true`, этот голос нельзя назначить игроку | +| `min_pitch_multiplier` / `max_pitch_multiplier` | Задаёт диапазон изменения высоты тона | -### Voice Node Details +### Подробности узла voice -Inside a ``, one or more `` entries can be added: +Внутри `` можно добавить один или несколько элементов ``: -| Attribute | Description | +| Атрибут | Описание | |---|---| -| `type` | Must match a declared `` | -| `path` | FMOD event path triggered for this voice | -| `face_anim` | Facial animation tag associated with this voice (e.g. `grunt`) | +| `type` | Должен соответствовать объявленному `` | +| `path` | Путь события FMOD, срабатывающий для этого голоса | +| `face_anim` | Тег лицевой анимации, связанный с этим голосом (например, `grunt`) | -### Workflow Summary +### Краткое описание процесса -1. Add a new `` under `` -2. Create a `` with a name, class, restrictions, and pitch range -3. Add one or more `` elements linking the definition to FMOD event paths -4. Assign `face_anim` for animation syncing +1. Добавьте новый `` в раздел `` +2. Создайте `` с именем, классом, ограничениями и диапазоном высоты тона +3. Добавьте один или несколько элементов ``, связывающих определение с путями событий FMOD +4. Назначьте `face_anim` для синхронизации анимации --- -## Physics Materials +## Физические материалы -The physics system manages all material-to-material interactions in the game and determines which sound events are triggered when collisions occur. Instead of handling each case independently, all physical interactions — wood striking metal, stone colliding with a projectile, metal on metal — are processed in a single unified system. This keeps logic consistent, reduces duplication, and makes it easier to maintain and expand audio coverage as the game grows. +Физическая система управляет всеми взаимодействиями материалов друг с другом в игре и определяет, какие звуковые события срабатывают при столкновениях. Вместо того чтобы обрабатывать каждый случай отдельно, все физические взаимодействия — удар дерева о металл, столкновение камня со снарядом, металл о металл — обрабатываются единой унифицированной системой. Это сохраняет согласованность логики, уменьшает дублирование и облегчает поддержку и расширение аудиопокрытия по мере роста игры. -### Material Interaction Handling +### Обработка взаимодействия материалов -Each material type is defined in the physics system along with its interaction rules when colliding with other materials. For example: +Каждый тип материала определяется в физической системе вместе с правилами его взаимодействия при столкновении с другими материалами. Например: -| Interaction | Result | +| Взаимодействие | Результат | |---|---| -| Wood vs. Metal | A metallic clash with resonant overtones | -| Stone vs. Missile | A sharp, brittle impact sound | -| Wood vs. Stone | A dull, muted collision | +| Дерево против металла | Металлический лязг с резонирующими обертонами | +| Камень против снаряда | Резкий, хрупкий звук удара | +| Дерево против камня | Глухое, приглушённое столкновение | -When two materials collide, the system evaluates their properties and selects the correct FMOD event to play. This removes the need to hard-code every possible pairwise interaction and ensures audio scales automatically as new materials are introduced. +Когда два материала сталкиваются, система оценивает их свойства и выбирает подходящее событие FMOD для воспроизведения. Это устраняет необходимость жёстко прописывать каждое возможное парное взаимодействие и гарантирует автоматическое масштабирование аудио при появлении новых материалов. -### Special Case: Water Interactions +### Особый случай: взаимодействие с водой -Water requires unique treatment compared to solid materials. Unlike other pairings, "object + water" doesn't need a dedicated event for every possible object type. Regardless of what enters the water, the player primarily perceives it as a water sound — not as "body hitting water" or "stone hitting water." +Вода требует особого подхода по сравнению с твёрдыми материалами. В отличие от других пар, сочетание «объект + вода» не требует отдельного события для каждого возможного типа объекта. Независимо от того, что попадает в воду, игрок в первую очередь воспринимает это как звук воды, а не как «тело, ударившееся о воду» или «камень, ударившийся о воду». -To simplify implementation, the system uses a **single generic water event** parameterized by the physical properties of the object entering the water: +Чтобы упростить реализацию, система использует **одно общее событие воды**, параметризованное физическими свойствами объекта, входящего в воду: -| Parameter | Description | +| Параметр | Описание | |---|---| -| **Volume** | Determines how large the displaced splash should sound | -| **Mass** | Scales the weight and depth of the impact | -| **Force** (velocity/acceleration) | Controls the intensity and sharpness of the splash | +| **Объём** | Определяет, насколько большим должен звучать вытесненный всплеск | +| **Масса** | Масштабирует вес и глубину удара | +| **Сила** (скорость/ускорение) | Контролирует интенсивность и резкость всплеска | -By combining these variables, the system can produce a wide range of splash sounds from the same event — from a small pebble skipping across the surface to a heavy boulder crashing into deep water. +Комбинируя эти переменные, система может создавать широкий диапазон звуков всплеска из одного и того же события — от маленького камешка, скачущего по поверхности, до тяжёлого валуна, врезающегося в глубокую воду. -**Benefits of this approach:** +**Преимущества такого подхода:** -- **Unified logic** — All material interactions are handled consistently in one system -- **Scalability** — Adding new materials only requires defining their properties, not rewriting interaction logic -- **Efficiency** — Parameter-driven variations replace dozens of unique event definitions -- **Water optimization** — One generic event covers all possible water interactions, driven dynamically by physics parameters -- **Realism** — Splash sounds scale naturally with object size, weight, and velocity +- **Единая логика** — все взаимодействия материалов обрабатываются согласованно в одной системе +- **Масштабируемость** — добавление новых материалов требует только определения их свойств, а не переписывания логики взаимодействия +- **Эффективность** — вариации, управляемые параметрами, заменяют десятки уникальных определений событий +- **Оптимизация воды** — одно общее событие покрывает все возможные взаимодействия с водой, динамически управляемое физическими параметрами +- **Реализм** — звуки всплеска естественно масштабируются в зависимости от размера, веса и скорости объекта --- -## Priority System {#priority-system} +## Система приоритетов {#priority-system} -This system runs **before** FMOD's built-in priority system, acting as a pre-filter to reduce the CPU cost of evaluating large numbers of events. It applies its own rules to decide which sounds are eligible, and only those are passed on to FMOD for playback. FMOD's internal priority system still applies once events are submitted, so you can continue using it to refine prioritization among active events. +Эта система работает **перед** встроенной системой приоритетов FMOD, выступая в роли предварительного фильтра для снижения нагрузки на процессор при оценке большого количества событий. Она применяет собственные правила, чтобы решить, какие звуки допустимы, и только они передаются в FMOD для воспроизведения. Внутренняя система приоритетов FMOD по-прежнему применяется после отправки событий, так что вы можете продолжать использовать её для уточнения приоритизации среди активных событий. -### Core Mechanism +### Основной механизм -The system maintains an array whose maximum size corresponds to the maximum number of events it's allowed to manage at once. Each candidate event is evaluated against a priority scheme based on: +Система поддерживает массив, максимальный размер которого соответствует максимальному количеству событий, которыми ей разрешено управлять одновременно. Каждое событие-кандидат оценивается по схеме приоритетов, основанной на: -| Parameter | Description | +| Параметр | Описание | |---|---| -| **Length** | Duration of the event — used to determine whether short transient sounds or long events should be favored | -| **Distance** | Spatial distance between emitter and listener. If this exceeds the event's defined max distance in FMOD, the sound is culled immediately and never passed to FMOD | -| **PriorityMultiplier** | A user-defined multiplier that adjusts the relative importance of an event compared to others | +| **Длина** | Продолжительность события — используется для определения того, следует ли отдавать предпочтение коротким переходным звукам или длинным событиям | +| **Расстояние** | Пространственное расстояние между источником и слушателем. Если оно превышает заданное в FMOD максимальное расстояние события, звук немедленно отсеивается и никогда не передаётся в FMOD | +| **PriorityMultiplier** | Заданный пользователем множитель, который корректирует относительную важность события по сравнению с другими | -These parameters are stored in the **SEDF (Sound Event Data File)** for every event, ensuring consistent evaluation. +Эти параметры хранятся в **SEDF (Sound Event Data File)** для каждого события, обеспечивая согласованную оценку. -### Distance Filtering +### Фильтрация по расстоянию -Events that fall outside their maximum audible distance are killed before FMOD ever processes them. This prevents FMOD from spending resources evaluating voices that can't be heard. +События, выходящие за пределы максимального слышимого расстояния, отбраковываются ещё до того, как FMOD вообще их обработает. Это предотвращает трату ресурсов FMOD на оценку голосов, которые невозможно услышать. -### Exceptions and Looping Events +### Исключения и зацикленные события -Looping sounds need special handling: +Зацикленные звуки требуют особой обработки: -- **Ambient sounds** are excluded from this system entirely and marked as persistent within FMOD — they are never culled by pre-priority logic. -- **Looped sounds** present a problem: if they're killed and restarted, they can't resume from their previous play position, causing synchronization issues. +- **Фоновые звуки (ambient)** полностью исключены из этой системы и помечены как постоянные в FMOD — они никогда не отсеиваются логикой предварительного приоритета. +- **Зацикленные звуки** создают проблему: если их остановить и запустить заново, они не могут возобновиться с предыдущей позиции воспроизведения, что вызывает проблемы синхронизации. -To handle this, looped sounds can be **virtualized** instead of killed. Virtualization lets the event stop consuming CPU while still tracking its playback position, so when it returns to audible range it continues seamlessly from where it left off. +Чтобы решить эту проблему, зацикленные звуки могут быть **виртуализованы** вместо остановки. Виртуализация позволяет событию прекратить потребление ресурсов процессора, продолжая при этом отслеживать позицию воспроизведения, так что при возвращении в слышимый диапазон оно продолжает воспроизведение без прерывания с того места, где остановилось. -### User Property Overrides +### Переопределения через пользовательские свойства -User Properties provide additional flexibility (see [User Properties]({{< ref "audio-modding-event-setup.md#user-properties" >}})): +Пользовательские свойства (User Properties) обеспечивают дополнительную гибкость (см. [Пользовательские свойства]({{< ref "audio-modding-event-setup.md#user-properties" >}})): -- **Ignore flags** — Distance or length checks can be bypassed for specific events if tagged accordingly -- **Custom multipliers** — A multiplier can be defined per event through User Properties, modifying its relative priority when compared with others +- **Флаги игнорирования** — проверки расстояния или длины можно обойти для определённых событий, если они соответствующим образом помечены +- **Пользовательские множители** — множитель можно задать для каждого события через пользовательские свойства, изменяя его относительный приоритет по сравнению с другими -**Benefits:** +**Преимущества:** -- **CPU efficiency** — Reduces FMOD's workload by culling inaudible or unnecessary sounds before they reach the engine -- **Flexible prioritization** — Length, distance, and multipliers allow fine-tuned control over event importance -- **Synchronization safety** — Virtualization ensures looped events remain consistent when reactivated -- **Designer control** — User Properties enable exceptions and weighting without code changes +- **Эффективность процессора** — снижает нагрузку на FMOD за счёт отсеивания неслышимых или ненужных звуков до того, как они достигнут движка +- **Гибкая приоритизация** — длина, расстояние и множители позволяют точно настраивать важность события +- **Безопасность синхронизации** — виртуализация обеспечивает согласованность зацикленных событий при их повторной активации +- **Контроль со стороны дизайнера** — пользовательские свойства позволяют задавать исключения и весовые коэффициенты без изменения кода --- -## Battle Ambient Sound System {#battle-ambient-sound-system} +## Система фонового звука боя {#battle-ambient-sound-system} -The Battle Ambient Sound System — abbreviated as **BASS** — is designed to optimize the playback of high-density sound effects, such as multiple sword clashes occurring in the same area. Instead of letting each individual sound play independently (which can quickly overwhelm both the mix and the CPU), BASS aggregates these events and replaces them with a single emitter that represents the group. +Система фонового звука боя — сокращённо **BASS** (Battle Ambient Sound System) — предназначена для оптимизации воспроизведения звуковых эффектов высокой плотности, таких как множественные удары мечей, происходящие в одной и той же области. Вместо того чтобы позволить каждому отдельному звуку воспроизводиться независимо (что может быстро перегрузить и микс, и процессор), BASS агрегирует эти события и заменяет их единым излучателем, представляющим всю группу. -### How It Works +### Как это работает -Within a defined region, BASS monitors the number of sound events triggered over a given period. When the count exceeds a specified threshold, the system suppresses the individual sounds in that region and spawns a single **group emitter event** in their place. +В пределах заданной области BASS отслеживает количество звуковых событий, вызванных за определённый период. Когда количество превышает заданный порог, система подавляет отдельные звуки в этой области и порождает вместо них единое событие **группового излучателя**. -This emitter event includes a parameter reflecting the density of sounds in the area. As the parameter increases, the mix shifts from sparse individual clashes to dense, chaotic battle noise. Players still perceive an intense soundscape, but without the overhead of dozens of overlapping one-shots. +Это событие-излучатель включает параметр, отражающий плотность звуков в области. По мере увеличения этого параметра микс смещается от редких отдельных ударов к плотному, хаотичному шуму боя. Игроки по-прежнему воспринимают насыщенный звуковой ландшафт, но без накладных расходов на десятки перекрывающихся одноразовых звуков. -### Interaction with the Priority System +### Взаимодействие с системой приоритетов -BASS operates **before** our proprietary engine's priority system. Normally, the priority system decides which sounds to cull when many voices compete for playback. In this workflow, BASS preemptively reduces polyphony at the source level — only the grouped emitter remains active, meaning the priority system has fewer voices to manage. This prevents unnecessary CPU/DSP usage and ensures consistent sound quality during crowded combat. +BASS работает **до** системы приоритетов нашего собственного движка. Обычно система приоритетов решает, какие звуки отсеивать, когда за воспроизведение конкурирует множество голосов. В этом рабочем процессе BASS заранее снижает полифонию на уровне источника — активным остаётся только сгруппированный излучатель, а значит, системе приоритетов приходится управлять меньшим количеством голосов. Это предотвращает излишнее использование ЦП/DSP и обеспечивает стабильное качество звука во время массовых боёв. -### BASS Group IDs +### Идентификаторы групп BASS -Use the `battle_ambient_group_id` user property (see [User Properties]({{< ref "audio-modding-event-setup.md#user-properties" >}})) to assign an event to a BASS group. +Используйте пользовательское свойство `battle_ambient_group_id` (см. [Пользовательские свойства]({{< ref "audio-modding-event-setup.md#user-properties" >}})), чтобы назначить событие группе BASS. -| ID | Group | +| ID | Группа | |---|---| -| 0 | Infantry move | -| 1 | Cavalry move | -| 2 | Weapons fight | -| 3 | Shield fight | -| 4 | Missile volley | -| 5 | Human fight | -| 6 | Human victory | -| 7 | Horse vocal | +| 0 | Движение пехоты | +| 1 | Движение кавалерии | +| 2 | Бой оружием | +| 3 | Бой щитами | +| 4 | Залп снарядов | +| 5 | Человеческий бой | +| 6 | Победа человека | +| 7 | Вокализация лошади | -**Examples:** -- Adding a new weapon event → set `battle_ambient_group_id` to **2** -- Adding a footstep event for a new mount type → set `battle_ambient_group_id` to **1** +**Примеры:** +- Добавление нового события оружия → установите `battle_ambient_group_id` равным **2** +- Добавление события шага для нового типа верхового животного → установите `battle_ambient_group_id` равным **1** -By assigning the correct group ID, BASS fires one unified event per group instead of hundreds of individual ones, significantly reducing active event count and saving system resources. +Назначая правильный идентификатор группы, BASS запускает одно унифицированное событие на группу вместо сотен отдельных, значительно снижая количество активных событий и экономя системные ресурсы. -**Benefits:** +**Преимущества:** -- **Performance optimization** — Prevents CPU and memory spikes from excessive overlapping sounds -- **Mix clarity** — Replaces cluttered layers of transients with a single controlled emitter -- **Scalability** — Parameter-driven event design adapts automatically to combat density +- **Оптимизация производительности** — предотвращает всплески нагрузки на ЦП и память из-за чрезмерного количества перекрывающихся звуков +- **Чистота микса** — заменяет загромождённые слои переходных звуков единым управляемым излучателем +- **Масштабируемость** — дизайн событий, управляемый параметрами, автоматически адаптируется к плотности боя --- -## Performance and Optimization +## Производительность и оптимизация -In a CPU- and memory-intensive title like **Mount & Blade II: Bannerlord**, FMOD must be treated as part of the overall performance budget. Poorly managed audio banks, codecs, or event design can consume resources the game engine needs for everything else. Optimization is not a one-off task — it's an ongoing discipline throughout the entire modding process. +В такой требовательной к ЦП и памяти игре, как **Mount & Blade II: Bannerlord**, FMOD должен рассматриваться как часть общего бюджета производительности. Плохо управляемые звуковые банки, кодеки или дизайн событий могут потреблять ресурсы, необходимые игровому движку для всего остального. Оптимизация — это не разовая задача, а постоянная дисциплина на протяжении всего процесса моддинга. -### Codec and Asset Strategy +### Стратегия кодеков и ассетов -Every decoded sample costs CPU, every oversized file costs memory and disk I/O, and every resample costs even more CPU. Codec strategy must be set deliberately, not left to chance. +Каждый декодированный сэмпл стоит процессорного времени, каждый слишком большой файл стоит памяти и операций ввода-вывода диска, а каждый ресэмплинг стоит ещё больше процессорного времени. Стратегию кодеков нужно задавать осознанно, а не оставлять на волю случая. -FMOD lets you set a default codec for the entire audio build in the bank build settings (ensuring consistency across the project) and override codecs per asset when specific files demand different treatment. +FMOD позволяет задать кодек по умолчанию для всей аудиосборки в настройках сборки банков (обеспечивая согласованность по всему проекту) и переопределить кодеки для отдельных ассетов, когда конкретные файлы требуют иного подхода. -FMOD Studio's practical PC formats are: +Практичные для ПК форматы FMOD Studio: -| Codec | Characteristics | +| Кодек | Характеристики | |---|---| -| **Vorbis** | Best compression, but higher decode cost. Best overall choice when CPU is available | -| **ADPCM** | Larger than Vorbis but almost free to decode. Good fallback when Vorbis is too CPU-heavy | -| **PCM** | No compression, no decode cost. Can quickly bloat memory — avoid unless strictly necessary | +| **Vorbis** | Лучшее сжатие, но более высокая стоимость декодирования. Лучший общий выбор, когда доступен запас процессора | +| **ADPCM** | Больше, чем Vorbis, но декодирование почти бесплатно. Хороший запасной вариант, когда Vorbis слишком нагружает процессор | +| **PCM** | Без сжатия, без затрат на декодирование. Может быстро раздуть объём памяти — избегайте, если это не строго необходимо | -#### Load Types +#### Типы загрузки -Each asset has a **Load Type** setting that determines how it lives in memory: +Каждый ассет имеет настройку **Load Type** (тип загрузки), которая определяет, как он хранится в памяти: -| Load Type | Description | +| Тип загрузки | Описание | |---|---| -| **Compressed** | Loaded in compressed form and decompressed at playback. Less memory, slightly more CPU at play time | -| **Decompressed** | Decompressed into PCM when banks load, not at playback. Not recommended unless you have a specific need (e.g. very low-spec devices) | -| **Streaming** | Loaded in chunks from disk as needed. Good for long music and ambiences that aren't time-sensitive | +| **Compressed** (сжатый) | Загружается в сжатом виде и распаковывается при воспроизведении. Меньше памяти, немного больше нагрузки на ЦП во время воспроизведения | +| **Decompressed** (распакованный) | Распаковывается в PCM при загрузке банков, а не при воспроизведении. Не рекомендуется, если у вас нет конкретной необходимости (например, устройства с очень низкими характеристиками) | +| **Streaming** (потоковый) | Загружается частями с диска по мере необходимости. Хорошо подходит для длинной музыки и фоновых звуков, не критичных по времени | -### Streaming and Bank Management +### Потоковая передача и управление банками -On PC, long assets like music or ambiences can balloon RAM usage if kept fully in memory. Streaming solves this by pulling audio in chunks from disk, but every stream adds CPU overhead and disk I/O pressure. Stream too many files at once and you risk stutters and thread contention, especially on HDDs or low-end systems. **Stream only what needs it.** +На ПК длинные ассеты, такие как музыка или фоновые звуки, могут значительно увеличить использование оперативной памяти, если хранятся полностью в памяти. Потоковая передача решает эту проблему, подгружая аудио частями с диска, но каждый поток добавляет нагрузку на ЦП и дисковый ввод-вывод. Если одновременно воспроизводить слишком много потоковых файлов, возникает риск заиканий и конкуренции потоков, особенно на жёстких дисках (HDD) или слабых системах. **Используйте потоковую передачу только там, где это действительно необходимо.** -Banks are containers for events, assets, and metadata — they determine what FMOD loads into RAM at runtime. Poorly structured banks leave unnecessary assets in memory, extend load times, and create streaming bottlenecks. Each event should live in a single bank; the same event should never appear in multiple banks unless there's an unavoidable design requirement. +Банки — это контейнеры для событий, ассетов и метаданных — они определяют, что FMOD загружает в оперативную память во время выполнения. Плохо структурированные банки оставляют ненужные ассеты в памяти, увеличивают время загрузки и создают узкие места при потоковой передаче. Каждое событие должно находиться в одном банке; одно и то же событие никогда не должно присутствовать в нескольких банках, если только это не неизбежное требование дизайна. -### Event, DSP, and Channel Management +### Управление событиями, DSP и каналами -Every event generates one or more voices, each consuming CPU and memory. Stereo, quad, or 5.1 events multiply the number of channels being mixed. Combine this with DSP on each path and costs grow fast. If you don't actively manage instances, channels, and DSP chains, your mix can choke the CPU long before your assets fill memory. +Каждое событие создаёт один или несколько голосов, каждый из которых потребляет ЦП и память. Стерео-, квадро- или 5.1-события умножают количество каналов, участвующих в микшировании. Добавьте к этому DSP на каждом тракте, и затраты растут быстро. Если вы активно не управляете экземплярами, каналами и цепочками DSP, ваш микс может задушить процессор задолго до того, как ассеты заполнят память. -#### Controlling Event Instances and Channels +#### Контроль экземпляров событий и каналов -Although we already handle this with our custom priority system, you can set max instance limits on heavily triggered events if needed. For each event, define a sensible polyphony cap and choose a **stealing rule**: +Хотя мы уже обрабатываем это с помощью нашей собственной системы приоритетов, при необходимости вы можете задать ограничения на максимальное количество экземпляров для часто вызываемых событий. Для каждого события определите разумный предел полифонии и выберите **правило вытеснения**: -| Rule | Behavior | +| Правило | Поведение | |---|---| -| **Oldest** | Cuts off the instance that has been playing the longest | -| **Newest** | Blocks the most recently triggered instance from starting | -| **Quietest** | Stops the currently lowest-volume instance | -| **Virtualize** | Suspends an instance into a no-CPU "virtual" state while keeping its timeline active. Useful for VO and music | -| **None** | Prevents new instances from starting if the max is already reached | -| **Furthest** | Stops the instance furthest from the listener | +| **Oldest** (старейший) | Отключает экземпляр, который воспроизводится дольше всего | +| **Newest** (новейший) | Блокирует запуск самого недавно вызванного экземпляра | +| **Quietest** (тишайший) | Останавливает экземпляр с наименьшей текущей громкостью | +| **Virtualize** (виртуализировать) | Переводит экземпляр в состояние «виртуального» без затрат ЦП, сохраняя активной его временную шкалу. Полезно для озвучки (VO) и музыки | +| **None** (нет) | Предотвращает запуск новых экземпляров, если максимум уже достигнут | +| **Furthest** (самый дальний) | Останавливает экземпляр, наиболее удалённый от слушателя | -Keep channel counts realistic: +Держите количество каналов реалистичным: -- Use **mono** for any sound with no spatial width -- Use **stereo** only when width is essential (music, ambiences, UI) -- Save **quad or 5.1+** for true surround beds that justify the cost +- Используйте **моно** для любого звука без пространственной ширины +- Используйте **стерео** только тогда, когда ширина действительно важна (музыка, фоновые звуки, UI) +- Приберегите **квадро или 5.1+** для настоящих окружающих звуковых подложек, оправдывающих такие затраты -Every extra channel means extra mixing, panning, and potential DSP. Don't waste channels on one-shots that will collapse to mono in most contexts anyway. +Каждый дополнительный канал означает дополнительное микширование, панорамирование и потенциальную обработку DSP. Не тратьте каналы на одноразовые звуки, которые в большинстве контекстов всё равно сводятся к моно. -#### Managing DSP Load +#### Управление нагрузкой DSP -DSP processing is the heaviest part of runtime audio performance. Effects like convolution reverb, FFT filters, and multiband dynamics consume significant CPU — often more than their audible benefit justifies. Apply DSP only when it provides clear value, such as shaping the overall mix in a way that can't be pre-baked. For common one-shot events, keep them clean or embed processing directly into the audio file. +Обработка DSP — самая тяжёлая часть производительности аудио во время выполнения. Эффекты, такие как свёрточная реверберация (convolution reverb), FFT-фильтры и многополосная динамика, потребляют значительные ресурсы ЦП — часто больше, чем оправдывает их слышимая польза. Применяйте DSP только там, где это даёт очевидную ценность, например, при формировании общего микса таким образом, который нельзя предварительно «запечь» в файл. Для обычных одноразовых событий держите их чистыми или встраивайте обработку прямо в аудиофайл. -Channel count multiplies DSP cost: a stereo convolution reverb is twice the work of mono, and a quad instance multiplies it further. Use mono effects wherever possible. +Количество каналов умножает стоимость DSP: стерео свёрточная реверберация требует вдвое больше работы, чем моно, а квадро-экземпляр умножает её ещё сильнее. Используйте моно-эффекты, где это возможно. -### Bus and Routing +### Шины и маршрутизация -Bus hierarchies should stay functional and minimal. Group major categories under dedicated sub-buses only where it serves a clear purpose. Use sends and sidechains intentionally — every extra routing hop adds to channel mixing and DSP load. Consolidate DSP chains at the bus level instead of stacking them across many individual events. Snapshots can then modify the properties of a single DSP effect across multiple states, significantly cutting down on total DSP instances required. +Иерархии шин должны оставаться функциональными и минимальными. Группируйте основные категории под выделенными подшинами только там, где это служит ясной цели. Используйте сенды и сайдчейны осознанно — каждый дополнительный переход маршрутизации добавляет нагрузку на микширование каналов и DSP. Консолидируйте цепочки DSP на уровне шины вместо того, чтобы складывать их на множестве отдельных событий. Снапшоты (snapshots) затем могут изменять свойства одного эффекта DSP сразу в нескольких состояниях, значительно сокращая общее количество необходимых экземпляров DSP. -### Using Baked Effects +### Использование запечённых эффектов -If a sound always needs coloration (EQ, distortion, static reverb), bake it into the source file. Reserve runtime DSP for genuinely interactive processing: parameter-driven filters, ducking, pitch modulation, or environmental reverb zones that change dynamically. This prevents the slow creep of redundant DSP costs. +Если звуку всегда нужна окраска (эквализация, дисторшн, статичная реверберация), запеките её прямо в исходный файл. Оставьте DSP во время выполнения для действительно интерактивной обработки: фильтров, управляемых параметрами, дакинга, модуляции высоты тона или зон реверберации окружения, которые меняются динамически. Это предотвращает медленное накопление избыточных затрат на DSP. -### Importing Assets +### Импорт ассетов -Keep assets lean before they reach FMOD: +Держите ассеты компактными до того, как они попадут в FMOD: -- **Trim silence** from samples -- **Normalize loudness** to a consistent LUFS baseline -- **Match the project sample rate** (48 kHz) to avoid hidden resampling and wasted CPU cycles +- **Обрезайте тишину** из сэмплов +- **Нормализуйте громкость** до согласованной базовой линии LUFS +- **Соответствуйте частоте дискретизации проекта** (48 кГц), чтобы избежать скрытого ресэмплинга и потраченных впустую циклов процессора -While FMOD encodes assets into its own formats at build time, the **source format** you import still affects workflow. Using `.wav` for everything bloats the project since .wav files are uncompressed. Switching to **`.flac`** for source assets can drastically reduce disk footprint while preserving lossless quality — this doesn't affect the final encoded format (PCM, Vorbis, ADPCM, etc.), but makes asset management lighter and faster. +Хотя FMOD кодирует ассеты в собственные форматы на этапе сборки, **исходный формат**, который вы импортируете, всё равно влияет на рабочий процесс. Использование `.wav` для всего раздувает проект, поскольку файлы .wav не сжаты. Переход на **`.flac`** для исходных ассетов может значительно сократить объём занимаемого места на диске при сохранении качества без потерь — это не влияет на итоговый закодированный формат (PCM, Vorbis, ADPCM и т. д.), но делает управление ассетами более лёгким и быстрым. -### Testing for Edge Cases +### Тестирование граничных случаев -Always test edge conditions: thousands of agents in combat, long campaign sessions, or rapid scene transitions. These scenarios reveal memory leaks, mismanaged banks, or runaway event counts before they become real-world problems reported by players. +Всегда тестируйте предельные условия: тысячи агентов в бою, долгие сессии кампании или быстрые переходы между сценами. Эти сценарии выявляют утечки памяти, неправильное управление банками или неконтролируемый рост количества событий ещё до того, как они станут реальными проблемами, о которых сообщат игроки. diff --git a/docs/content/russian/Authoring Mission Scenes/Script Components/bannerlord_destructible_component.md b/docs/content/russian/Authoring Mission Scenes/Script Components/bannerlord_destructible_component.md index 6774497a..911e9a3b 100644 --- a/docs/content/russian/Authoring Mission Scenes/Script Components/bannerlord_destructible_component.md +++ b/docs/content/russian/Authoring Mission Scenes/Script Components/bannerlord_destructible_component.md @@ -1,5 +1,6 @@ +++ -title = "Destructible Component" +title = "Компонент разрушения (Destructible Component)" +ai_translated = true [menu.main] identifier = "bannerlord_destructible_component" @@ -7,97 +8,97 @@ parent = "bannerlord_scenes" +++ -The destruction system which gives artists a lot more freedom is explained below. +Ниже описана система разрушения, которая даёт художникам гораздо больше свободы. -## Characteristics +## Характеристики -It is a ScriptComponent which can be applied to any entity in a scene, as long as that entity has a collision body. +Это ScriptComponent, который можно применить к любому объекту на сцене, при условии что у этого объекта есть тело коллизии. -When not given any information, the script will just make the entity disappear after being destroyed. It will also re-appear when the mission resets. +Если не задать никакой информации, скрипт просто заставит объект исчезнуть после разрушения. Он также снова появится при сбросе миссии. -The script can be used to destroy entities in one or more states, with optional sound, particles and dynamic objects spawning in each state. +Этот скрипт можно использовать для разрушения объектов в одном или нескольких состояниях, с опциональным звуком, частицами и появлением динамических объектов на каждом этапе. -Any existing prefab that has a DestructibleComponent script (Siege towers, gates, ballistas, ..) will continue to work even when you remove that script. It will only no longer be destructible. +Любой существующий префаб со скриптом DestructibleComponent (осадные башни, ворота, баллисты и т. д.) продолжит работать, даже если вы удалите этот скрипт. Он просто перестанет быть разрушаемым. -One entity can have multiple DestructibleComponent scripts. E.g. the battering ram is destructible, but it also has individual rooftiles which can be destroyed too. Any damage that is applied to a child will also be applied to the parent(s). +У одного объекта может быть несколько скриптов DestructibleComponent. Например, таран разрушаем, но у него также есть отдельные черепичные плитки крыши, которые тоже можно разрушить. Любой урон, применённый к дочернему объекту, также будет применён к родителю (родителям). -Destroyed prefabs can always be tweaked and improved later without breaking any scenes, because they are not part of the intact entity (They are spawned at runtime). +Разрушенные префабы всегда можно доработать и улучшить позже, не нарушая работу каких-либо сцен, поскольку они не являются частью целого объекта (они создаются во время выполнения). -| Example Script of Siege Tower | +| Пример скрипта осадной башни | | ------ | |  | -| **DestructionStates**, can be one or more prefabs. Seperated by "," (comma). -| **DestroyedByStoneOnly**, True means that only projectiles from mangonels or trebuchets can damage this entity. False means anything can damage this entity. -| **CanBeDestroyedInititally**, defines if this entity can be destroyed already when loading the scene. This is controlled from the campaign map based on a destruction percentage from bombardements. This is generally only true on wall merlons. But it can also be used on aesthetic entities to make the scene look more destroyed from the start. Entities to be destroyed are selected randomly. -| **MaxHitPoint** are the starting hitpoints from this entity. Every time the mission resets, the entity will also have its current hitpoints set back to the MaxHitPoints. -| **ReferenceEntityTag** is an optional tag for when a DestructionState prefab has a different frame than its parent or to copy animation states. You can add an extra entity (under the entity with the DestructibleComponent script) with a correct frame and supply it with a reference tag, so that the spawned DestructionState prefab will use that frame. If there is no ReferenceEntity, the frame of the entity with the DestructibleComponent script will be used. Reference entity can also be used in special scenarios like a castlegate (opening/closing animations), to get the animation state from the reference entity and apply it to the newly spawned damaged entity. -| **OriginalStateTag** is only required when you have multiple DestructionStates. Usually, when an entity is destroyed, we hide the entity which has the script component applied, and spawn a new entity from the DestructionState (without a parent). But for some entities (like gates), we do not want to hide the entire entity because it has to keep functioning as a gate until it is fully destroyed. Using the OriginalStateTag, we will only hide the entity which has this tag applied, and the rest of the hierarchy (particles, standing points, ..) will still be visible. Any DestructibleComponent that has more than one destructionState will spawn the damaged prefabs as child entities. -| **HeavyHitParticlesTag** is a tag which can be applied to any child-entities that have a particle-system. These particles will burst once, when a certain amount of damage is taken in a single blow. This particle system is generally shared between all destruction states (It's not part of the entities that get hidden/spawned). -| **HeavyHitParticlesThreshold** is the minimum damage that is required to be taken in a single blow, to trigger particles with HeavyHitParticlesTag tag. - -## Effects - -Generally, we try to keep the spawned prefabs as small as possible for performance reasons, and also to avoid entity duplication. -You have access to the following functionality to add effects: - -- On the damaged prefab, when spawned: All particle systems on every entity in the hierarchy, will automatically be bursted once. -- On the damaged prefab, when spawned: All dynamic bodies on every entity in the hierarchy, will automatically receive the impulse from the last hit that destroyed the previous state. -- On the damaged prefab, when spawned: All other meshes on every entity in the hierarchy, will remain in place if they have no dynamic body-flag. -- Part of the entity hierarchy: Heavy hit particles have to be shared between all destruction states, and are played whenever the DestructibleComponent takes _HeavyHitParticlesThreshold_ damage. -- You can play custom animations on DestructibleComponents that have a skeleton (e.g. castlegate being hit by battering ram). The animation progress will transfer to the newly spawned damaged entities. -- You can add a script of type AmbientSoundEmitter on a damaged prefab and provide the sound event. It will automatically play when the entity is spawned. -- Apart from using multiple states, you can also add multiple child entities with DestructibleComponents (e.g. battering ram rooftiles which are individually destructible). Keep in mind that any damage that is applied to a child DestructibleComponent is also applied to every parent in the hierarchy. Currently, we don't know the performance implications of having too many of these. +| **DestructionStates** — может быть одним или несколькими префабами, разделёнными запятой (","). +| **DestroyedByStoneOnly** — True означает, что только снаряды мангонелей или требушетов могут нанести урон этому объекту. False означает, что урон может нанести что угодно. +| **CanBeDestroyedInititally** определяет, может ли этот объект быть уже разрушен при загрузке сцены. Это контролируется с карты кампании на основе процента разрушения от бомбардировок. Обычно это значение равно true только для зубцов стен (wall merlons). Но его также можно использовать для декоративных объектов, чтобы сцена выглядела более разрушенной с самого начала. Объекты для разрушения выбираются случайным образом. +| **MaxHitPoint** — это начальные очки прочности этого объекта. При каждом сбросе миссии текущие очки прочности объекта также будут сброшены до значения MaxHitPoints. +| **ReferenceEntityTag** — это опциональный тег для случаев, когда у префаба DestructionState другой кадр (frame), чем у его родителя, или для копирования состояний анимации. Вы можете добавить дополнительный объект (внутри объекта со скриптом DestructibleComponent) с правильным кадром и присвоить ему тег ссылки, чтобы созданный префаб DestructionState использовал этот кадр. Если ReferenceEntity отсутствует, будет использован кадр объекта со скриптом DestructibleComponent. Ссылочный объект также можно использовать в особых сценариях, например для ворот замка (анимации открытия/закрытия), чтобы получить состояние анимации от ссылочного объекта и применить его к новому заспавненному повреждённому объекту. +| **OriginalStateTag** требуется только тогда, когда у вас несколько DestructionStates. Обычно при разрушении объекта мы скрываем объект, к которому применён скрипт-компонент, и создаём новый объект из DestructionState (без родителя). Но для некоторых объектов (например, ворот) мы не хотим скрывать весь объект целиком, потому что он должен продолжать функционировать как ворота, пока не будет полностью разрушен. Используя OriginalStateTag, мы скроем только тот объект, к которому применён этот тег, а остальная часть иерархии (частицы, точки стояния и т. д.) останется видимой. Любой DestructibleComponent с более чем одним DestructionState будет создавать повреждённые префабы как дочерние объекты. +| **HeavyHitParticlesTag** — это тег, который можно применить к любым дочерним объектам, имеющим систему частиц. Эти частицы сработают один раз, когда за один удар получено определённое количество урона. Эта система частиц обычно является общей для всех состояний разрушения (она не является частью объектов, которые скрываются/создаются). +| **HeavyHitParticlesThreshold** — это минимальный урон, который должен быть получен за один удар, чтобы запустить частицы с тегом HeavyHitParticlesTag. + +## Эффекты + +Как правило, мы стараемся делать создаваемые префабы как можно меньше ради производительности, а также чтобы избежать дублирования объектов. +У вас есть доступ к следующим возможностям для добавления эффектов: + +- На повреждённом префабе при создании: все системы частиц на каждом объекте в иерархии автоматически сработают один раз. +- На повреждённом префабе при создании: все динамические тела на каждом объекте в иерархии автоматически получат импульс от последнего удара, уничтожившего предыдущее состояние. +- На повреждённом префабе при создании: все остальные мэши на каждом объекте в иерархии останутся на месте, если у них нет флага динамического тела. +- Часть иерархии объекта: частицы сильного удара (heavy hit particles) должны быть общими для всех состояний разрушения и воспроизводятся всякий раз, когда DestructibleComponent получает урон, равный _HeavyHitParticlesThreshold_. +- Вы можете воспроизводить пользовательские анимации на DestructibleComponents, имеющих скелет (например, ворота замка, по которым бьёт таран). Прогресс анимации будет перенесён на новые созданные повреждённые объекты. +- Вы можете добавить скрипт типа AmbientSoundEmitter на повреждённый префаб и указать звуковое событие. Оно будет автоматически воспроизводиться при создании объекта. +- Помимо использования нескольких состояний, вы также можете добавить несколько дочерних объектов с DestructibleComponents (например, отдельные разрушаемые черепичные плитки крыши тарана). Имейте в виду, что любой урон, применённый к дочернему DestructibleComponent, также применяется к каждому родителю в иерархии. В настоящее время мы не знаем, как влияет на производительность наличие слишком большого количества таких компонентов. {{% notice tip %}} -Any hit from a weapon will already play the default impact particle effects and sounds based on the material type (wood, stone, ..), so don't go too crazy with extra effects. +Любой удар оружием уже воспроизводит стандартные эффекты частиц и звуки удара в зависимости от типа материала (дерево, камень и т. д.), поэтому не стоит слишком усердствовать с дополнительными эффектами. {{% /notice %}} {{% notice warning %}} -Any dynamic mesh that is flying around after spawning a damaged entity, is temporary and should have no physics collision with the player! They should not affect gameplay, because we don't synchronize these for players in multiplayer. +Любой динамический мэш, летающий вокруг после создания повреждённого объекта, является временным и не должен иметь физической коллизии с игроком! Они не должны влиять на геймплей, поскольку мы не синхронизируем их для игроков в многопользовательском режиме. {{% /notice %}} -## Examples +## Примеры -### Example 1: Wall with breakable merlons +### Пример 1: Стена с разрушаемыми зубцами -For walls, we can only destroy the merlons and nothing else. They can only be damaged by mangonels/trebuchets and they will only take one hit before being destroyed. +Для стен мы можем разрушать только зубцы (merlons) и ничего больше. Их может повредить только мангонель/требушет, и они выдерживают только один удар перед разрушением. -| Hierarchy of WallSegment | +| Иерархия WallSegment | | ------ | -|  This is what our scene hierarchy looks like for a single wall piece. European_castle_wall_a_l3 is an entity with script WallSegment. It does not care if it has destructible children or not. Every merlon is a different child-entity that has its own DestructibleComponent script. Once they are destroyed, they all spawn the same destroyed prefab. Every merlon has a debris_holder entity, which is an empty entity. It just hold a ReferenceEntityTag tag, and the correct frame to spawn the destroyed prefab from (Important because of mesh bending: Location and rotation may change compared to the parent). | +|  Вот как выглядит иерархия нашей сцены для одного участка стены. European_castle_wall_a_l3 — это объект со скриптом WallSegment. Ему не важно, есть ли у него разрушаемые дочерние объекты или нет. Каждый зубец — это отдельный дочерний объект со своим собственным скриптом DestructibleComponent. После их разрушения все они создают один и тот же разрушенный префаб. У каждого зубца есть объект debris_holder, который является пустым объектом. Он просто хранит тег ReferenceEntityTag и правильный кадр для создания разрушенного префаба (важно из-за деформации мэша: расположение и поворот могут отличаться от родителя). | -| Script example of a single merlon | +| Пример скрипта одного зубца | | ------ | -|  Every merlon has the exact same script. They will all spawn the "debris" prefab when destroyed. We decided to make them destroy after a single hit from a mangonel, so they have very low hitpoints. DestroyedByStoneOnly makes them ignore damage from all other weapons (arrows, swords, axes, ..). Because of CanBeDestroyedInititally, these merlons have a chance to already be broken when entering the mission. The merlons need a ReferenceEntity entity to determine the spawn frame for the broken prefabs. | +|  У каждого зубца абсолютно одинаковый скрипт. Все они будут создавать префаб "debris" при разрушении. Мы решили, что они разрушаются после одного удара мангонеля, поэтому у них очень мало очков прочности. DestroyedByStoneOnly заставляет их игнорировать урон от всего остального оружия (стрел, мечей, топоров и т. д.). Из-за CanBeDestroyedInititally у этих зубцов есть шанс быть уже сломанными при входе в миссию. Зубцам нужен объект ReferenceEntity, чтобы определить кадр создания для сломанных префабов. | -**Origin of wall and merlon pieces** +**Исходная точка стены и частей зубцов** | | | |-----|-----| - |  Each merlon is a unique mesh, which has its origin point at the bottom of the wall (same as the wall). - |  Every merlon shares the same destroyed prefab, which has a local origin. debris_holder has a ReferenceEntityTag. -|  |  Every child of the debris prefab is an entity with flag "dynamic" and has a collision body. When spawned, it will automatically receive the last impulse that the DestructibleComponent received when destroyed. + |  Каждый зубец — это уникальный мэш, точка начала координат (origin) которого находится у основания стены (так же, как и у стены). + |  Все зубцы используют один и тот же разрушенный префаб, у которого есть локальная точка начала координат. У debris_holder есть ReferenceEntityTag. +|  |  Каждый дочерний объект префаба debris — это объект с флагом "dynamic" и телом коллизии. При создании он автоматически получит последний импульс, который получил DestructibleComponent при разрушении. -### Example 2: Siege Barricade +### Пример 2: Осадная баррикада -Siege barricades are very simple objects. They are static entities and their only function is to block incoming projectiles. However, they can be destroyed in multiple stages. Each stage looking more destroyed than the one before. +Осадные баррикады — очень простые объекты. Это статичные объекты, и их единственная функция — блокировать входящие снаряды. Однако их можно разрушать поэтапно, в несколько стадий. Каждая стадия выглядит более разрушенной, чем предыдущая. -| The different destruction states of a siege barricade | +| Разные стадии разрушения осадной баррикады | | ------ | -|  Currently, the different states do not have any special particles or dynamic entities, but they can easily be added later on. Entities with the "dynamic" body flag, and particle systems will automatically trigger when spawned. | +|  В настоящее время разные состояния не имеют особых частиц или динамических объектов, но их легко можно добавить позже. Объекты с флагом тела "dynamic" и системы частиц автоматически срабатывают при создании. | {{% notice tip %}} -Every stage of the destroyed barricade has its own unique collision body as well. This allows people to shoot arrows more easily through the later destructions, and also move through state_5. +У каждой стадии разрушенной баррикады также есть собственное уникальное тело коллизии. Это позволяет людям легче стрелять стрелами сквозь более поздние стадии разрушения, а также проходить через state_5. {{% /notice %}} -| Hierarchy of siege barricade in scene | Siege Barricade script component | +| Иерархия осадной баррикады на сцене | Скрипт-компонент осадной баррикады | | -------- | ------- | |  |  | -siege_barricade_a is an empty parent. It just holds the script. siege_barricade_a_state1 is the actual mesh + body and has the "original_state" tag. When the barricade takes enough damage, siege_barricade_a_state1 will be made invisible, the next damaged prefab will be spawned and added to siege_barricade_a as a child. This is important because the DestructibleComponent needs to be informed of hits, and it can only do that if it has a (visible) collision body on itself or on a child. +siege_barricade_a — это пустой родитель. Он просто хранит скрипт. siege_barricade_a_state1 — это фактический мэш + тело, и у него есть тег "original_state". Когда баррикада получает достаточно урона, siege_barricade_a_state1 станет невидимым, появится следующий повреждённый префаб и будет добавлен к siege_barricade_a в качестве дочернего объекта. Это важно, потому что DestructibleComponent должен получать информацию об ударах, а сделать это он может только в том случае, если у него самого или у его дочернего объекта есть (видимое) тело коллизии. -the last state (state_5 in this case) will be spawned when the entity has 0 health (fully destroyed). The other ones will be used in between MaxHitPoints and 0. +последнее состояние (в данном случае state_5) будет создано, когда у объекта 0 здоровья (полностью разрушен). Остальные будут использоваться в промежутке между MaxHitPoints и 0. -When the mission is reset (Health is reset to MaxHitPoint), the original entity (entity with tag "original_state") will be made visible again. +При сбросе миссии (здоровье сбрасывается до MaxHitPoint) исходный объект (объект с тегом "original_state") снова станет видимым. -Every DestructionState prefab has the same origin and rotation, so we don't have to use a ReferenceEntity. \ No newline at end of file +У каждого префаба DestructionState одинаковая точка начала координат и поворот, поэтому нам не нужно использовать ReferenceEntity. diff --git a/docs/content/russian/Authoring Mission Scenes/Script Components/scene_spawn_points_guide.md b/docs/content/russian/Authoring Mission Scenes/Script Components/scene_spawn_points_guide.md index 4bbe2bbc..7c8a288e 100644 --- a/docs/content/russian/Authoring Mission Scenes/Script Components/scene_spawn_points_guide.md +++ b/docs/content/russian/Authoring Mission Scenes/Script Components/scene_spawn_points_guide.md @@ -1,142 +1,138 @@ +++ -title = "Scene Spawn Point Guide" +title = "Руководство по точкам появления на сцене" +ai_translated = true [menu.main] identifier = "scene_spawn_point_guide" parent = "bannerlord_scenes" +++ -## How to design fully featured scenes in Bannerlord +## Как создавать полнофункциональные сцены в Bannerlord -Each scene has own basic necessities to run without crashing and has extras to give better experience to player. Designers can check these necessities with [Spawn Point Debug Tool]({{< ref "spawn_point_debug_tool.md" >}}) to be sure that their scene will not crash. +Каждая сцена имеет свои базовые необходимые элементы, чтобы работать без сбоев, а также дополнительные элементы для улучшения опыта игрока. Дизайнеры могут проверить эти необходимые элементы с помощью [инструмента отладки точек появления (Spawn Point Debug Tool)]({{< ref "spawn_point_debug_tool.md" >}}), чтобы убедиться, что их сцена не вызовет сбой. -## 1. Town Center Scene +## 1. Сцена центра города -Player will be spawned on the "sp_player_outside" prefab if he/she is entering the city for the first time, -because of this feature "sp_player_outside" must be placed far from city's entrance; otherwise player will be -spawned on "sp_player" and this spawnpoint can be next to the entrance gate. Town center scene has some -mandatory characters as follows: +Игрок будет появляться в префабе «sp_player_outside», если он/она заходит в город впервые, из-за этой особенности «sp_player_outside» должен быть размещён далеко от входа в город; в противном случае игрок будет +появляться в «sp_player», и эта точка появления может находиться рядом с воротами входа. Сцена центра города имеет несколько +обязательных персонажей: -|Player Spawn Point| +|Точка появления игрока| |-----| -|When player enters the town center from top right panel in the map scene, player and the conversation NPC will be spawned on "sp_player_conversation" prefab. Scene must have these prefabs more than 1 in order increase variation. {{% notice warning %}} The scale of the conversation prefab must not change. +|Когда игрок входит в центр города через верхнюю правую панель на сцене карты, игрок и NPC для разговора будут созданы в префабе «sp_player_conversation». В сцене должно быть больше 1 такого префаба для увеличения вариативности. {{% notice warning %}} Масштаб префаба разговора не должен изменяться. {{% /notice %}}| -|Traders| +|Торговцы| |-----| -|Traders such as armorers, blacksmiths and horse merchants are mandatory for town center scenes. If scene has more than one market place, it is ok to have more then one trader NPCs. Traders in market places may have their own sets. These sets can be considered as prefabs with some spawn points in it. For example, for weaponsmith there can be 3 points in weaponsmith set but there must be 1 spawned weaponsmith. This NPC will go to these points randomly, in a word NPC may go to his/her selling table and start trading or go to the backside of his/her shop and sit on a chair for some time. {{% notice tip %}} Designer may want to change these wait times between actions with "MinWaitInSeconds" and "MaxWaitInSeconds" parameters. (-1: forever). +|Торговцы, такие как оружейники, кузнецы и торговцы лошадьми, обязательны для сцен центра города. Если в сцене несколько рыночных площадей, допустимо иметь более одного NPC-торговца. Торговцы на рыночных площадях могут иметь свои собственные наборы (сеты). Эти наборы можно рассматривать как префабы с несколькими точками появления внутри них. Например, для оружейника может быть 3 точки в наборе оружейника, но должен быть создан 1 оружейник. Этот NPC будет случайным образом перемещаться между этими точками, другими словами, NPC может подойти к своему торговому столу и начать торговлю, либо пойти в заднюю часть своего магазина и сесть на стул на некоторое время. {{% notice tip %}} Дизайнер может захотеть изменить время ожидания между действиями с помощью параметров «MinWaitInSeconds» и «MaxWaitInSeconds». (-1: вечно). {{% /notice %}}| -|Notables| +|Знатные персонажи (Notables)| |-----| -## Notable Parent Prefab +## Родительский префаб знатного персонажа (Notable Parent Prefab) -Scene must have some notables. In order to find them easy, notable spawn points must be placed near center area of the city. -Every notable have their own spawn point tag and every notable have their unique helper characters. +Сцена должна иметь несколько знатных персонажей. Чтобы было легко их найти, точки появления знатных персонажей должны размещаться рядом с центральной областью города. +Каждый знатный персонаж имеет свой собственный тег точки появления, и у каждого знатного персонажа есть уникальные вспомогательные персонажи. -| Notable | Spawn Point Tag | Helper Character Tag | +| Знатный персонаж | Тег точки появления | Тег вспомогательного персонажа | | ------ | ------ | ------ | -| **Preacher** | sp_notable_preacher | sp_preacher_notary | -| **Gang Leader** | sp_notable_gangleader | sp_gangleader_bodyguard | -| **Rural Notable** | sp_notable_rural_notable | sp_rural_notable_notary | -| **Artisan** | sp_notable_artisan | sp_artisan_notary | -| **Merchant** | sp_notable_merchant | sp_merchant_notary | +| **Проповедник (Preacher)** | sp_notable_preacher | sp_preacher_notary | +| **Главарь банды (Gang Leader)** | sp_notable_gangleader | sp_gangleader_bodyguard | +| **Деревенский знатный персонаж (Rural Notable)** | sp_notable_rural_notable | sp_rural_notable_notary | +| **Ремесленник (Artisan)** | sp_notable_artisan | sp_artisan_notary | +| **Купец (Merchant)** | sp_notable_merchant | sp_merchant_notary | -Notables have one parent prefab named **"sp_notables_parent"**. Each notable has 1 set as child so, parent prefab has 5 child notable sets. +Знатные персонажи имеют один родительский префаб с именем **«sp_notables_parent»**. У каждого знатного персонажа есть 1 набор (сет) в качестве дочернего элемента, поэтому родительский префаб имеет 5 дочерних наборов знатных персонажей. -Artists must place this parent prefab and put it in a prominent place of town center. Also prefab must be seen easily by player. After mission start, game logic will activate the notable set according to the notables in the town center. +Художники должны разместить этот родительский префаб и расположить его на видном месте в центре города. Также префаб должен быть легко заметен игроком. После начала миссии игровая логика активирует набор знатного персонажа в соответствии со знатными персонажами в центре города. -In the notable sets, every notable will have unique helper character and their spawn point as well. (bodyguards for gangleader, notary for merchant...). +В наборах знатных персонажей у каждого знатного персонажа будет уникальный вспомогательный персонаж и своя точка появления (телохранители для главаря банды, нотариус для купца...). -In the picture below. There were 2 parent prefabs in the scene. After mission start, one prefab is activated for **gangleader** and her bodyguards. Other prefab is activated for **merchant** and his notary. +На картинке ниже было 2 родительских префаба в сцене. После начала миссии один префаб активируется для **главаря банды** и её телохранителей. Другой префаб активируется для **купца** и его нотариуса. {{% notice tip %}} -Every settlement can have at most 6, every village can have at most 3 notables. So, artist must consider this and place at least 8 parent prefab for town center scenes and place at least 5 parent prefab for village scenes. And town center's have 3 workshop. Each worshop must have 1 parent prefab. -So, for town center scenes 8 + 3 (from workshops) ~10 parent prefabs must be added. +Каждое поселение может иметь не более 6, а каждая деревня — не более 3 знатных персонажей. Поэтому художник должен учесть это и разместить не менее 8 родительских префабов для сцен центра города и не менее 5 родительских префабов для сцен деревень. Также в центрах городов есть 3 мастерские. У каждой мастерской должен быть 1 родительский префаб. +Таким образом, для сцен центра города необходимо добавить 8 + 3 (от мастерских) ~10 родительских префабов. {{% /notice %}} {{% notice warning %}} -All points in the notable sets have rotations according to their motion capture animations, so don't rotate the points or animations will not syncronize. +Все точки в наборах знатных персонажей имеют вращения в соответствии со своими анимациями захвата движения (motion capture), поэтому не вращайте точки — иначе анимации не синхронизируются. {{% /notice %}}  -|Guards| +|Стражники| |-----| -|There are some idle guards and patrolling guards. Patrolling guards are programmed as moving one point to another while activating the next point and deactivating the current one.| +|Есть несколько бездействующих стражников и патрулирующих стражников. Патрулирующие стражники запрограммированы как перемещающиеся от одной точки к другой, активируя следующую точку и деактивируя текущую.| -|Passages| +|Проходы| |-----| -|Town center scene must include all passages to other scenes such as Tavern, Arena, Lords hall...| +|Сцена центра города должна включать все проходы к другим сценам, таким как таверна, арена, зал лордов...| -|Battle Sets| +|Боевые наборы (Battle Sets)| |-----| -|For town scenes, battle sets are only used for common area clearing. so they should not be too far apart, and should be placed to represent a fight between gangs rather than a battle between armies.|, +|Для городских сцен боевые наборы используются только для зачистки общих зон, поэтому они не должны быть расположены слишком далеко друг от друга, и должны размещаться так, чтобы представлять собой драку между бандами, а не битву между армиями.|, -|Townsfolk| +|Горожане| |-----| -|NPCs are always moving around the city. In order to prettify the scene, designer may want to use some extra prefabs. If scene has "sp_npc_repair_set", one NPC will go to that point and start hammering away while other NPC complains about the situation or scene may have some beggars begging for townsfolk help.| +|NPC всегда перемещаются по городу. Чтобы украсить сцену, дизайнер может захотеть использовать несколько дополнительных префабов. Если в сцене есть «sp_npc_repair_set», один NPC подойдёт к этой точке и начнёт стучать молотком, в то время как другой NPC будет жаловаться на ситуацию, либо в сцене могут быть нищие, просящие помощи у горожан.| -## 2. Tavern Scene +## 2. Сцена таверны -|Player Spawn Point| +|Точка появления игрока| |-----| -|Spawnpoint for player, "sp_player", must be placed nearby to the town center passage. Scene must include at least one "sp_player_conversation" prefab or more. {{% notice warning %}} The scale of the conversation prefab must not change. +|Точка появления игрока «sp_player» должна быть размещена рядом с проходом в центр города. Сцена должна включать как минимум один префаб «sp_player_conversation» или более. {{% notice warning %}} Масштаб префаба разговора не должен изменяться. {{% /notice %}}| -|Game Hosts (Gambler NPCs)| +|Ведущие игр (NPC-игроки в азартные игры)| |-----| -|Each tavern scene must have gambler (game host) NPC. The chair underneath NPC must have "gambler_npc" and "npc_wait" tags both. The chair which player will use to join game must have "gambler_player" and "reserved" tags both.| +|Каждая сцена таверны должна иметь NPC-игрока в азартные игры (ведущего игры). Стул под NPC должен иметь оба тега: «gambler_npc» и «npc_wait». Стул, который игрок будет использовать для присоединения к игре, должен иметь оба тега: «gambler_player» и «reserved».| -## 3. Lords Hall Scene +## 3. Сцена зала лордов -|Player Spawn Point| +|Точка появления игрока| |-----| -|Player spawn points for Lords Hall scene is as same as Tavern scene. Spawn point for player must be placed nearby to the town center passage.| +|Точки появления игрока для сцены зала лордов такие же, как и для сцены таверны. Точка появления игрока должна быть размещена рядом с проходом в центр города.| -## 4. Village Scene +## 4. Сцена деревни -|Player Spawn Point| +|Точка появления игрока| |-----| -|Village scene don't have "sp_player_outside" prefab. "sp_player" prefab must not be placed far from village center nor very near. When spawned, player must see the walking villagers from afar. When player enters the village from top right panel in the map scene, player and the conversation NPC will be spawned on "sp_player_conversation" prefab. Scene must have these prefabs more than one in order to increase variation. {{% notice warning %}} The scale of the conversation prefab must not change. +|В сцене деревни нет префаба «sp_player_outside». Префаб «sp_player» не должен быть размещён ни далеко, ни слишком близко от центра деревни. При появлении игрок должен видеть гуляющих жителей деревни издалека. Когда игрок входит в деревню через верхнюю правую панель на сцене карты, игрок и NPC для разговора будут созданы в префабе «sp_player_conversation». В сцене должно быть больше одного такого префаба для увеличения вариативности. {{% notice warning %}} Масштаб префаба разговора не должен изменяться. {{% /notice %}}| -|Notables| +|Знатные персонажи| |-----| -|Scene must have some notables. In order to find them easy, notable spawn points must be placed near center area of the city.| +|Сцена должна иметь несколько знатных персонажей. Чтобы было легко их найти, точки появления знатных персонажей должны размещаться рядом с центральной областью города.| -|Villagers| +|Жители деревни| |-----| -|Villagers have lots of extra activities in village center such as collecting grapes, repairing something or grooming horse. The activities must be balanced between physical and social activities. Villager NPC may go and clean walls then sit and chat with others.| +|У жителей деревни есть множество дополнительных занятий в центре деревни, таких как сбор винограда, починка чего-либо или уход за лошадью. Деятельность должна быть сбалансирована между физической и социальной активностью. NPC-житель деревни может пойти и почистить стены, а затем сесть и поболтать с другими.| -|Common areas| +|Общие зоны| |-----| -|Each village has 3 common areas which are not in the village center. Any type of spawn points can be used inside of the common area. "common_area_NUMBER" prefabs should be placed to specify the area. This prefabs has a script attached named "CommonAreaScript". The script has some parameters as follows:| -|AreaRadius : Artist can change this parameter script to extend or reduce the area. | -|AreaIndex : Already set in prefabs for three common areas| -|Type : Type of the area should be set from the list below| +|У каждой деревни есть 3 общие зоны, которые не находятся в центре деревни. Внутри общей зоны можно использовать любой тип точек появления. Префабы «common_area_NUMBER» должны быть размещены, чтобы обозначить зону. К этому префабу прикреплён скрипт с именем «CommonAreaScript». Скрипт имеет следующие параметры:| +|AreaRadius: Художник может изменить этот параметр скрипта, чтобы расширить или уменьшить зону. | +|AreaIndex: Уже установлен в префабах для трёх общих зон| +|Type: Тип зоны следует задать из списка ниже| -|Area Types|Scene|Explanation| +|Типы зон|Сцена|Пояснение| |-----|-----|-----| -Backstreet|Town Center|Back alley where thugs are spawned -Clearing|Town Center|Open area -Waterfront|Town Center|Near coast or port -Pasture|Village|Pasture, forage (usually a heath or moor) -Thicket|Village|Shrubbery -Bog|Village|Swampy area -Forest|Village|Lots of trees -Ravine|Village|Valley or canyon -Spring|Village|Puddle in desert -Cove|Village|Bay -Marsh|Village|Swampy area near river -Wadi|Village|Valley, does not have rocks on both sides - -|Battle Spawnpoints| +Backstreet|Центр города|Переулок, где появляются бандиты +Clearing|Центр города|Открытая зона +Waterfront|Центр города|Рядом с побережьем или портом +Pasture|Деревня|Пастбище, выгон (обычно пустошь или болотистая местность) +Thicket|Деревня|Заросли кустарника +Bog|Деревня|Болотистая местность +Forest|Деревня|Много деревьев +Ravine|Деревня|Долина или каньон +Spring|Деревня|Лужа в пустыне +Cove|Деревня|Бухта +Marsh|Деревня|Болотистая местность у реки +Wadi|Деревня|Долина, не имеющая скал с обеих сторон + +|Точки появления для сражения| |-----| -|If game is opening the scene with battle mode. Battle sets will be initiated and battle troops will be spawned on each. Battle sets must be placed far from each other, and with defender and attacker sides in mind.| - - - - +|Если игра открывает сцену в боевом режиме, будут инициализированы боевые наборы, и боевые отряды будут появляться в каждом из них. Боевые наборы должны быть размещены далеко друг от друга, с учётом сторон атакующих и защищающихся.| diff --git a/docs/content/russian/Authoring Mission Scenes/Script Components/spawn_point_debug_tool.md b/docs/content/russian/Authoring Mission Scenes/Script Components/spawn_point_debug_tool.md index 7df257c3..1116b343 100644 --- a/docs/content/russian/Authoring Mission Scenes/Script Components/spawn_point_debug_tool.md +++ b/docs/content/russian/Authoring Mission Scenes/Script Components/spawn_point_debug_tool.md @@ -1,49 +1,46 @@ +++ -title = "Spawn Point Debug Tool" +title = "Инструмент отладки точек спавна (Spawn Point Debug Tool)" +ai_translated = true [menu.main] identifier = "spawn_point_debug_tool" parent = "bannerlord_scenes" +++ -## Introduction +## Введение -The tool which has prefab named "SpawnPointDebugView" can be added to scene. Prefab has "SpawnPointDebugView" script attached and tool can be opened through inspector toggle. -Tool has 3 tabs named "Scene basic information tab", "Scene entity check tab" and "Navigation mesh check tab". +Инструмент, имеющий префаб с именем "SpawnPointDebugView", можно добавить в сцену. К префабу прикреплён скрипт "SpawnPointDebugView", и инструмент можно открыть переключателем в инспекторе. +Инструмент имеет 3 вкладки: "Scene basic information tab", "Scene entity check tab" и "Navigation mesh check tab".  -## 1. Scene Basic Information Tab +## 1. Вкладка базовой информации о сцене (Scene Basic Information Tab) -This tab tries to determine the scene type in order to find necessities; if detected type is not correct, artist can override the type using toggle buttons below. +Эта вкладка пытается определить тип сцены, чтобы найти необходимые требования; если определённый тип неверен, художник может переопределить тип с помощью переключателей ниже. -## 2. Scene Entity Check Tab +## 2. Вкладка проверки сущностей сцены (Scene Entity Check Tab) -This tab calculates the spawn point count and warns artist if counts are not in the scene criteria. Clicking the "Count Entities" button and toggling the categories will fill the table of calculations. "DONT USE" toggle stands for outdated entities which scene must not include. Last column of table shows how many agent will be spawned on current spawn points. +Эта вкладка подсчитывает количество точек спавна и предупреждает художника, если количество не соответствует критериям сцены. Нажатие кнопки "Count Entities" и переключение категорий заполнит таблицу расчётов. Переключатель "DONT USE" обозначает устаревшие сущности, которые сцена не должна содержать. Последний столбец таблицы показывает, сколько агентов будет порождено на текущих точках спавна.  -At the end of each row there is a button which can list all game prefabs with clicked button's tag. Clicking the button will open a new window that list all prefabs with particular tag. +В конце каждой строки есть кнопка, которая может вывести список всех игровых префабов с тегом нажатой кнопки. Нажатие кнопки откроет новое окно со списком всех префабов с определённым тегом.   -## 3. Navigation Mesh Check Tab -This tool will mark the spawn points which are not on the navigation mesh or on the navigation mesh that will be deactivated by 'Navigation Mesh Deactivator'. If scene does not have 'Navigation Mesh Deactivator', Deactivation face id will be 0 and scene entity check tab will warn artist to place it in scene. Clicking "CHECK" button and toggling the categories will show debug lines on the invalid spawn points with category color. -Navigation Mesh Check tool shows the spawn points according to scene level. Each toggle will activate 2 buttons named "Previous" and "Next". Clicking these buttons will make editor camera to focus on the misplaced spawn points one by one. +## 3. Вкладка проверки навигационной сетки (Navigation Mesh Check Tab) +Этот инструмент пометит точки спавна, которые не находятся на навигационной сетке или находятся на навигационной сетке, которая будет деактивирована с помощью 'Navigation Mesh Deactivator'. Если в сцене нет 'Navigation Mesh Deactivator', Deactivation face id будет равен 0, и вкладка проверки сущностей сцены предупредит художника о необходимости разместить его в сцене. Нажатие кнопки "CHECK" и переключение категорий отобразит отладочные линии на недопустимых точках спавна с цветом категории. +Инструмент проверки навигационной сетки отображает точки спавна в соответствии с уровнем сцены. Каждый переключатель активирует 2 кнопки с именами "Previous" и "Next". Нажатие этих кнопок заставит камеру редактора фокусироваться на неправильно размещённых точках спавна по очереди.  -This tab can also checks points that are out of mission bound but this feature is only working in missions. +Эта вкладка также может проверять точки, находящиеся за пределами границы миссии, но эта функция работает только в миссиях. {{% notice tip %}} -To check points that out of mission bounds, tool can be activated in the mission if current scene has "SpawnPointDebugView" tool prefab with console command "debug.mission_spawnpoint_count_and_mesh_checker_ui". +Чтобы проверить точки за пределами границ миссии, инструмент можно активировать в миссии, если текущая сцена имеет префаб инструмента "SpawnPointDebugView", с помощью консольной команды "debug.mission_spawnpoint_count_and_mesh_checker_ui". {{% /notice %}} {{% notice warning %}} -If you are seeing the tab buttons multiple time, there are more than one "SpawnPointDebugView" in the scene, please remove them. +Если вы видите кнопки вкладок несколько раз, значит в сцене находится более одного "SpawnPointDebugView", пожалуйста, удалите лишние. {{% /notice %}} - - - - diff --git a/docs/content/russian/Authoring Mission Scenes/arenas.md b/docs/content/russian/Authoring Mission Scenes/arenas.md index 1e92dcef..08e5a1c2 100644 --- a/docs/content/russian/Authoring Mission Scenes/arenas.md +++ b/docs/content/russian/Authoring Mission Scenes/arenas.md @@ -1,110 +1,111 @@ +++ -title = "What Makes an Arena Scene" +title = "Что составляет сцену арены" description = "" weight = 1 +ai_translated = true +++ -#### Intro +#### Введение -* We are going to answer the “How to create an arena scene?” and “What should we take into consideration when creating an arena scene?” questions in this documentation. +* В этой документации мы ответим на вопросы «Как создать сцену арены?» и «Что следует учитывать при создании сцены арены?». -#### Scene Preparation +#### Подготовка сцены -* The first topic that needs to be highlighted is that the terrain for the arena scene should not be too big. Fewer terrain nodes can be used in arena scenes. Far less than you need on other types of scenes. +* Первое, на что нужно обратить внимание, — это то, что местность для сцены арены не должна быть слишком большой. В сценах арены можно использовать меньше узлов местности. Гораздо меньше, чем требуется для других типов сцен. -#### Terrain and scene models -* In an arena scene, the terrain should be flat or near flat with a few uneven parts (it is up to the scene author’s taste). -* Models should be placed before with modular parts (stands and lounges). - * Example: A Sturgian arena scene has `sturgia_arena_grandstand_a`, `sturgia_arena_grandstand_b`, `sturgia_arena_grandstand_c`, `sturgia_arena_grandstand_d` modular mesh parts. -* Fake houses should be used because we don’t want the background of the stands and the inner city view to be empty. We can do this by referencing the `Adam0` model’s head height view in the fighting areas and lounges. -* Each faction has unique models. These models should be used accordingly and should be placed on the appropriate parts of the scene. +#### Местность и модели сцены +* В сцене арены местность должна быть плоской или почти плоской, с несколькими неровными участками (это зависит от вкуса автора сцены). +* Модели следует размещать заранее с помощью модульных частей (трибуны и ложи). + * Пример: Стурийская сцена арены имеет модульные части меша `sturgia_arena_grandstand_a`, `sturgia_arena_grandstand_b`, `sturgia_arena_grandstand_c`, `sturgia_arena_grandstand_d`. +* Следует использовать фальшивые дома, поскольку мы не хотим, чтобы фон трибун и вид на внутренний город были пустыми. Это можно сделать, ориентируясь на высоту головы модели `Adam0` в зонах боя и ложах. +* У каждой фракции есть уникальные модели. Эти модели следует использовать соответствующим образом и размещать в подходящих частях сцены. -#### Required spawn points -* In the active fighting area: +#### Необходимые точки появления (spawn points) +* В активной зоне боя: * `tournament_practice_set` * `tournament_fight_set` -* In the lounge area: +* В зоне ложи: * `sp_tournament_master` * `sp_player_near_arena_master` - * `_barrier_passage_center` (needs to be placed at the door or the lounge entry points) + * `_barrier_passage_center` (должна быть размещена у двери или входных точек ложи) * `sp_player` -#### Step-by-step arena creation with screenshots -* Terrain features: One node (Color Map Resolution: 512x512), LOD Multiplier (1) -* The fighting area is now specified. We have also done the terrain painting (we suggest you use `adam0` mesh to help with proportions). +#### Пошаговое создание арены со скриншотами +* Особенности местности: один узел (разрешение карты цвета: 512x512), множитель LOD (1) +* Зона боя теперь определена. Мы также выполнили покраску местности (рекомендуем использовать меш `adam0` для помощи с пропорциями). | | | | ------ | ----------- | | | | -* After designating the arena place, the lounges and the stands should be placed (if you have your own custom models you can use them at this stage, otherwise use existing models in the prefab tab, like `arena_main_building`). -* In addition to the environmental elements, you can place various meshes for visual beautification (stones, broken barrels, logs, etc.). +* После обозначения места арены следует разместить ложи и трибуны (если у вас есть собственные пользовательские модели, вы можете использовать их на этом этапе, в противном случае используйте существующие модели во вкладке префабов, например `arena_main_building`). +* В дополнение к элементам окружения вы можете разместить различные меши для визуального украшения (камни, разбитые бочки, брёвна и т. д.). -* Torches and light sources should also be placed on the scene. +* На сцене также следует разместить факелы и источники света. -* Search for `arena_audience_mid_point` in the prefab tab. Place it in the middle of the scene periodically. +* Найдите `arena_audience_mid_point` во вкладке префабов. Размещайте его периодически в середине сцены. -* Search for `crowd_man` in the prefab tab. Place the three variants as you like on the stands. +* Найдите `crowd_man` во вкладке префабов. Разместите три варианта по своему усмотрению на трибунах. -* This stage is one of the most important ones. The spawn points that should be placed in the arena's main building which we call lounges are the following: +* Этот этап — один из самых важных. Точки появления, которые следует разместить в главном здании арены, которое мы называем ложами, следующие: * `sp_tournament_master` * `sp_player_near_arena_master` * `_barrier_passage_center` * `sp_player` -* `sp_tournament_master` should be placed facing back to the fighting area. In front of this spawn point, you need to place `sp_player_near_arena_master` because they need to face each other. Besides this, `camera_height_limiter` needs to be placed as the lens should see the lounge area. -* Barries need to be placed in the lounge. +* `sp_tournament_master` следует разместить спиной к зоне боя. Перед этой точкой появления нужно разместить `sp_player_near_arena_master`, поскольку они должны быть обращены друг к другу. Помимо этого, необходимо разместить `camera_height_limiter`, поскольку объектив должен видеть зону ложи. +* В ложе необходимо разместить барьеры. -| Spawn point placements | Spawn point placements and placed barriers | +| Размещение точек появления | Размещение точек появления и установленные барьеры | | ------ | ----------- | | | | -| Another angle of the placed spawn points | The level of the Camera Height Limiter, place, and lens’ target | +| Другой угол размещённых точек появления | Уровень ограничителя высоты камеры, место и цель объектива | | ------ | ----------- | | | | -* `envmap_prop` should be placed in the arena centre. The height of this is important. It is suggested to use the `Adam0` model for proportioning. +* `envmap_prop` следует разместить в центре арены. Высота этого объекта важна. Рекомендуется использовать модель `Adam0` для определения пропорций. -* If there are any areas that we don’t want the player or the AI to go to, we should place barriers. +* Если есть области, куда мы не хотим, чтобы заходил игрок или ИИ, следует разместить барьеры. -* A path should be drawn along the stands. This path is used for the stand audio. Don’t forget to name the path. - * Search for `arena_path_sound` in the prefab tab. Place the prefab on the scene wherever you want. Enlarge the `Scripts` drop-down menu on the `Entity Inspector` tab. You should see the `path_converger` script. Enter the path name you entered before into the `Path Name` field in the `path_converger` script. +* Вдоль трибун следует нарисовать путь (path). Этот путь используется для звука трибун. Не забудьте дать пути имя. + * Найдите `arena_path_sound` во вкладке префабов. Разместите префаб на сцене там, где хотите. Разверните выпадающее меню `Scripts` во вкладке `Entity Inspector`. Вы должны увидеть скрипт `path_converger`. Введите имя пути, которое вы указали ранее, в поле `Path Name` скрипта `path_converger`. | | | | ------ | ----------- | | | | -* A general camera needs to be placed on the scene. You can search for `camera_instance` in the prefabs tab. WARNING! There are two Camera Instances in the prefabs tab. The one we are going to use is the one named with lowercase letters. You can add your camera to the scene as shown in the screenshot. +* На сцене необходимо разместить общую камеру. Вы можете найти `camera_instance` во вкладке префабов. ВНИМАНИЕ! Во вкладке префабов есть два Camera Instance. Нам нужен тот, что назван строчными буквами. Вы можете добавить камеру на сцену, как показано на скриншоте. -* For the arena fighting area, you need to place two spawn points. These are: - * `tournament_practice_set` (used for “Practice fight” campaign option) - * `tournament_fight_set` (used for “Join the tournament” campaign option) -* After placing these two sets you need to place child spawn points. You can check the screenshot for details. +* Для зоны боя арены нужно разместить две точки появления. Это: + * `tournament_practice_set` (используется для опции кампании «Тренировочный бой») + * `tournament_fight_set` (используется для опции кампании «Присоединиться к турниру») +* После размещения этих двух наборов нужно разместить дочерние точки появления. Подробности можно посмотреть на скриншоте. | | | | ------ | ----------- | | | | -* You need to place `border_soft` around the fighting area (not necessary around the stands). +* Вокруг зоны боя нужно разместить `border_soft` (не обязательно вокруг трибун). -* The last stage consists of creating the navmesh for the lounge and the fighting area. +* Последний этап заключается в создании навигационной сетки (navmesh) для ложи и зоны боя. | | | | ------ | ----------- | -| | | \ No newline at end of file +| | | diff --git a/docs/content/russian/Authoring Mission Scenes/custom_water_materials_for_non_naval_scenes.md b/docs/content/russian/Authoring Mission Scenes/custom_water_materials_for_non_naval_scenes.md index affd7ea6..534d7829 100644 --- a/docs/content/russian/Authoring Mission Scenes/custom_water_materials_for_non_naval_scenes.md +++ b/docs/content/russian/Authoring Mission Scenes/custom_water_materials_for_non_naval_scenes.md @@ -1,134 +1,134 @@ +++ -title = "Custom Water Materials for Non-Naval Scenes" +title = "Пользовательские материалы воды для не морских (non-naval) сцен" description = "" weight = 1 +ai_translated = true +++ -This guide explains how to give a scene its own water look when the Naval DLC macro-displacement renderer is **not** in use — for example, a river ford, a lake, or any land battle with a water body in it. +Это руководство объясняет, как придать сцене собственный вид воды, когда рендерер макро-смещения (macro-displacement) из дополнения Naval DLC **не** используется — например, брод через реку, озеро или любое сухопутное сражение с водоёмом. --- -## Overview +## Обзор -By default every non-naval scene shares a single engine water material called `base_water_scene_default`. That material controls the colour of the water, how light scatters through it, and what the surface looks like. +По умолчанию каждая не морская (non-naval) сцена использует общий для движка материал воды `base_water_scene_default`. Этот материал управляет цветом воды, тем, как свет рассеивается в ней, и тем, как выглядит поверхность. -You can replace it per-scene with any material that uses the `water_surface` shader. When you do, the engine uses your material instead — and the wave simulation parameters (strength, choppiness, wind direction influence) are no longer overridden by gameplay code, so you can tune them directly in the Scene Inspector. +Вы можете заменить его для конкретной сцены любым материалом, использующим шейдер `water_surface`. Когда вы это делаете, движок использует ваш материал вместо стандартного — а параметры симуляции волн (сила, хаотичность, влияние направления ветра) больше не переопределяются игровым кодом, поэтому вы можете настраивать их напрямую в Scene Inspector. -> **Naval DLC note:** This override only applies when the Naval DLC macro-displacement renderer is **inactive**. In naval combat missions the override is ignored and the naval pipeline takes over as usual. +> **Примечание о Naval DLC:** Это переопределение применяется только тогда, когда рендерер макро-смещения из Naval DLC **неактивен**. В морских боевых миссиях переопределение игнорируется, и управление берёт на себя морской (naval) пайплайн как обычно. --- -## Step 1 — Create a Water Material +## Шаг 1 — Создание материала воды -1. Open the **Resource Browser** and find `base_water_scene_default`. -2. Duplicate it and give it a clear name, for example `my_module_lake_water`. -3. Open the duplicate in the **Material Inspector**. -4. Verify that the **Shader** field shows `water_surface`. Only materials with this exact shader will appear in the scene's water material picker. +1. Откройте **Resource Browser** и найдите `base_water_scene_default`. +2. Дублируйте его и дайте ему понятное имя, например `my_module_lake_water`. +3. Откройте дубликат в **Material Inspector**. +4. Убедитесь, что в поле **Shader** указано `water_surface`. В списке выбора материала воды сцены будут отображаться только материалы именно с этим шейдером. --- -## Step 2 — Set the Material on the Scene +## Шаг 2 — Назначение материала сцене -1. Open your scene in the editor. -2. In the **Scene Inspector**, expand the **Water** group. -3. Find the **Non-Naval Water Material Override** field. -4. Click the picker and choose your material. - - The list is filtered to show only `water_surface` materials. - - Leave the field empty to revert to the engine default (`base_water_scene_default`). -5. Save the scene. The override is stored in the scene file and loaded automatically every time the scene is opened in-game or in the editor. +1. Откройте вашу сцену в редакторе. +2. В **Scene Inspector** разверните группу **Water**. +3. Найдите поле **Non-Naval Water Material Override**. +4. Нажмите на элемент выбора и выберите ваш материал. + - Список отфильтрован так, чтобы показывать только материалы `water_surface`. + - Оставьте поле пустым, чтобы вернуться к стандартному материалу движка (`base_water_scene_default`). +5. Сохраните сцену. Переопределение сохраняется в файле сцены и загружается автоматически каждый раз при открытии сцены в игре или в редакторе. -> -> **Editor preview:** If the Naval DLC is active in your editor session, the **Visibility Manager** panel will show a **"Preview Naval Water Renderer"** checkbox. Make sure this is **unchecked** while working on non-naval water — when it is checked the naval macro-displacement renderer is active and your material override will not be visible. Uncheck it to switch the viewport to the non-naval path and see your material changes live. +> +> **Предпросмотр в редакторе:** Если Naval DLC активен в вашей сессии редактора, на панели **Visibility Manager** появится флажок **"Preview Naval Water Renderer"**. Убедитесь, что он **отключён**, пока вы работаете с не морской водой — когда он включён, активен морской рендерер макро-смещения, и переопределение вашего материала не будет видно. Отключите его, чтобы переключить вьюпорт на не морской путь рендеринга и увидеть изменения материала в реальном времени. --- -## Step 3 — Tune the Material +## Шаг 3 — Настройка материала -The two fields that have the most visual impact are in the Material Inspector. Everything else (wave animation, displacement, caustics) is driven by the simulation and cannot be changed per-material. +Два поля, которые оказывают наибольшее визуальное влияние, находятся в Material Inspector. Всё остальное (анимация волн, смещение, каустика) определяется симуляцией и не может быть изменено для отдельного материала. -### Factor Color — Water Body Color +### Factor Color — цвет тела воды -This controls how light is absorbed as it travels down through the water. Think of it as the colour the water takes on when it is deep. +Этот параметр определяет, как свет поглощается по мере прохождения вглубь воды. Думайте об этом как о цвете, который приобретает вода на глубине. -| Channel | What it controls | +| Канал | Что он контролирует | | :---- | :---- | -| **R (red)** | How much red light survives at depth. Low \= reds disappear quickly, giving a blue-green tint. | -| **G (green)** | How much green light survives. | -| **B (blue)** | How much blue light survives. High \= clear blue water. | -| **A (alpha)** | How quickly the scattered haze takes over with depth. Low values make the haze appear almost immediately; higher values (0.5–2.0) give a natural depth gradient. | +| **R (красный)** | Насколько красный свет сохраняется на глубине. Низкое значение \= красный быстро исчезает, давая сине-зелёный оттенок. | +| **G (зелёный)** | Насколько сохраняется зелёный свет. | +| **B (синий)** | Насколько сохраняется синий свет. Высокое значение \= чистая синяя вода. | +| **A (альфа)** | Насколько быстро рассеянная дымка проявляется с глубиной. Низкие значения делают дымку почти мгновенной; более высокие значения (0,5–2,0) дают естественный градиент глубины. | -**Starting points to try:** +**Отправные точки для проб:** -| Water type | Factor Color (R, G, B, A) | +| Тип воды | Factor Color (R, G, B, A) | | :---- | :---- | -| Clear tropical blue | 0.05, 0.35, 0.80, 1.0 | -| Deep dark ocean | 0.02, 0.10, 0.25, 1.5 | -| Murky river | 0.10, 0.50, 0.30, 0.8 | -| Shallow lagoon | 0.15, 0.60, 0.70, 0.5 | -| Swamp / bog | 0.20, 0.35, 0.10, 0.4 | +| Чистая тропическая синяя | 0.05, 0.35, 0.80, 1.0 | +| Глубокий тёмный океан | 0.02, 0.10, 0.25, 1.5 | +| Мутная река | 0.10, 0.50, 0.30, 0.8 | +| Мелкая лагуна | 0.15, 0.60, 0.70, 0.5 | +| Болото / трясина | 0.20, 0.35, 0.10, 0.4 | -> The colour values are in linear space. The Material Inspector displays them converted to sRGB for readability — what you see in the colour picker is approximately what you will see in-game in bright sunlight. +> Значения цвета заданы в линейном пространстве. Material Inspector отображает их конвертированными в sRGB для удобства восприятия — то, что вы видите в выборе цвета, примерно соответствует тому, что вы увидите в игре при ярком солнечном свете. -### Factor2 Color — Underwater Haze / Scatter Color +### Factor2 Color — цвет подводной дымки / рассеяния -This is the tint of the murky glow you see when looking through shallow water at a lit surface below. Think of it as the colour of the water itself rather than what is behind it. +Это оттенок мутного свечения, которое вы видите, глядя сквозь мелкую воду на освещённую поверхность внизу. Думайте об этом как о цвете самой воды, а не того, что находится за ней. -| Channel | What it controls | +| Канал | Что он контролирует | | :---- | :---- | -| **R, G, B** | The haze colour. A good starting point is a lighter, slightly greenish version of your Factor Color. | -| **A (alpha)** | How strongly the haze colour appears near the surface. 0.1–0.3 is a natural range. | +| **R, G, B** | Цвет дымки. Хорошей отправной точкой будет более светлая, слегка зеленоватая версия вашего Factor Color. | +| **A (альфа)** | Насколько сильно цвет дымки проявляется у поверхности. 0,1–0,3 — естественный диапазон. | -**Starting points to try:** +**Отправные точки для проб:** -| Water type | Factor2 Color (R, G, B, A) | +| Тип воды | Factor2 Color (R, G, B, A) | | :---- | :---- | -| Clear tropical blue | 0.10, 0.60, 0.50, 0.2 | -| Deep dark ocean | 0.05, 0.20, 0.40, 0.1 | -| Murky river | 0.15, 0.40, 0.20, 0.3 | -| Swamp / bog | 0.20, 0.30, 0.08, 0.35 | +| Чистая тропическая синяя | 0.10, 0.60, 0.50, 0.2 | +| Глубокий тёмный океан | 0.05, 0.20, 0.40, 0.1 | +| Мутная река | 0.15, 0.40, 0.20, 0.3 | +| Болото / трясина | 0.20, 0.30, 0.08, 0.35 | -> Set Factor2 Color to a colour in the same family as Factor Color but lighter and slightly more green or cyan. Very saturated values can look unnatural. +> Установите Factor2 Color в цвет той же гаммы, что и Factor Color, но светлее и чуть более зелёный или циановый. Слишком насыщенные значения могут выглядеть неестественно. --- -## Step 4 — Tune the Scene Wave Settings +## Шаг 4 — Настройка параметров волн сцены -When a custom water material override is active, the gameplay code no longer forces fixed wave parameters onto your scene. The sliders in the **Scene Inspector Water group** now have full effect. +Когда активно переопределение материала воды для конкретной сцены, игровой код больше не навязывает сцене фиксированные параметры волн. Ползунки в группе **Scene Inspector Water group** теперь получают полный эффект. -| Slider | What it does | Suggested range | +| Ползунок | Что он делает | Рекомендуемый диапазон | | :---- | :---- | :---- | -| **Strength** | Controls how energetic and tall the waves are. Higher \= choppier surface, more foam at the edges. | 0.5–3.0 for rivers and lakes; up to 6–8 for stormy coasts | -| **Choppiness** | Controls the shape of wave peaks. 0 \= smooth rolling waves, 1 \= sharp peaked waves. | 0.3–0.7 for most water bodies | -| **Wind Dependency** | How strongly the waves align with the wind direction. 0 \= waves travel in all directions equally, 1 \= waves strongly follow the wind. | 0.0–0.5 for enclosed water; 0.5–1.0 for open water | +| **Strength (сила)** | Управляет тем, насколько энергичными и высокими будут волны. Выше \= более хаотичная поверхность, больше пены у краёв. | 0,5–3,0 для рек и озёр; до 6–8 для штормовых побережий | +| **Choppiness (хаотичность)** | Управляет формой гребней волн. 0 \= гладкие пологие волны, 1 \= острые пики волн. | 0,3–0,7 для большинства водоёмов | +| **Wind Dependency (зависимость от ветра)** | Насколько сильно волны выравниваются по направлению ветра. 0 \= волны движутся во всех направлениях одинаково, 1 \= волны сильно следуют за ветром. | 0,0–0,5 для замкнутых водоёмов; 0,5–1,0 для открытой воды | -> Without a material override, **Strength** is forced to 10 and **Wind Dependency** to 0 by the engine regardless of what you set here. The sliders only take effect when a custom material override is assigned. +> Без переопределения материала **Strength** принудительно устанавливается в 10, а **Wind Dependency** — в 0 движком, независимо от того, что вы здесь зададите. Ползунки вступают в силу только тогда, когда назначено переопределение пользовательского материала. --- -## What Cannot Be Changed per Material +## Что нельзя изменить для отдельного материала -The following are driven by the engine simulation or the global render pipeline. They are the same for every non-naval water surface in every scene and cannot be overridden by changing the water material. +Следующее управляется симуляцией движка или глобальным пайплайном рендеринга. Эти параметры одинаковы для каждой не морской поверхности воды в каждой сцене и не могут быть переопределены изменением материала воды. -- Wave normal maps and displacement (these come from the FFT water simulation) -- Caustics -- Refraction of the scene behind the water +- Карты нормалей волн и смещение (они берутся из симуляции воды на основе FFT) +- Каустика +- Преломление сцены позади воды --- -## Hot-Reloading in the Editor +## Горячая перезагрузка в редакторе (Hot-Reloading) -When you save changes to your water material while the scene is open in the editor, the engine detects the change and refreshes the water automatically within a few seconds. You do not need to reload the scene. +Когда вы сохраняете изменения в своём материале воды, пока сцена открыта в редакторе, движок обнаруживает изменение и автоматически обновляет воду в течение нескольких секунд. Перезагружать сцену не требуется. -If the water does not update after saving the material, try toggling the **Non-Naval Water Material Override** picker off and back on to force a refresh. +Если вода не обновляется после сохранения материала, попробуйте переключить элемент выбора **Non-Naval Water Material Override** выключить и снова включить, чтобы принудительно обновить. --- -## Quick Checklist - -- [ ] Material shader is exactly `water_surface` -- [ ] Override field is set in the Scene Inspector Water group -- [ ] Scene is saved after setting the override -- [ ] Factor Color alpha is above 0.1 (very low values make all water look uniformly hazy) -- [ ] Factor2 Color is in the same colour family as Factor Color but lighter -- [ ] Strength and Choppiness sliders are set to the values you want (they now matter) +## Краткий чек-лист +- [ ] Шейдер материала — точно `water_surface` +- [ ] Поле переопределения установлено в группе Water в Scene Inspector +- [ ] Сцена сохранена после установки переопределения +- [ ] Альфа Factor Color выше 0,1 (слишком низкие значения делают всю воду равномерно мутной) +- [ ] Factor2 Color в той же цветовой гамме, что и Factor Color, но светлее +- [ ] Ползунки Strength и Choppiness установлены на нужные вам значения (теперь они имеют значение) diff --git a/docs/content/russian/Authoring Mission Scenes/sieges.md b/docs/content/russian/Authoring Mission Scenes/sieges.md index 5e49fdd8..c4e14eb0 100644 --- a/docs/content/russian/Authoring Mission Scenes/sieges.md +++ b/docs/content/russian/Authoring Mission Scenes/sieges.md @@ -1,63 +1,65 @@ +++ -title = "Как создать сцену осады" +title = "Что делает сцену сценой осады" description = "" -weight = 1 +weight = 10 +ai_translated = true +++ #### Введение -Этот перечень особенностей осады поможет вам при создании городов и замков, подходящих для осады. +Этот список особенностей, специфичных для осады, поможет вам при создании городов и замков, подходящих для осад. ___ -#### Осаждаемые сцены +#### Осаждаемые стены -*Осадные стены - это позиции стен, которые поддерживают функцию пробитых стен в сценах осады. Нам нужно будет указать твердые и сломанные этапы и их важные позиции, а также изменения сетки навигации AI, как если бы произошел разрыв.* +*Осаждаемые стены — это позиции стен, которые поддерживают функцию пробитых стен в сценах осады. Нам нужно будет указать целые и разрушенные состояния и их важные позиции, а также изменения навигационной сетки ИИ, если образуется пролом.* -* Add a tag to the parent entity, that will later be used on siege ladders and siege towers (ex:wall_segment_left, wall_segment_right). This tag will identify which siege machines are related to which lanes, and will be used for “target wall segment” variable on siege machines. -* Add the tag “broken_child” to the broken wall, and add the tag “solid_child” to the solid wall. -* Add two entities as child entities to the solid wall. First one for where defender troops will wait as attackers approach the castle, and second for where they should stand for defending position. These entities should have the tags “wait_pos” and “middle_pos'' respectively. +* Добавьте тег родительской сущности, который впоследствии будет использоваться на осадных лестницах и осадных башнях (например: wall_segment_left, wall_segment_right). Этот тег будет определять, какие осадные машины относятся к каким полосам, и будет использоваться для переменной «target wall segment» на осадных машинах. +* Добавьте тег «broken_child» к разрушенной стене и тег «solid_child» к целой стене. +* Добавьте две дочерние сущности к целой стене. Первая — для места, где защитники будут ждать приближения атакующих к замку, вторая — для места, где они должны стоять в оборонительной позиции. Эти сущности должны иметь теги «wait_pos» и «middle_pos» соответственно. - + -* For the broken wall, add three child entities. They should have the tags “wait_pos”, “middle_pos” and “attacker_wait_pos”. First two are the same as solid wall and attacker wait pos is where Attacker troops will wait (preferably behind covers) while other siege engines get into position. -* **WallSegment script** - * Enter the side of the siegeable wall (it should be either left or right, middle is reserved for the gatehouse regardless of its position). - * Enter the navigation mesh ids you will use for that siegeable wall. - * Remake and id the navigation mesh accordingly. - * Make sure that new navigation mesh faces have correct levels. +* Для разрушенной стены добавьте три дочерние сущности. Они должны иметь теги «wait_pos», «middle_pos» и «attacker_wait_pos». Первые два аналогичны целой стене, а attacker_wait_pos — это место, где атакующие войска будут ждать (предпочтительно за укрытиями), пока другие осадные орудия занимают позицию. +* Добавьте скрипты WallSegment со значениями по умолчанию к разрушенной и к целой стене. +* **Скрипт WallSegment** (родительская сущность) + * Укажите сторону осаждаемой стены (она должна быть либо левой, либо правой; средняя зарезервирована для надвратной башни независимо от её положения). + * Введите идентификаторы навигационной сетки, которые вы будете использовать для этой осаждаемой стены. + * Пересоздайте и промаркируйте навигационную сетку соответствующим образом. + * Убедитесь, что новые грани навигационной сетки имеют правильные уровни. - + -| Solid Wall Navmesh | Broken Wall Navmesh | +| Навигационная сетка целой стены | Навигационная сетка разрушенной стены | | ------ | ----------- | -|  |  | +| | | -* If you are not going to use under debris navmesh ids you can enter “-1” to corresponding ID’s on the wall segment script. -* In this example when the wall is not broken, 328 will connect to 342, 331 will connect to 391, 341 will be active, and 351 will be active. -* When the wall is broken and there is a breach, 328 will connect to 371 and 381 will connect to 391, and 361 will be active. -* This way if we have a lot of debris around the siegeable wall, we will have much fewer agents getting stuck for lack of navigation mesh. -* In this image, empty spaces between navmeshes were exaggerated for sake of clarity. +* Если вы не собираетесь использовать идентификаторы навигационной сетки под обломками, вы можете ввести «-1» в соответствующие ID в скрипте wall segment. +* В этом примере, когда стена не разрушена, 328 будет соединяться с 342, 331 будет соединяться с 391, 341 будет активен, а 351 будет активен. +* Когда стена разрушена и образован пролом, 328 будет соединяться с 371, а 381 будет соединяться с 391, и 361 будет активен. +* Таким образом, если вокруг осаждаемой стены много обломков, гораздо меньше агентов будут застревать из-за отсутствия навигационной сетки. +* На этом изображении пустые пространства между навигационными сетками были преувеличены для наглядности. ___ #### Ворота замка -*The castle gate is the location and prefabs that interact with the battering ram. We will have to use 2 of them, 1 outer gate which will be broken down by the battering ram and an inner one which will be broken down by normal troop attacks.* +*Ворота замка — это место и префабы, которые взаимодействуют с тараном. Нам нужно будет использовать 2 ворот: 1 внешние, которые будут разбиты тараном, и внутренние, которые будут разбиты обычными атаками войск.* -* Place the outer and inner gates. -* Outer gate should have an “outer_gate” tag, and the inner gate should have an “inner_gate” tag. -* **CastleGate script** - * Enter the navigation mesh id you will use for the gate. - * Make the side variable “middle”. - * Change the HP of the gate according to its position and level (For outer gates HP’s should be: 12000 on level 1, 15000 on level 2 and 18000 on level 3. Inner gates HP’s should be 1000 for all levels.) - * Remake and id the navigation mesh accordingly. - * Make sure that new navigation mesh faces have correct levels. -* Adjust the position of “middle_position” of the outer gate. It should be really close to the inner side of the inner gate. -* You can turn off the navmeshes, for open state of the gate using [navigationmeshidtodisableonopen] navmesh id. +* Разместите внешние и внутренние ворота. +* Внешние ворота должны иметь тег «outer_gate», а внутренние — тег «inner_gate». +* **Скрипт CastleGate** + * Введите идентификатор навигационной сетки, который вы будете использовать для ворот. + * Установите переменную стороны (side) как «middle». + * Измените HP ворот в соответствии с их положением и уровнем (для внешних ворот HP должно быть: 12000 на уровне 1, 15000 на уровне 2 и 18000 на уровне 3. HP внутренних ворот должно быть 1000 для всех уровней.) + * Пересоздайте и промаркируйте навигационную сетку соответствующим образом. + * Убедитесь, что новые грани навигационной сетки имеют правильные уровни. +* Отрегулируйте позицию «middle_position» внешних ворот. Она должна быть очень близко к внутренней стороне внутренних ворот. +* Вы можете отключать навигационные сетки для открытого состояния ворот, используя идентификатор навигационной сетки [navigationmeshidtodisableonopen]. - + -* **Related prefabs** +* **Связанные префабы** * Aserai_castle_gate_inner_l1 * Aserai_castle_gate_outer_l1 * Battania_castle_gate_inner_l3 @@ -74,33 +76,33 @@ ___ ___ -#### Deployment Points +#### Точки развёртывания -*All siege machines are placed under deployment points. These points later in the mission become the selectable positions, in which players can place their siege equipment, like ballistas, battering ram or the siege towers.* +*Все осадные машины размещаются под точками развёртывания. Эти точки впоследствии в миссии становятся выбираемыми позициями, в которых игроки могут размещать своё осадное снаряжение, такое как баллисты, таран или осадные башни.* -* There needs to be 4 of those for the defender siege machines. 4 for the attacker siege machines. 2 for each siege tower. And one for the battering ram. -* The siege machines can be connected to these deployment points, by either placing them in their radius, or by tags. +* Должно быть 4 таких точки для осадных машин защитника. 4 для осадных машин атакующего. 2 для каждой осадной башни. И одна для тарана. +* Осадные машины могут быть связаны с этими точками развёртывания либо путём размещения их в радиусе действия точки, либо с помощью тегов. - + -* Best practices - * Make sure the radiuses of the Deployment Points don't overlap. - * You'll need to have different Deployment Points for each layer, for example: - * Since the walls change with each layer, the defender siege machines naturally have to be in different positions on top of them. - * Since the gate house position changes, the battering ram needs to take a different path. The same goes for siege towers. +* Лучшие практики + * Убедитесь, что радиусы точек развёртывания не перекрываются. + * Вам нужны разные точки развёртывания для каждого слоя (layer), например: + * Поскольку стены меняются с каждым слоем, осадные машины защитника естественным образом должны находиться в разных позициях на их вершине. + * Поскольку положение надвратной башни меняется, тарану нужен другой путь. То же самое касается осадных башен. ___ -#### Secondary Siege Machines +#### Второстепенные осадные машины -*Secondary siege machines are ranged siege machines that support the assault or try to fend off attackers. They include ballistas and mangonels for both sides and trebuchets for the attacker.* +*Второстепенные осадные машины — это дальнобойные осадные машины, которые поддерживают штурм или пытаются отразить атакующих. К ним относятся баллисты и манганели для обеих сторон и требушеты для атакующего.* -* Mangonel and ballista entities should be included for each defender position, and mangonel ballista and trebuchet prefab should be included for each attacker position. -* There should be 4 “Deployment Point” positions for defenders and 4 for attackers. -* Both siege machines and deployment points have a “side” variable, make sure those variables are correct. -* No siege machine should be under control of more than one deployment point. +* Сущности манганели и баллисты должны быть включены для каждой позиции защитника, а префабы манганели, баллисты и требушета должны быть включены для каждой позиции атакующего. +* Должно быть 4 позиции «точки развёртывания» для защитников и 4 для атакующих. +* И осадные машины, и точки развёртывания имеют переменную «side» (сторона), убедитесь, что эти переменные корректны. +* Ни одна осадная машина не должна находиться под управлением более чем одной точки развёртывания. -* **Related prefabs** +* **Связанные префабы** * Ballista_a_spawner * Ballista_b_spawner * Mangonel_a_spawner @@ -109,89 +111,89 @@ ___ ___ -#### Siege Tower - -*Siege towers are the prefabs that support the situation when siegers build a siege tower in the campaign map. They replace one of the wall lanes. If a siege tower is deployed they will override the siege ladder on that “side”. If there is a breach on a lane, the siege tower can not be deployed to that lane.* - -* Place the suitable siege tower to the scene. -* Adjust the angle of the deployable exit ramp of the either by selecting the ramp and rotating it or using the “RampRotationDegree” parameter within the “SiegeTowerSpawner” script -* If your exit ramp has a large slope angle either upwards or downwards, make sure that the navigation mesh prefab fits the ramp, otherwise make one. -* [Build the path for the siege tower]({{< ref "path_editing.md" >}}), using the path tool. -* **SiegeTowerSpawner script** - * Enter the path name. - * Enter the target wall segment. This is the tag we added to the wall that has the middle and wait positions. The siege tower will search for that tag and then search for its child entities to direct AI troops accordingly. - * Enter the side tag. - * Once the tower is connected to its path, place the deployment point at the beginning of the path in connection to the siege tower. -* You can mark the merlons on the way of the siege tower with the tag `tower_merlon`. These merlons will be removed once a siege tower is deployed to the scene. Make sure that they have a “DestructableComponent” script and “CanBeDestroyedInitially” tag is selected. -* Place a “_barrier_ai_04x04m” prefab on the wall where the siege tower will approach. Give the barrier a unique tag like “tower_barrier_lvl3”. Now insert this tag within the “BarrierTagToRemove” parameter under the SiegeTowerSpawner script. The tagged barrier will be removed once the ramp of the siege tower is open. +#### Осадная башня + +*Осадные башни — это префабы, которые поддерживают ситуацию, когда осаждающие строят осадную башню на карте кампании. Они заменяют одну из полос стены. Если осадная башня развёрнута, она заменит осадную лестницу на этой «стороне». Если на полосе есть пролом, осадную башню нельзя развернуть на этой полосе.* + +* Разместите подходящую осадную башню в сцене. +* Отрегулируйте угол выдвижной рампы, либо выбрав рампу и повернув её, либо используя параметр «RampRotationDegree» в скрипте «SiegeTowerSpawner». +* Если у вашей выходной рампы большой угол наклона вверх или вниз, убедитесь, что префаб навигационной сетки подходит к рампе, иначе создайте новый. +* [Постройте путь для осадной башни]({{< ref "path_editing.md" >}}), используя инструмент путей. +* **Скрипт SiegeTowerSpawner** + * Введите название пути. + * Введите целевой сегмент стены (target wall segment). Это тег, который мы добавили к стене, имеющей позиции middle и wait. Осадная башня будет искать этот тег, а затем искать его дочерние сущности, чтобы направлять войска ИИ соответствующим образом. + * Введите тег стороны (side tag). + * После того как башня подключена к своему пути, разместите точку развёртывания в начале пути, в связи с осадной башней. +* Вы можете пометить зубцы (мерлоны) на пути осадной башни тегом `tower_merlon`. Эти зубцы будут удалены, как только осадная башня развернётся в сцене. Убедитесь, что у них есть скрипт «DestructableComponent» и выбран тег «CanBeDestroyedInitially». +* Разместите префаб «_barrier_ai_04x04m» на стене там, где будет приближаться осадная башня. Дайте барьеру уникальный тег, например «tower_barrier_lvl3». Теперь вставьте этот тег в параметр «BarrierTagToRemove» в скрипте SiegeTowerSpawner. Помеченный барьер будет удалён, как только откроется рампа осадной башни. -* **Related prefabs** +* **Связанные префабы** * Siege_tower_5m_spawner * Siege_tower_9m_spawner * siege_tower_12m_spawner ___ -#### Battering Ram +#### Таран -*Battering ram is the prefab that supports the situation when siegers build a battering ram in the campaign. The battering ram will be connected to the side tag and will damage the outer gate once it reaches the gates and troops swing the ram.* +*Таран — это префаб, который поддерживает ситуацию, когда осаждающие строят таран во время кампании. Таран будет связан с тегом стороны и будет наносить урон внешним воротам, как только он достигнет ворот и войска начнут раскачивать таран.* -* [Build the path using the path tool]({{< ref "path_editing.md" >}}). The crash indicator on the ghost entity of the battering ram prefab should make contact with the gate to match animations and visuals. +* [Постройте путь с помощью инструмента путей]({{< ref "path_editing.md" >}}). Индикатор столкновения на сущности-призраке префаба тарана должен соприкасаться с воротами, чтобы соответствовать анимациям и визуальным эффектам. - + -* **BatteringRamSpawner script** - * Enter Side Tag +* **Скрипт BatteringRamSpawner** + * Введите тег стороны (Side Tag). * GateTag: outer_gate - * Enter the path name to the script. - * Once the battering ram is connected to its path, place the deployment point at the beginning of the path in connection to the battering ram. + * Введите название пути в скрипт. + * После того как таран подключён к своему пути, разместите точку развёртывания в начале пути, в связи с тараном. -* **Related prefabs** +* **Связанные префабы** * Batteringram_a_spawner ___ -#### Ditch Fillers +#### Заполнители рва -*If the scene has ditches and a moat around the castle, we have a ditch filler system which allows the siege towers and battering rams to work properly. Ditch fillers will spawn if the player deploys the connected siege engines. We will have to arrange and ID various navigation mesh faces for AI to use pathfinding properly around the ditch filler.* +*Если сцена имеет рвы и ров вокруг замка, у нас есть система заполнителей рва, которая позволяет осадным башням и таранам работать правильно. Заполнители рва будут появляться, если игрок развернёт связанные осадные орудия. Нам нужно будет организовать и промаркировать различные грани навигационной сетки, чтобы ИИ мог правильно прокладывать путь вокруг заполнителя рва.* -* After placing the proper entity to fill the moat, [collect all of them under a single parent entity]({{< ref "creating_entity.md#entity-hierarchies" >}}). -* Add the tag “ditch_filler” and the appropriate side tag (left, right, or middle) to the connected siege engine. -* Once a siege tower or a battering ram is deployed, the ditch filler will be deployed with it too. -* We manipulate the navigation mesh in a similar manner to the wall breaches. -* The navmesh ids are on the siege tower and battering ram scripts. -* Enter the navigation mesh ids you will use for that ditch filler. -* Remake and id the navigation mesh accordingly. -* Make sure new navigation mesh faces have correct levels. +* После размещения подходящей сущности для заполнения рва [соберите все их под одной родительской сущностью]({{< ref "creating_entity.md#entity-hierarchies" >}}). +* Добавьте тег «ditch_filler» и соответствующий тег стороны (левая, правая или средняя) к связанному осадному орудию. +* Как только осадная башня или таран развёрнуты, заполнитель рва также будет развёрнут вместе с ними. +* Мы манипулируем навигационной сеткой подобно тому, как это делается для проломов в стенах. +* Идентификаторы навигационной сетки находятся в скриптах осадной башни и тарана. +* Введите идентификаторы навигационной сетки, которые вы будете использовать для этого заполнителя рва. +* Пересоздайте и промаркируйте навигационную сетку соответствующим образом. +* Убедитесь, что новые грани навигационной сетки имеют правильные уровни. -| SiegeTowerSpawner Script | Ditch Filler | +| Скрипт SiegeTowerSpawner | Заполнитель рва | | ------ | ----------- | -|  |  | +| | | -* In this example, when there is no ditch filler, 423, 426, and 424 will be deactivated. 422 and 433 will stay connected 427 will be active, 432 and 425 will be connected. -* When there is a ditch filler, 422 will disconnect from 433 and connect to 423, 426 will be active, 425 will be disconnected from 432 and connect to 424, and 427 will be deactivated. +* В этом примере, когда нет заполнителя рва, 423, 426 и 424 будут деактивированы. 422 и 433 останутся соединёнными, 427 будет активен, 432 и 425 будут соединены. +* Когда есть заполнитель рва, 422 отсоединится от 433 и соединится с 423, 426 будет активен, 425 отсоединится от 432 и соединится с 424, а 427 будет деактивирован. ___ -#### Siege Ladders +#### Осадные лестницы -*Siege ladders are deployed by default to both siegeable walls unless there is a siege tower or a breach.* +*Осадные лестницы по умолчанию развёртываются на обеих осаждаемых стенах, если только не присутствует осадная башня или пролом.* -* Choose the correct size of the ladder spawner, never resize the ladder spawners height. -* **SiegeLadderSpawner script** - * Enter the target wall segment. This is the tag we added to the wall that has the middle and wait positions. The ladder will search for that tag and then search for its child entities to direct AI troops accordingly. - * Enter the id of the navigation mesh you will use. - * Enter the SideTag. - * "merlon_solid_left" or "merlon_solid_right" tag have to add both ladder merlons according to walls right or left position. These tags are added to make sure tagged merlons do not break and cause physics problems with AI troops movements. -* Remake and id the navmesh accordingly. -* Nav mesh face on the siege ladder should be one directional towards the wall. +* Выберите правильный размер спавнера лестницы, никогда не изменяйте высоту спавнеров лестницы. +* **Скрипт SiegeLadderSpawner** + * Введите целевой сегмент стены (target wall segment). Это тег, который мы добавили к стене, имеющей позиции middle и wait. Лестница будет искать этот тег, а затем искать его дочерние сущности, чтобы направлять войска ИИ соответствующим образом. + * Введите идентификатор навигационной сетки, который вы будете использовать. + * Введите SideTag. + * Теги «merlon_solid_left» или «merlon_solid_right» необходимо добавить к обоим зубцам лестницы в соответствии с правым или левым положением стен. Эти теги добавляются для того, чтобы помеченные зубцы не ломались и не вызывали проблем с физикой при движении войск ИИ. +* Пересоздайте и промаркируйте навигационную сетку соответствующим образом. +* Грань навигационной сетки на осадной лестнице должна быть однонаправленной в сторону стены. - + -* Adjust the standing and fork holder positions using the “UpperStateRotationDegree” and “DownStateRotationDegree” to match the terrain and the walls. -* Place a “_barrier_ai_04x04m” prefab on the wall where the ladder will land. Give the barrier a unique tag like “left_ladder_barrier_a”. Now insert this tag to the ladder's “BarrierTagToRemove” parameter. The tagged barrier will be removed once the siege ladder is lifted up to the walls. +* Отрегулируйте позиции стояния и держателя вил, используя «UpperStateRotationDegree» и «DownStateRotationDegree», чтобы соответствовать местности и стенам. +* Разместите префаб «_barrier_ai_04x04m» на стене там, где приземлится лестница. Дайте барьеру уникальный тег, например «left_ladder_barrier_a». Теперь вставьте этот тег в параметр «BarrierTagToRemove» лестницы. Помеченный барьер будет удалён, как только осадная лестница будет поднята к стенам. -* **Related prefabs** +* **Связанные префабы** * Siege_ladder_6m_spawner * Siege_ladder_7m_spawner * Siege_ladder_8m_spawner @@ -200,24 +202,24 @@ ___ ___ -#### Archer Positions +#### Позиции лучников -*Archer positions are AI direction locations with which scene designers can define locations where archers can shoot from. There are 2 types of archer positions.* +*Позиции лучников — это места направления ИИ, с помощью которых дизайнеры сцен могут определять места, откуда лучники могут стрелять. Существует 2 типа позиций лучников.* -* **Big archer positions** - * Positions used by archer formations. - * With prefab names “defender_archer_position” and “attacker_archer_position”. - * They have the tags “archer_position” and “archer_position_attacker”. +* **Большие позиции лучников** + * Позиции, используемые формированиями лучников. + * С названиями префабов «defender_archer_position» и «attacker_archer_position». + * Они имеют теги «archer_position» и «archer_position_attacker». -* **Small archer positions** - * Positions used by archer agents. - * With prefab names “strategic_archer_point” and “strategic_attacker_archer_position”. - * They have the script “strategicarea”. The script has variables for: - * Attacker or defender side. - * Range (an archer position should be in their range for them to be used). There must be a big archer position inside this range for the small archer position to be active. The default range is 40m for defender and 60m for attacker. - * Depth and width: Both represent the size of the area usable by troops. 1x1 is suitable for one troop in a 1m x 1m area. 4x2 is suitable for 8 troops in a 4m x 2m area. - -* **Related prefabs** +* **Малые позиции лучников** + * Позиции, используемые отдельными агентами-лучниками. + * С названиями префабов «strategic_archer_point» и «strategic_attacker_archer_position». + * Они имеют скрипт «strategicarea». У скрипта есть переменные для: + * Стороны атакующего или защитника. + * Радиуса (большая позиция лучника должна быть в их радиусе, чтобы они использовались). Внутри этого радиуса должна быть большая позиция лучника, чтобы малая позиция лучника была активна. Радиус по умолчанию составляет 40 м для защитника и 60 м для атакующего. + * Глубины и ширины: оба параметра представляют размер области, используемой войсками. 1x1 подходит для одного бойца в области 1м x 1м. 4x2 подходит для 8 бойцов в области 4м x 2м. + +* **Связанные префабы** * Defender_archer_position * Attacker_archer_position * Strategic_archer_point @@ -225,110 +227,111 @@ ___ ___ -#### Deployment Boundaries +#### Границы развёртывания -*We place boundary entities to the scene to specify where attackers and defenders can deploy their troops. They work pretty much like soft borders.* +*Мы размещаем сущности границ в сцене, чтобы указать, где атакующие и защитники могут разворачивать свои войска. Они работают примерно как мягкие границы.* -* All boundary entities should have these 3 tags: +* Все сущности границ должны иметь эти 3 тега: * walk_area_vertex - * defender or attacker - * deployment_castle_boundary_[insert number] -* deployment_castle_boundary_[insert number] tag with the same number in [insert number] are connected to each other to create a convex area. For example 5 entities with deployment_castle_boundary_3 tag will create a pentagon, defining a border area. -* You can use prefabs “attacker_boundry“, “defender_boundry“ and edit them to your needs. -* If you add an “out” tag to one of those boundary sets it acts like a negative space, subtracting from the deployment zone instead of adding to it. With this method you can create concave deployment zones. + * defender или attacker + * deployment_castle_boundary_[вставьте номер] +* Теги deployment_castle_boundary_[вставьте номер] с одинаковым номером в [вставьте номер] соединены друг с другом, чтобы создать выпуклую область. Например, 5 сущностей с тегом deployment_castle_boundary_3 создадут пятиугольник, определяя область границы. +* Вы можете использовать префабы «attacker_boundry», «defender_boundry» и редактировать их по своему усмотрению. +* Если вы добавите тег «out» к одному из этих наборов границ, он будет действовать как отрицательное пространство, вычитаясь из зоны развёртывания, а не добавляясь к ней. С помощью этого метода можно создавать вогнутые зоны развёртывания. -* **Related prefabs** +* **Связанные префабы** * Attacker_boundry * Defender_boundry ___ -#### Camera +#### Камера -*The camera position and angle specify the viewpoint that will be used during the deployment phase.* +*Положение и угол камеры определяют точку обзора, которая будет использоваться во время фазы развёртывания.* -* Create an empty entity. -* Camera for the attacker should have the tag “strategycameraattacker”. -* Camera for the defender should have the tag “strategycameradefender”. -* Make sure that the camera positions are inside the deployment boundaries. +* Создайте пустую сущность. +* Камера для атакующего должна иметь тег «strategycameraattacker». +* Камера для защитника должна иметь тег «strategycameradefender». +* Убедитесь, что позиции камеры находятся внутри границ развёртывания. ___ -#### Spawn Points +#### Точки появления -*Spawn points are the locations where NPC troops and the player will spawn in the scene at the start of the battle.* +*Точки появления (spawn points) — это места, где войска NPC и игрок будут появляться в сцене в начале сражения.* -* Use the standard “sp_battle_set” prefab for troop spawning and reinforcements. The prefab includes 16 entities, for each type of troops, attacker and defender, starting or reinforcement. Normal spawn designates the spawn location at the start of the battle, while reinforcements define where the reinforcements will spawn. -* Make sure to set the proper level visibility, since another “sp_battle_set” prefab is used within the civilian level for common area fight missions. +* Используйте стандартный префаб «sp_battle_set» для появления войск и подкреплений. Префаб включает 16 сущностей для каждого типа войск, атакующих и защитников, начальных или подкрепления. Обычное появление обозначает место появления в начале сражения, а подкрепления определяют, где будут появляться подкрепления. +* Убедитесь, что установлена правильная видимость уровня (level visibility), поскольку другой префаб «sp_battle_set» используется в гражданском уровне для миссий боя в общей зоне. ___ -#### Flee Lines +#### Линии бегства -*There are flee lines both for attackers and defenders. If placed in siege scenes, the AI should prefer to run away using the flee lines rather then to the closest soft border edge.* +*Существуют линии бегства как для атакующих, так и для защитников. Если они размещены в сценах осады, ИИ должен предпочитать убегать по линиям бегства, а не к ближайшему краю мягкой границы.* -* Defenders should run to the keep. -* To be active, the Flee lines must be covered by navigation mesh. +* Защитники должны бежать в донжон (keep). +* Чтобы быть активными, линии бегства должны быть покрыты навигационной сеткой. -* **Related prefabs** +* **Связанные префабы** * Flee_line_attacker * Flee_line_defender ___ -#### Tactical Position Script +#### Скрипт тактической позиции -*The script [tacticalposition] enables us to modify the width of various AI positions.* +*Скрипт [tacticalposition] позволяет нам изменять ширину различных позиций ИИ.* -* Once added to an entity you can change many parameters within it. For siege purposes, the only important one is _width. Value entered here is equal to the width of the formation in meters. -* You can use this script in [wait_pos], [middle_pos], [attacker_wait_pos], archer positions and siege ladder wait positions. +* После добавления к сущности вы можете изменить множество параметров внутри него. Для целей осады важен только _width. Введённое здесь значение равно ширине формирования в метрах. +* Вы можете использовать этот скрипт в [wait_pos], [middle_pos], [attacker_wait_pos], позициях лучников и позициях ожидания осадных лестниц. -| Tactical Position | Deployment | +| Тактическая позиция | Развёртывание | | ------ | ----------- | -|  |  | +| | | ___ -#### AI Barrier +#### Барьер ИИ -*The AI barrier should be added to all locations where the AI troops might fall from unacceptable heights.* +*Барьер ИИ следует добавлять во всех местах, где войска ИИ могут упасть с недопустимой высоты.* -* With the path tool, first draw the path line then check the “Enable Barrier Build” checkbox. After the barrier is built, click “Go to entity” and check the scripts of the prefab. The following “barrier_builder” script parameters should be checked: +* С помощью инструмента путей сначала нарисуйте линию пути, затем отметьте флажок «Enable Barrier Build». После того как барьер построен, нажмите «Go to entity» и проверьте скрипты префаба. Следующие параметры скрипта «barrier_builder» должны быть проверены: * AI Limiter * Agent Only - * If necessary, Flip can be checked according to the side of the wall. + * При необходимости можно включить Flip в соответствии со стороной стены. ___ -#### Throwable Rock Pile +#### Куча метательных камней -*We can place usable rock piles to siege scenes.* +*Мы можем размещать используемые кучи камней в сценах осады.* -* The prefab [throwable_rock_pile] has three components: - * Stone pile: With 8 interactable points for AI to pick up the rocks. - * throw_pos: Where the agent will move to throw the rock. - * volume_box: Designates the area to which the AI can throw the rock. -* When an enemy AI moves into the volume_box the prefab will call an agent, that agent will pick up a rock and try to throw it to an enemy in the volume_box that it can target. -* You can have multiple throw_pos per volume_box. Just duplicate the throw_pos entity. -* You connect throw_pos entities to a volume_box by adding a tag to the volume_box and entering that tag name to the script of throw_pos. +* Префаб [throwable_rock_pile] имеет три компонента: + * Stone pile (куча камней): с 8 интерактивными точками для того, чтобы ИИ подбирал камни. + * throw_pos: место, куда агент переместится, чтобы бросить камень. + * volume_box: обозначает область, в которую ИИ может бросить камень. +* Когда вражеский ИИ входит в volume_box, префаб вызовет агента, этот агент подберёт камень и попытается бросить его во врага в volume_box, которого он может выбрать целью. +* Вы можете иметь несколько throw_pos на один volume_box. Просто продублируйте сущность throw_pos. +* Вы соединяете сущности throw_pos с volume_box, добавляя тег к volume_box и вводя это имя тега в скрипт throw_pos. - + ___ -#### Using Throwable rock piles and Archer position (and pretty much everything else) under Broken and Solid walls +#### Использование куч метательных камней и позиций лучников (и почти всего остального) под целыми и разрушенными стенами -* throwable_rock_pile’s and archer positions do work when they are child entities. -* So you can separately place these entities as well as any other entity you want under solid or broken walls as child entities. This way you can create archer positions covering a breach, or utilize the solid wall when there is no breach. +* throwable_rock_pile и позиции лучников работают, когда они являются дочерними сущностями. +* Поэтому вы можете отдельно размещать эти сущности, а также любые другие сущности, которые вы хотите, под целыми или разрушенными стенами в качестве дочерних сущностей. Таким образом вы можете создать позиции лучников, покрывающие пролом, или использовать целую стену, когда пролома нет. -| Example of Solid Walls | Example of Broken Walls | +| Пример целых стен | Пример разрушенных стен | | ------ | ----------- | -|  |  | +| | | ___ -#### Merlons and other Destructible components +#### Зубцы и другие разрушаемые компоненты -*According to the wall HP of the settlement we create wall breaches but we also destroy some the entities containing the destructable_component script. This feature was intended for merlons but it does not specifically check for merlons but rather for the script itself.* +*В зависимости от HP стены поселения мы создаём проломы в стенах, но также разрушаем некоторые сущности, содержащие скрипт destructable_component. Эта функция была задумана для зубцов (мерлонов), но она не проверяет конкретно зубцы, а скорее сам скрипт.* -* A parameter called “CanBeDestroyedInnıtially” is present in the “destructable_component” script. If it is checked, that entity has a chance to be destroyed on mission start, depending on the castle hit points (that are brought down during the siege progression on the campaign map). -* By default it is on for merlons and off for pretty much everything else. If you make any scene specific destructible entities, make sure to set the aforementioned parameter properly. \ No newline at end of file +* В скрипте «destructable_component» присутствует параметр «CanBeDestroyedInnıtially». Если он отмечен, у этой сущности есть шанс быть разрушенной в начале миссии, в зависимости от очков прочности замка (которые снижаются во время осадной прогрессии на карте кампании). +* По умолчанию он включён для зубцов и выключен практически для всего остального. Если вы создаёте какие-либо специфичные для сцены разрушаемые сущности, обязательно правильно настройте указанный параметр. + diff --git a/docs/content/russian/Authoring Mission Scenes/tactical_positions.md b/docs/content/russian/Authoring Mission Scenes/tactical_positions.md index ed9544c5..69fc19c3 100644 --- a/docs/content/russian/Authoring Mission Scenes/tactical_positions.md +++ b/docs/content/russian/Authoring Mission Scenes/tactical_positions.md @@ -1,107 +1,108 @@ +++ title = "Тактические позиции миссии" description = "" -weight = 1 +weight = 20 +ai_translated = true +++ -### Тактические позиции и тактические регионы +### ТАКТИЧЕСКИЕ ПОЗИЦИИ И ТАКТИЧЕСКИЕ ЗОНЫ -Это скриптовые сущности, которые сообщают ИИ об особенностях местности. Они не работают как осада, ИИ не всегда будет использовать тактические позиции или регионы, которые вы можете разместить. Они могут использовать их в условиях, благоприятствующих их использованию. +Это скриптовые сущности, которые сообщают ИИ об особенностях рельефа. Они работают не так, как в осаде — ИИ не всегда будет использовать размещённые вами тактические позиции или зоны. Он может использовать их при условиях, благоприятствующих их применению. -В зависимости от движения игрока и рандомизации пути появления существует очень большое количество сценариев, которые могут возникнуть во время сражений. Из-за этого лучше иметь как можно больше значимых позиций и регионов, отмеченных, насколько это возможно, но их отсутствие или отсутствие отметки некоторых значимых позиций не приведет к очевидным ошибкам, как при осаде, но приведет к менее интересным битвам, потому что ИИ не узнает об их окружении. Типы и способы использования разных тактических позиций и регионов: +В зависимости от движения игрока и рандомизации путей появления войск, во время сражений может возникнуть очень большое количество сценариев. Из-за этого лучше отметить как можно больше значимых позиций и зон, но отсутствие таких отметок, в отличие от осады, не приведёт к очевидным ошибкам, а лишь сделает сражения менее интересными, поскольку ИИ не будет осведомлён об окружающей обстановке. Типы и способы использования различных тактических позиций и зон: #### Тактические позиции -##### Возвышенность, направление движения по склону +##### Возвышенность, склон, обращённый в определённом направлении -Они предназначены для удобных позиций на возвышенности, обращенных в одном направлении. ИИ может удерживать эти позиции, если противник приближается со стороны тактической позиции. -Направление - самая важная часть. Позиция для защиты будет смотреть вперед (зеленая стрелка в редакторе) позиции. Параметры следующие: +Это выгодные позиции на возвышенности, обращённые в одном направлении. ИИ может удерживать такие позиции, если противник наступает со стороны, куда обращена тактическая позиция. +Направление — самая важная часть. Позиция для обороны будет обращена в сторону переднего направления (зелёная стрелка в редакторе) позиции. Параметры следующие: {{% notice info %}} -* _width: the AI will try to form itself to the full extent of the width and if it's too narrow and AI has too many troops or if it's too wide and AI doesn't have enough troops AI may think it's a poorly suitable position. -* _slope: is also important for choosing between positions, it is in degrees and maximum of 60 degrees of slope is recognised by AI. It should roughly estimate the steepness of the position. +* _width: ИИ будет стараться развернуться на всю ширину позиции, и если она слишком узкая, а у ИИ слишком много войск, либо слишком широкая, а у ИИ недостаточно войск, ИИ может посчитать её плохо подходящей позицией. +* _slope: также важен при выборе между позициями, измеряется в градусах, максимум 60 градусов уклона распознаётся ИИ. Должен примерно отражать крутизну позиции. * _isInsurmountable: false * _isOuterEdge: false * _tacticalPositionType: HighGround -* _tacticalPositionMembership: Forest, Opening or Difficult Terrain depending on surroundings. +* _tacticalPositionMembership: Forest, Opening или Difficult Terrain, в зависимости от окружения. * _tacticalPositionSide: BehaviorSideNotSet {{% /notice %}}  -##### Вершина холма, защищаемая со всех сторон +##### Вершина холма, обороняемая со всех направлений -Это для высоких позиций на вершине холмов, которые легко защищать со всех сторон. ИИ может удерживать эти позиции независимо от направления приближения врага. ИИ будет позиционировать себя на вершине холма в соответствии с позицией врага. Направление не важно. +Это позиции на возвышенности на вершине холмов, которые легко оборонять со всех сторон. ИИ может удерживать такие позиции независимо от направления атаки противника. ИИ будет располагаться на вершине холма в зависимости от позиции противника. Направление не имеет значения. {{% notice info %}} -* _width is important, should be roughly equal to the radius of the top of the hill. -* _slope is also important for choosing between positions, it is in degrees and a maximum of 60 degrees of slope is recognised by AI. It should roughly estimate the steepness of the position. -* _isInsurmountable => true this is what defines the property of this type of position +* _width важна, должна примерно соответствовать радиусу вершины холма. +* _slope также важен при выборе между позициями, измеряется в градусах, максимум 60 градусов уклона распознаётся ИИ. Должен примерно отражать крутизну позиции. +* _isInsurmountable => true, именно это определяет свойство данного типа позиции * _isOuterEdge => false * _tacticalPositionType => HighGround -* _tacticalPositionMembership => Forest, Opening or Difficult Terrain depending on surroundings. +* _tacticalPositionMembership => Forest, Opening или Difficult Terrain, в зависимости от окружения. * _tacticalPositionSide => BehaviorSideNotSet {{% /notice %}}  -##### Точка давки +##### Узкие проходы (Choke Points) -Это позиции с непроходимыми преградами с обеих сторон. ИИ с меньшими числами может попытаться удержать эти позиции, чтобы уменьшить их недостаток числа. +Это позиции с непроходимыми преградами с обеих сторон. ИИ с численным меньшинством может попытаться удержать такие позиции, чтобы компенсировать недостаток численности. {{% notice info %}} -* Direction is the most important part. The position to defend will face the forward direction(green arrow in editor) of the position. *** -* _width is important, the AI will try to form itself to the full extent of the width and if it's too narrow and AI has too many troops or if it's too wide and AI doesn't have enough troops AI may think it's a poorly suitable position. -* Slope is also slightly important for choosing between positions, it is in degrees and a maximum of 60 degrees of slope is recognised by AI. It should roughly estimate the steepness of the position. -* _isInsurmountable => false (currently this field does nothing for choke points, but I will add checking both front and back of the same chokepoint if _isInsurmountable is true, therefore if there is a chokepoint that can be used against enemies in front and in back, mark this true instead of adding two chokepoints with opposite directions) +* Направление — самая важная часть. Позиция для обороны будет обращена в сторону переднего направления (зелёная стрелка в редакторе) позиции. *** +* _width важна, ИИ будет стараться развернуться на всю ширину позиции, и если она слишком узкая, а у ИИ слишком много войск, либо слишком широкая, а у ИИ недостаточно войск, ИИ может посчитать её плохо подходящей позицией. +* Уклон также немного важен при выборе между позициями, измеряется в градусах, максимум 60 градусов уклона распознаётся ИИ. Должен примерно отражать крутизну позиции. +* _isInsurmountable => false (в настоящее время это поле ничего не делает для узких проходов, но я добавлю проверку обеих сторон — передней и задней — одного и того же узкого прохода, если _isInsurmountable установлено как true, поэтому, если узкий проход можно использовать против врагов и спереди, и сзади, отметьте это как true вместо добавления двух узких проходов с противоположными направлениями) * _isOuterEdge => false * _tacticalPositionType => ChokePoint -* _tacticalPositionMembership => Forest, Opening or Difficult Terrain depending on surroundings. +* _tacticalPositionMembership => Forest, Opening или Difficult Terrain, в зависимости от окружения. * _tacticalPositionSide => BehaviorSideNotSet {{% /notice %}}  -##### Позиция на утёсе +##### Позиции на обрывах (Cliff Positions) -Эти тактические позиции сами по себе бессмысленны. Они должны быть помещены в иерархию сущностей под тактическими позициями узких мест. Если он размещен под узким проходом и ИИ использует его, будут использоваться только положения обрыва. +Эти тактические позиции сами по себе бессмысленны. Их следует размещать в иерархии сущностей под тактическими позициями узких проходов. Если они размещены под узким проходом и ИИ использует этот узкий проход, только тогда позиции на обрывах будут использоваться. {{% notice info %}} -* Cliff positions should be positions that the enemy cannot reach when the parent choke point is held by other defenders. -* When eligible, ranged and archer formations will move to this position. -* Direction of the cliff position will determine where the archers formation will face when they are using this position. -* _width is important, the AI will try to form itself to the full extent of the width and if it's too narrow and AI has too many troops or if it's too wide and AI doesn't have enough troops AI may think it's a poorly suitable position. -* _slope => not important +* Позиции на обрывах должны быть позициями, которые противник не может достичь, пока родительский узкий проход удерживается другими защитниками. +* Когда это применимо, стрелковые и лучниковые формирования будут перемещаться на эту позицию. +* Направление позиции на обрыве определяет, в какую сторону будет обращено формирование лучников при использовании данной позиции. +* _width важна, ИИ будет стараться развернуться на всю ширину позиции, и если она слишком узкая, а у ИИ слишком много войск, либо слишком широкая, а у ИИ недостаточно войск, ИИ может посчитать её плохо подходящей позицией. +* _slope => не важен * _isInsurmountable => false * _isOuterEdge => false * _tacticalPositionType => Cliff -* _tacticalPositionMembership => Forest, Opening or Difficult Terrain depending on surroundings, not important +* _tacticalPositionMembership => Forest, Opening или Difficult Terrain, в зависимости от окружения, не важно * _tacticalPositionSide => BehaviorSideNotSet {{% /notice %}}  -#### Тактический регион +#### ТАКТИЧЕСКИЕ ЗОНЫ -Они предназначены для маркировки областей в сценах. Дан только радиус, и область имеет круглую форму. Очевидно, что сцены будут иметь регионы с лесами полностью нестандартной/произвольной формы, сложными ландшафтами и открытыми местами. Поэтому следует определить несколько тактических областей с различными круговыми областями, при необходимости их можно добавить. Радиус и круговая площадь каждой области могут быть приблизительными, но не обязательно точными. +Это зоны для отметки областей на сценах. Задаётся только радиус, и зона имеет форму круга. Очевидно, что сцены будут иметь зоны с полностью произвольной/случайной формой лесов, сложной местности и открытых пространств. Поэтому следует определять несколько тактических зон с различными круговыми областями — сколько потребуется. Радиус и круговая площадь каждой зоны могут быть приблизительными, точность не требуется. -##### Лесистая местность +##### Лесные зоны -ИИ может использовать позиции внутри лесных областей, если у врага превосходящее количество стрелков и кавалерии, потому что лучники и кавалерия менее эффективны в лесах. Любой другой регион, который невыгоден как для стрелковых подразделений, так и для кавалерии, может быть отдан лесному региону, он необязательно должен быть лесом, иметь деревья и т.д. Это может быть рынок с множеством препятствий и укрытий или что-то в этом роде. +ИИ может использовать позиции внутри лесных зон, если у противника численное превосходство в стрелковых и кавалерийских подразделениях, поскольку лучники и кавалерия менее эффективны в лесу. Любой другой зоне, невыгодной как для стрелкового оружия, так и для кавалерии, можно присвоить тип «лесная зона» — ей не обязательно быть лесом и иметь деревья и т.п., это может быть рынок с большим количеством препятствий и укрытий или что-то подобное.  ##### Сложная местность -Это включает в себя каменистую местность, а также болота, или могут быть даже рыночные площади или какое-либо место с множеством препятствий на земле, любая область, которая не препятствует дальнему огню (например, леса), но препятствует и замедляет кавалерию, должна быть рассмотрена и отмечена труднопроходимой местностью. ИИ может использовать позиции внутри труднопроходимой местности, если у врага больше кавалерийских единиц. +Сюда входит каменистая местность, а также болота, или даже рынки, или местность с большим количеством препятствий на земле — любая область, которая не мешает стрелковому огню (в отличие от лесов), но затрудняет и замедляет кавалерию, следует рассматривать и отмечать как сложную местность. ИИ может использовать позиции внутри зон сложной местности, если у противника численное превосходство в кавалерийских подразделениях.  -##### Открытая местность +##### Открытые зоны -Позиции, позволяющие быстро передвигаться кавалерии и вести чисто стрелковую стрельбу. Этот тип региона предназначен для обозначения подходящих полей боя. ИИ может выбрать защиту в открытых зонах, если у них есть большее или равное количество отрядов дальнего боя и кавалерии. +Позиции, позволяющие быстрое передвижение кавалерии и чистый стрелковый огонь. Этот тип зоны предназначен для отметки подходящих полей сражения. ИИ может выбрать оборону в открытых зонах, если у него превосходящее или равное количество стрелковых и кавалерийских подразделений.  -#### Совмещение тактических регионов и позиций +#### КОМБИНАЦИИ ТАКТИЧЕСКИХ ЗОН И ПОЗИЦИЙ -Тактические позиции, описанные в разделе A, также могут быть помещены в объекты Тактического региона. Их _tacticalRegionMembership должен быть правильно выбран. В этой ситуации ИИ поймет, что точка прохода также находится в лесном районе, и при правильных условиях может предпочесть это положение давки или возвышенность соответственно. +Тактические позиции, описанные в разделе A, также можно размещать внутри сущностей тактических зон. Их _tacticalRegionMembership должен быть выбран правильно. В этом случае ИИ поймёт, что узкий проход также находится в лесной зоне, и при подходящих условиях сможет предпочесть эту позицию узкого прохода или возвышенность соответственно. diff --git a/docs/content/russian/Authoring Mission Scenes/villages.md b/docs/content/russian/Authoring Mission Scenes/villages.md index b21f2708..600ea909 100644 --- a/docs/content/russian/Authoring Mission Scenes/villages.md +++ b/docs/content/russian/Authoring Mission Scenes/villages.md @@ -1,205 +1,205 @@ +++ -title = "What Makes a Village Scene" +title = "Что делает сцену деревней" description = "" -weight = 1 +weight = 15 +ai_translated = true +++ -#### Introduction -This list of checkpoints should aid you in creation of village scenes and provide you with an insight into what we pay attention to when creating village scenes. - -#### Navigation Mesh - -* Navigation mesh consists of triangles and quads. It is used by the AI for pathfinding. The global illumination system also uses it to find the visible locations of the scene. -* Keep in mind that the navigation mesh faces should not be too far away from the physics below it. The distance should at 1.5m maximum. -* The faces can be labeled to give cues to the agent spawning and the navigation inside the scene. -* In order to make the agents follow roads, we label the faces on top of the roads with the ID 2. -* Note that all of the agent spawnpoints should be connected by navigation mesh faces with ID 2. -* For the animals, navigation mesh ID 3 can be used. Typically, these faces are kept within separate islands in structures like ditches. The animals will then roam inside those islands only. -* Change the ID's of all other faces to 1 (from 0). -* Remember that the agents will use the navigation mesh ID's 2. In order to create realistic pathing (on roads), scene designers should place a Navigation Mesh Deactivator (prefab name is Navigation_Mesh_Deactivator). It can be placed anywhere in the scene. Its purpose is to disable the ID 1 faces in civilian modes. The DisableFaceWithID variable of the script should be 1. -* For the animals, the variable "DisableFaceWithIDForAnimals" within the same script should be 3. -* Make sure the faces are fairly equal in size outside of the village area / where troops will maneuver. -* Make sure there are no disconnected navmeshes. -* The better the navmesh, the better will AI perform on it. Always think about that there might be big field battle inside the village. So try to avoid having many enclosed areas like a pig farm with only 1 entrance (for example: throw over some fences to create more entries) -* Avoid having big areas accessible to the player but not AI. Player will be able to shoot AI from places without navmesh. -* Use “_barrier_ai_x” to prevent AI from falling off from cliffs or getting stuck in tight areas (like a market booth) off the navmesh. +#### Введение +Этот список контрольных пунктов поможет вам в создании сцен деревень и даст представление о том, на что мы обращаем внимание при создании таких сцен. + +#### Навигационная сетка (Navigation Mesh) + +* Навигационная сетка состоит из треугольников и четырёхугольников. Она используется ИИ для построения пути (pathfinding). Система глобального освещения также использует её для определения видимых участков сцены. +* Помните, что грани навигационной сетки не должны находиться слишком далеко от физики под ними. Максимальное расстояние — 1,5 м. +* Грани можно помечать, чтобы давать подсказки для спавна агентов и навигации внутри сцены. +* Чтобы агенты следовали по дорогам, помечайте грани поверх дорог идентификатором (ID) 2. +* Обратите внимание, что все точки спавна агентов должны быть соединены гранями навигационной сетки с ID 2. +* Для животных можно использовать ID навигационной сетки 3. Обычно такие грани располагаются на отдельных «островах» в таких структурах, как рвы. В этом случае животные будут перемещаться только внутри этих островов. +* Измените ID всех остальных граней на 1 (с 0). +* Помните, что агенты будут использовать грани навигационной сетки с ID 2. Чтобы создать реалистичное передвижение (по дорогам), дизайнеры сцен должны разместить Navigation Mesh Deactivator (имя префаба — Navigation_Mesh_Deactivator). Его можно разместить в любом месте сцены. Его назначение — отключать грани с ID 1 в гражданских режимах. Переменная DisableFaceWithID скрипта должна быть равна 1. +* Для животных переменная "DisableFaceWithIDForAnimals" в том же скрипте должна быть равна 3. +* Убедитесь, что грани примерно одинакового размера за пределами территории деревни / там, где будут маневрировать войска. +* Убедитесь, что нет разъединённых участков навигационной сетки. +* Чем лучше навигационная сетка, тем лучше будет работать ИИ на ней. Всегда учитывайте, что внутри деревни может происходить крупное полевое сражение. Поэтому старайтесь избегать множества замкнутых зон, таких как свиноферма только с одним входом (например, можно разобрать часть забора, чтобы создать больше входов). +* Избегайте больших зон, доступных игроку, но не доступных ИИ. Игрок сможет стрелять по ИИ из мест без навигационной сетки. +* Используйте "_barrier_ai_x", чтобы ИИ не падал с обрывов и не застревал в узких местах (например, в рыночном прилавке) за пределами навигационной сетки.  -#### Spawn Points +#### Точки спавна (Spawn Points) -As noted before, all spawn points need to be placed on top of navmesh (ID 2) and inside the soft borders. Remember that some prefabs (like chairs and benches) come with spawn points attached to them. If the spawn points aren't compatible with the village mission, they will most likely crash the game or cause errors. One example is "sp_blacksmith_with_smithing_machine". The most important thing about the entry points are their tags. They decide what type of NPC will spawn there. For your own sake, don't play around with those tags too much and keep them as they are from the prefabs. +Как было сказано ранее, все точки спавна должны располагаться на навигационной сетке (ID 2) и внутри мягких границ (soft borders). Помните, что некоторые префабы (например, стулья и скамейки) уже содержат прикреплённые к ним точки спавна. Если точки спавна несовместимы с миссией деревни, они, скорее всего, приведут к вылету игры или ошибкам. Один из примеров — "sp_blacksmith_with_smithing_machine". Самое важное в точках входа — это их теги. Именно они определяют, какой тип NPC будет там появляться. Ради собственного спокойствия не экспериментируйте слишком сильно с этими тегами и оставляйте их такими, какими они заданы в префабах.  -##### Player Spawnpoint +##### Точка спавна игрока (Player Spawnpoint) -* Prefab: **sp_player**. -* Make sure it's placed in a location where it can be seen from or at least has a clear path leading towards it. Do not place it too far away. -* There should be a navigation mesh under the spawnpoint. +* Префаб: **sp_player**. +* Убедитесь, что она размещена в месте, которое видно или к которому хотя бы ведёт чёткий путь. Не размещайте её слишком далеко. +* Под точкой спавна должна быть навигационная сетка. -##### Battle Spawnpoints - -* Prefab: **Sp_battle_set**. -* Make sure the attacker and defender spawns aren't too close to each other or at least don't have direct line of sight to each other. -* Make sure to move the reinforcement point out of sight as best as possible while still not being too far from the front lines. -* Make sure all spawnpoints have some empty space around for troops to properly spawn in. +##### Боевые точки спавна (Battle Spawnpoints) -##### Conversation Spawnpoints (civilian) +* Префаб: **Sp_battle_set**. +* Убедитесь, что точки спавна атакующих и защищающихся не расположены слишком близко друг к другу или хотя бы не имеют прямой видимости друг на друга. +* Постарайтесь максимально убрать точку подкрепления (reinforcement point) из поля зрения, не размещая её при этом слишком далеко от передовой. +* Убедитесь, что вокруг всех точек спавна достаточно свободного места, чтобы войска могли корректно появляться. -* Prefab: **sp_player_conversation**. -* Conversation points define where the agent and the conversation partner spawn when the player enters the village via the "Talk to Notable" button from the World Map. -* Make sure they have a nice vista but keep them relatively close to the village center. +##### Точки спавна для разговоров (гражданские) -##### Animation Points (civilian) +* Префаб: **sp_player_conversation**. +* Точки разговора определяют, где появляются агент и собеседник, когда игрок заходит в деревню через кнопку "Talk to Notable" на карте мира. +* Убедитесь, что из них открывается приятный вид, но при этом они находятся относительно близко к центру деревни. -* Prefab: **sp_npc_x**. -* These are used for normal villagers. You can use around 40 positions. -* They define the positions in scenes where the villagers will spawn and walk to. -* Make sure they are nicely spaced throughout the village and close surroundings. -* Villagers will wonder along paths to get to them. -* If the paths are too long you might find your villagers wondering around at all times with nobody actually doing anything. Try to avoid long distances and place points close to the main paths. -* Placing more or less spawnpoints doesn't influence how many villagers will populate the scene. +##### Точки анимации (гражданские) -##### Rural Noteable Spawnpoints +* Префаб: **sp_npc_x**. +* Используются для обычных жителей деревни. Можно использовать около 40 позиций. +* Они определяют позиции в сцене, где будут появляться и куда будут ходить жители. +* Убедитесь, что они хорошо распределены по деревне и ближайшим окрестностям. +* Жители будут бродить по путям, чтобы добраться до них. +* Если пути слишком длинные, жители могут постоянно бродить, при этом никто фактически ничего не делает. Старайтесь избегать больших расстояний и размещайте точки ближе к основным путям. +* Размещение большего или меньшего количества точек спавна не влияет на то, сколько жителей будет населять сцену. -* Prefab: **sp_notable_x**. -* The number of prefabs should be around 6. -* These are the spawnpoints for the notables of the village (quest givers) and lords. -* Make sure they are in a prominent location of the village or generally places where village elder / lords would hang around. -* You can check the Debug Window (documentation will cover that) to make sure you have placed the correct notable positions. -* Go to the “Scene Entity Check Tab” and tick the “NPCs” Box and count. +##### Точки спавна сельских знатных персонажей (Rural Noteable Spawnpoints) -##### Bandit Camps +* Префаб: **sp_notable_x**. +* Количество префабов должно быть около 6. +* Это точки спавна для знатных персонажей деревни (дающих задания) и лордов. +* Убедитесь, что они находятся в заметном месте деревни или в местах, где обычно находятся старейшины деревни / лорды. +* Вы можете проверить отладочное окно (Debug Window) (документация будет это рассматривать), чтобы убедиться, что вы разместили правильные позиции знатных персонажей. +* Перейдите на вкладку "Scene Entity Check Tab", включите флажок "NPCs" и посчитайте. -* Prefab: **common_area_x**. -* Each village scene has 3 Bandit Camps outside the village (place 3 prefabs), used for scene quests. -* Use the same spawns as for normal villagers (~15 per camp). Try to not have them do chores like farming. -* You can also use patrol spawnpoints: **sp_guard_patrol_simple, sp_guard_patrol”.** -* All spawn points in the radius will spawn bandits instead of villagers. -* You can increase the radius by scaling the common area prefab. -* Use civilian animation points as spawn points for bandits, some suggestions: “sp_npc_wait_wall, lookout, sp_npc_argue_set, sp_npc_wait”. -* Make sure that there is some indication to where they could be so that the player has a chance of finding them (especially at night). -* Don't place them too close to each other. +##### Лагеря бандитов (Bandit Camps) + +* Префаб: **common_area_x**. +* У каждой сцены деревни есть 3 лагеря бандитов за пределами деревни (разместите 3 префаба), используемых для квестов сцены. +* Используйте те же точки спавна, что и для обычных жителей (~15 на лагерь). Старайтесь не заставлять их выполнять такие дела, как земледелие. +* Также можно использовать точки патрулирования: **sp_guard_patrol_simple, sp_guard_patrol**. +* Все точки спавна в радиусе будут порождать бандитов вместо жителей деревни. +* Радиус можно увеличить, масштабируя префаб common area. +* Используйте гражданские точки анимации в качестве точек спавна для бандитов, вот некоторые варианты: "sp_npc_wait_wall, lookout, sp_npc_argue_set, sp_npc_wait". +* Убедитесь, что есть какой-то намёк на то, где они могут находиться, чтобы у игрока был шанс их найти (особенно ночью). +* Не размещайте их слишком близко друг к другу.  -##### Animal Spawnpoints +##### Точки спавна животных (Animal Spawnpoints) -* Prefab: **sp_animalName**. -* Use “DisableWandering” in the AnimalSpawnSettings script, to stop animals from walking around your scene. -* Overall its best to put it on all bigger animals like cows and pigs if they aren't there to wonder around. +* Префаб: **sp_animalName**. +* Используйте "DisableWandering" в скрипте AnimalSpawnSettings, чтобы животные не бродили по вашей сцене. +* В целом лучше всего применять это для всех крупных животных, таких как коровы и свиньи, если им не нужно бродить вокруг. -##### Tactical Region +##### Тактический регион (Tactical Region) -* Prefab: **TacticalRegion**. -* Used to tell the AI where there are relevant bigger regions (forests, hills etc.). -* AI will position themselves inside the radius or avoid it. -* Don't overuse it, stick to ~5 (make sure there is some variety). +* Префаб: **TacticalRegion**. +* Используется, чтобы сообщить ИИ о местах, где есть значимые крупные регионы (леса, холмы и т. д.). +* ИИ будет позиционировать себя внутри радиуса или избегать его. +* Не злоупотребляйте этим, придерживайтесь ~5 (обеспечивая некоторое разнообразие). -##### Tactical Positions +##### Тактические позиции (Tactical Positions) -* Prefab: **TacticalPosition**. -* Used to tell the AI where there are relevant smaller positions (like choke points between buildings, cliffs for archers and so on). -* AI will position themselves according to the rotation of the Prefab and in regards to the width given by the script. -* You can use them quite often. -* The higher the slope the “better” is the position. +* Префаб: **TacticalPosition**. +* Используется, чтобы сообщить ИИ о значимых небольших позициях (например, узких проходах между зданиями, обрывах для лучников и т. д.). +* ИИ будет позиционировать себя в соответствии с поворотом префаба и с учётом ширины, заданной скриптом. +* Их можно использовать довольно часто. +* Чем выше уклон, тем "лучше" позиция.  -##### Flee Positions +##### Точки бегства (Flee Positions) -* Positions to which fleeing troops and also horses will run away too. -* Make sure they are inside the Soft Border and that there is a navmesh below them. +* Позиции, к которым будут убегать отступающие войска, а также лошади. +* Убедитесь, что они находятся внутри мягкой границы (Soft Border) и что под ними есть навигационная сетка.  -#### Debug Window +#### Отладочное окно (Debug Window) -* Prefab: **SpawnPointDebugView**. -* There is a built-in debug tool which can be enabled by adding the above prefab to the scene. Place the prefab anywhere in the scene and activate the window with the check box in its script. -* This prefab opens a little debug window in the editor that helps you make sure you meet the requirements for the mission (like spawn points, navmesh). -* In the “Scene Entity Check Tab” you can count your Entry Points and make sure you have placed enough of them (or too many). -* In the “Navigation Mesh Check Tab” you can make sure all your Entry Points are connected to the navmesh properly. +* Префаб: **SpawnPointDebugView**. +* Существует встроенный инструмент отладки, который можно включить, добавив указанный выше префаб в сцену. Разместите префаб в любом месте сцены и активируйте окно с помощью флажка в его скрипте. +* Этот префаб открывает небольшое отладочное окно в редакторе, которое помогает убедиться, что вы соответствуете требованиям для миссии (например, точки спавна, навигационная сетка). +* На вкладке "Scene Entity Check Tab" вы можете посчитать свои точки входа и убедиться, что вы разместили их достаточно (или слишком много). +* На вкладке "Navigation Mesh Check Tab" вы можете убедиться, что все ваши точки входа правильно соединены с навигационной сеткой.  -#### Soft Border +#### Мягкая граница (Soft Border) -* Prefab: **border_soft**. -* They define the red borders of the scene. -* When placed they form a polygon where the 2 edges connect between the closest two border entities (but never more than two). -* To check the current borders, go into the "Visibility Window" → "Visibility Masks" and enable "Borders". -* After crossing them the player has a few seconds to return inside the map borders, make sure this can't be abused somehow. +* Префаб: **border_soft**. +* Определяют красные границы сцены. +* При размещении они образуют многоугольник, в котором 2 ребра соединяются между двумя ближайшими граничными сущностями (но никогда более чем между двумя). +* Чтобы проверить текущие границы, зайдите в "Visibility Window" → "Visibility Masks" и включите "Borders". +* После пересечения границ у игрока есть несколько секунд, чтобы вернуться внутрь границ карты, убедитесь, что этим нельзя как-либо злоупотребить.  -#### Sounds +#### Звуки -##### Master Ambient Sound +##### Основной фоновый звук (Master Ambient Sound) -* Prefab: **x_ambient_sound**. -* Choose a mandatory master ambient sound. -* You can place the prefab for the mandatory ambient sound anywhere. -* Make sure it has the “Is Master Sound” enabled. -* Make sure it doesn't have the “Is Triggered” enabled. +* Префаб: **x_ambient_sound**. +* Выберите обязательный основной (master) фоновый звук. +* Префаб для обязательного фонового звука можно разместить где угодно. +* Убедитесь, что у него включена опция "Is Master Sound". +* Убедитесь, что у него отключена опция "Is Triggered". -##### Additional Ambient sounds +##### Дополнительные фоновые звуки (Additional Ambient sounds) -* Used for bigger areas (like forests). -* Needs to have the “Is Triggered” bool. -* To see how far it reaches, from the "Visibility Window" enable "Sound Entities" under the ""Visibility Masks" group. -* To change their reach, you can scale them like you would do with other editor entities (using the “b” key or the gizmo). +* Используются для более крупных зон (например, лесов). +* Должны иметь включённый булевый параметр "Is Triggered". +* Чтобы увидеть, насколько далеко он распространяется, в окне "Visibility Window" включите "Sound Entities" в группе "Visibility Masks". +* Чтобы изменить их радиус действия, их можно масштабировать так же, как и другие сущности редактора (с помощью клавиши "b" или гизмо).  -##### Reverb +##### Реверберация (Reverb) -* There are different prefabs for each use case: **reverb_x**. -* Adds reverb effect to any sound spawned inside its boundary. -* They are generally used for tight or underground areas. -* You can place these in tight alleys between taller buildings, cliffs, in caves or in dense forests. -* Needs to have the “Is Triggered” enabled. +* Для каждого случая использования существуют разные префабы: **reverb_x**. +* Добавляет эффект реверберации к любому звуку, порождённому внутри его границ. +* Обычно используются для тесных или подземных зон. +* Их можно размещать в узких переулках между высокими зданиями, на обрывах, в пещерах или в густых лесах. +* Должны иметь включённую опцию "Is Triggered". -##### Detail +##### Детали (Detail) -* Used for small details. -* Make sure “Is Triggered” is disabled. -* Place them where ever you want them to play. +* Используются для небольших деталей. +* Убедитесь, что "Is Triggered" отключена. +* Размещайте их там, где хотите, чтобы они воспроизводились. -##### Moving sounds on paths (for rivers and such) +##### Перемещение звуков по путям (для рек и т. п.) -Sometimes it's useful to move sounds along a coast line or a river. The below technique is more performance-friendly and more precise than placing multiple sound entities along your river for example. +Иногда полезно перемещать звуки вдоль береговой линии или реки. Описанная ниже техника более производительна и точна, чем размещение множества звуковых сущностей вдоль, например, реки. -* Place a path on the river. For more information, see [Path Editing]({{< ref "path_editing.md" >}}). -* Add the sound to the scene. -* Place any additional Ambient sound as explained above. -* Add the “path_converger” script to your ambient sound's entity. -* Enter the name of your path to the "path_converger". -* The sound will now follow the path according to the camera position. +* Разместите путь (path) вдоль реки. Подробнее см. [Редактирование путей (Path Editing)]({{< ref "path_editing.md" >}}). +* Добавьте звук в сцену. +* Разместите любой дополнительный фоновый звук, как описано выше. +* Добавьте скрипт "path_converger" к сущности вашего фонового звука. +* Введите имя вашего пути в поле "path_converger". +* Теперь звук будет следовать по пути в зависимости от позиции камеры. -##### Sounds in the Engine +##### Звуки в движке -You can check the "MODDING_TOOLS_DIRECTORY/Sounds/GUIDs.txt" file for the list of the sounds in the game. These names can be used inside the script of the sound entities. +Вы можете проверить файл "MODDING_TOOLS_DIRECTORY/Sounds/GUIDs.txt" для получения списка звуков в игре. Эти имена можно использовать внутри скрипта звуковых сущностей. -#### Lights +#### Освещение (Lights) -* Have at least one “**envmap_prop**” in your scene. -* For darker areas like caves use “**local_envmap_prop**”. -* It will affect the lighting in an area depending on the values of its “ReflectionCapturer” script. -* Make sure the village and bandit camps are nicely lit. -* Take extra care for the conversation points. -* Use torches and other entities. -* Make sure torches inside buildings and other dark areas have “alwaysBurn” enabled in the LightCycle script. -* Try to avoid placing “artificial lights” without an actual source. -* You can bake the ambient lighting in your scene with the GI system. This will make the ambient lighting much more realistic. For more information, see [GI System]({{< ref "prt.md" >}}). +* Разместите в сцене хотя бы один "**envmap_prop**". +* Для тёмных зон, таких как пещеры, используйте "**local_envmap_prop**". +* Он будет влиять на освещение в зоне в зависимости от значений своего скрипта "ReflectionCapturer". +* Убедитесь, что деревня и лагеря бандитов хорошо освещены. +* Уделите особое внимание точкам разговора. +* Используйте факелы и другие сущности. +* Убедитесь, что у факелов внутри зданий и других тёмных мест включена опция "alwaysBurn" в скрипте LightCycle. +* Старайтесь избегать размещения "искусственного освещения" без реального источника. +* Вы можете запечь (bake) фоновое освещение в вашей сцене с помощью системы GI. Это сделает фоновое освещение гораздо более реалистичным. Подробнее см. [Система GI (GI System)]({{< ref "prt.md" >}}).  -#### Atmosphere +#### Атмосфера (Atmosphere) -* Make sure your scene works and looks fine with all of the “**TOD_x**” atmospheres and in all seasons! (since it will be tested with those). -* Choose a “Color Grade” that fits your scene (we suggest using the ones for the faction your scene is for, like: “color_grade_empire_soft”). +* Убедитесь, что ваша сцена работает и хорошо выглядит со всеми атмосферами "**TOD_x**" и во всех временах года! (так как она будет тестироваться именно с ними). +* Выберите "Color Grade", которая подходит вашей сцене (мы рекомендуем использовать те, что предназначены для фракции, для которой создаётся сцена, например: "color_grade_empire_soft").  - diff --git a/docs/content/russian/BestPractices/merging_module_xml_files_with_native.md b/docs/content/russian/BestPractices/merging_module_xml_files_with_native.md index 9e631673..75746777 100644 --- a/docs/content/russian/BestPractices/merging_module_xml_files_with_native.md +++ b/docs/content/russian/BestPractices/merging_module_xml_files_with_native.md @@ -1,24 +1,25 @@ +++ -title = "Merging Module XML Files with Native" +title = "Слияние XML-файлов модуля с нативными файлами" +ai_translated = true [menu.main] identifier = "merging_module_xml_files_with_native" parent = "bestpractices" +++ -With Bannerlord v1.3, we have implemented an XML merging algorithm that assists in merging XML files defined in other modules' module data without using XSLT. We can add new elements to the XMLs or change some attributes during merging, using their unique attributes and other information gathered from XSDs. Follow these steps to enable the merging algorithm: +Начиная с Bannerlord v1.3, мы реализовали алгоритм слияния XML, который помогает объединять XML-файлы, определённые в данных модулей (module data) других модулей, без использования XSLT. Во время слияния мы можем добавлять новые элементы в XML или изменять некоторые атрибуты, используя их уникальные атрибуты и другую информацию, полученную из XSD. Выполните следующие шаги, чтобы включить алгоритм слияния: -1. Create an XML file that needs to be merged with the base game -2. Add new elements with the content of the mod; they will be added to the appropriate places in the final merged XML file that is going to be used by the game -3. Change elements that are already present in the base game +1. Создайте XML-файл, который необходимо объединить с базовой игрой +2. Добавьте новые элементы с содержимым мода; они будут добавлены в соответствующие места в итоговом объединённом XML-файле, который будет использоваться игрой +3. Измените элементы, которые уже присутствуют в базовой игре -In the engine, merging of native and other modules' data is done in two ways. +В движке слияние данных нативной игры и других модулей выполняется двумя способами. -## Merging for Native +## Слияние для нативной игры (Native) -These are the XML files that start with "soln". In ModuleData, they are defined in the "project.mbproj" file. +Это XML-файлы, имена которых начинаются с "soln". В ModuleData они определяются в файле "project.mbproj". -In the following code, we can see that this module registers: +В приведённом ниже коде видно, что этот модуль регистрирует: * action_sets * action_types @@ -42,11 +43,11 @@ In the following code, we can see that this module registers: ``` -These files are automatically found by the system and merged with native. +Эти файлы автоматически обнаруживаются системой и объединяются с нативными данными. -## Managed XML Files +## Управляемые XML-файлы (Managed XML Files) -The other kind of merging is done with managed XML files such as items.xml, heroes.xml, and settlements.xml. They are defined in the SubModule.xml file located at the module's root. Here's an example of a SubModule file: +Другой вид слияния выполняется для управляемых (managed) XML-файлов, таких как items.xml, heroes.xml и settlements.xml. Они определяются в файле SubModule.xml, расположенном в корне модуля. Вот пример файла SubModule: ```xml @@ -75,9 +76,9 @@ The other kind of merging is done with managed XML files such as items.xml, hero ``` -In the above example, we have registered an XMLNode to the game with the id="Items". So when we need merging, items.xml from the base game will merge with the items.xml from the mod. The only thing that needs to be done is to implement the items.xml file as usual, and they will be merged. +В приведённом выше примере мы зарегистрировали в игре XMLNode с id="Items". Поэтому при слиянии items.xml из базовой игры будет объединён с items.xml из мода. Всё, что нужно сделать — это реализовать файл items.xml как обычно, и они будут объединены. -Let's have a look at the Torch item located in the native "items.xml": +Рассмотрим предмет Torch (факел), расположенный в нативном файле "items.xml": ```xml ``` -We can change some properties of this item by rewriting it in our own module. When the merge algorithm runs, it searches through the XML file and looks at the "unique" attributes of that element (which is "id" in this case). If a unique attribute is found, that element is changed, and if it is not found, the new item is added to the XML file. Let's say we wanted to change the above Torch item, which has the following unique attribute id: "torch". We want to make it available in shops, change its swing_damage to 9, and set the DropOnWeaponChange flag to false. We would insert the following code into our module's items.xml: +Мы можем изменить некоторые свойства этого предмета, переписав его в нашем собственном модуле. Когда запускается алгоритм слияния, он проходит по XML-файлу и просматривает "уникальные" атрибуты данного элемента (в данном случае это "id"). Если уникальный атрибут найден, этот элемент изменяется; если не найден, новый элемент добавляется в XML-файл. Предположим, мы хотим изменить указанный выше предмет Torch, у которого уникальный атрибут id равен "torch". Мы хотим сделать его доступным в магазинах, изменить его swing_damage на 9 и установить флаг DropOnWeaponChange в false. Для этого мы вставим следующий код в items.xml нашего модуля: ```xml ``` -The algorithm then searches through the items and finds an item with a unique attribute that is already present in native files. It then starts the merging process. This is the resulting item: +Затем алгоритм проходит по предметам и находит предмет с уникальным атрибутом, который уже присутствует в нативных файлах. После этого начинается процесс слияния. Вот итоговый предмет: ```xml ``` -For each XML file, there is an XSD schema file that gives information about the structure of the XML file. The XSD files are located in the XmlSchemas folder. These files also tell us which attributes of an element are unique attributes. And there are some elements where the algorithm always prefers merging. In the XML files above, if we look at the corresponding XSD schemas, we will see that for the element "Item", the unique attribute is "id", for the element "ItemComponent", we should always prefer merging because it is restricted that there is only one "ItemComponent" element for each "Item". All these information is read from the xsd files by the algorithm. For example, let's look at the xsd schema of "ShipHulls": +Для каждого XML-файла существует файл схемы XSD, который предоставляет информацию о структуре XML-файла. Файлы XSD находятся в папке XmlSchemas. Эти файлы также сообщают нам, какие атрибуты элемента являются уникальными. Кроме того, существуют элементы, для которых алгоритм всегда предпочитает слияние. В приведённых выше XML-файлах, если посмотреть на соответствующие XSD-схемы, можно увидеть, что для элемента "Item" уникальным атрибутом является "id", а для элемента "ItemComponent" всегда следует предпочитать слияние, поскольку установлено ограничение, что для каждого "Item" может быть только один элемент "ItemComponent". Вся эта информация считывается алгоритмом из xsd-файлов. Например, рассмотрим xsd-схему для "ShipHulls": ```xml @@ -244,7 +245,7 @@ For each XML file, there is an XSD schema file that gives information about the ``` -In the schema above, we can see that "xs:unique" elements tells us which attributes of the element specified with "xpath" are unique. For example lets look at: +В приведённой выше схеме видно, что элементы "xs:unique" сообщают нам, какие атрибуты элемента, указанного в "xpath", являются уникальными. Например, рассмотрим: ```xml @@ -254,7 +255,7 @@ In the schema above, we can see that "xs:unique" elements tells us which attribu ``` -This tells that, "id" attribute of an element "ShipHull" is unique. So, the merging algorithm checks this "id" field while merging. There are also some annotations that can be seen in the xsd files such as: +Это означает, что атрибут "id" элемента "ShipHull" является уникальным. Таким образом, алгоритм слияния при объединении проверяет именно это поле "id". В xsd-файлах также можно встретить некоторые аннотации, например: ```xml @@ -265,4 +266,4 @@ This tells that, "id" attribute of an element "ShipHull" is unique. So, the merg ``` -This tells us that an "AvailableSlots" element occurs only once in its parent and when the algorithm encounters an "AvailableSlots" item while modifying the parent item with merging, it knows that the "AvailableSlots" present in the other element that we are trying to merge directly merges with the existing "AvailableSlots" without resulting in two "AvailableSlots" elements. Elements that are annotated like this do not have unique id's as well because we don't need one. +Это сообщает нам, что элемент "AvailableSlots" встречается в своём родительском элементе только один раз, и когда алгоритм при слиянии родительского элемента встречает элемент "AvailableSlots", он понимает, что "AvailableSlots" в другом элементе, с которым мы пытаемся выполнить слияние, напрямую объединяется с существующим "AvailableSlots", не создавая при этом два элемента "AvailableSlots". Элементы, аннотированные таким образом, также не имеют уникальных идентификаторов, поскольку они нам не нужны. diff --git a/docs/content/russian/BestPractices/xml_editor.md b/docs/content/russian/BestPractices/xml_editor.md index 133a90a1..dcae75c7 100644 --- a/docs/content/russian/BestPractices/xml_editor.md +++ b/docs/content/russian/BestPractices/xml_editor.md @@ -1,17 +1,18 @@ +++ -title = "Getting Started with XML Editor" +title = "Начало работы с редактором XML" +ai_translated = true [menu.main] identifier = "xml_editor" parent = "bestpractices" +++ -#### Module -Bannerlord consists of different modules, which give it different functionality. You can think of them as game mods. This approach allows players to easily mod the game. The modules are inside the Mount & Blade II Bannerlord installation folder, called `Modules`. +#### Модуль +Bannerlord состоит из разных модулей, которые придают ему различную функциональность. Их можно рассматривать как игровые моды. Такой подход позволяет игрокам легко модифицировать игру. Модули находятся внутри папки установки Mount & Blade II Bannerlord, в каталоге с названием `Modules`. #### XML -XML stands for E**x**tensible **M**arkup **L**anguage, which allows the storage of data related to the game. If we want to add some data to a Module, we would create an XML document within it, or add it to an existing XML document. -#### XSD (Schema files) -XSD stands for **X**ML **S**chema **D**efinition. It allows for a validation layer for data that is provided through XML files. Each XML file in Bannerlord has a related schema file. For example, schema files provide a schema for a culture object, and it looks something like this: +XML расшифровывается как E**x**tensible **M**arkup **L**anguage (расширяемый язык разметки), который позволяет хранить данные, связанные с игрой. Если мы хотим добавить какие-то данные в модуль, мы создаём XML-документ внутри него или добавляем данные в существующий XML-документ. +#### XSD (файлы схем) +XSD расшифровывается как **X**ML **S**chema **D**efinition (определение схемы XML). Он обеспечивает уровень валидации для данных, предоставляемых через XML-файлы. Каждый XML-файл в Bannerlord имеет связанный файл схемы. Например, файлы схем определяют схему для объекта культуры, и она выглядит примерно так: - Culture - Name @@ -19,106 +20,106 @@ XSD stands for **X**ML **S**chema **D**efinition. It allows for a validation lay - Description - … -As you can see, these files are schema for how we are going to structure our XML files. 99% of the time, the XML editor prevents you from making a change that is not allowed in the schema files. If, by any chance, you make a change that makes the XML file not fit the schema file, you are going to get an error while saving the file, thus allowing you to fix your mistake. +Как видите, эти файлы являются схемой того, как мы будем структурировать наши XML-файлы. В 99% случаев редактор XML предотвращает внесение изменений, недопустимых в файлах схемы. Если вдруг вы внесёте изменение, из-за которого XML-файл перестанет соответствовать файлу схемы, при сохранении файла вы получите ошибку, что позволит вам исправить свою ошибку. #### XSLT -XSLT stands for E**x**tensible **S**tylesheet **L**anguage **T**ransformations. It allows for the transformation of existing XML files into new ones, based on the defined rules. These rules get applied to the XML files when they are being loaded into the game. +XSLT расшифровывается как E**x**tensible **S**tylesheet **L**anguage **T**ransformations (расширяемый язык преобразований таблиц стилей). Он позволяет преобразовывать существующие XML-файлы в новые на основе определённых правил. Эти правила применяются к XML-файлам при их загрузке в игру. -Example use case: Assume that we would like to make changes for some culture in the game, but they are defined in one of the official modules. We cannot directly open and edit the official module, as that change will no longer be part of our own module. +Пример использования: предположим, мы хотим внести изменения для какой-то культуры в игре, но она определена в одном из официальных модулей. Мы не можем напрямую открыть и отредактировать официальный модуль, поскольку это изменение больше не будет частью нашего собственного модуля. -Therefore, instead of changing the XML file, we create rules with XSLT inside our own module, which transform the existing XML file in the related official module. +Поэтому вместо изменения XML-файла мы создаём правила с помощью XSLT внутри нашего собственного модуля, которые преобразуют существующий XML-файл в соответствующем официальном модуле. -#### Getting Started with XML Editor -The XML Editor is a program that allows you to: +#### Начало работы с редактором XML +Редактор XML — это программа, которая позволяет вам: -- Edit your module’s XML files with schema-aware validation that prevents invalid changes. -- Safely modify official and other module data via XSLT, generating non-destructive transformation rules. - - Accomplish the above two steps through UI rather than text editors. +- Редактировать XML-файлы вашего модуля с учётом схемы (schema-aware validation), что предотвращает недопустимые изменения. +- Безопасно изменять данные официальных и других модулей с помощью XSLT, генерируя неразрушающие правила преобразования. + - Выполнять два вышеуказанных шага через UI, а не через текстовые редакторы. -You can access the XML Editor through the `Mount & Blade II: Bannerlord Modding Kit` on Steam. After installing the Kit, you’ll find the XML Editor inside the `XMLEditor` folder in the game’s root directory. +Вы можете получить доступ к редактору XML через `Mount & Blade II: Bannerlord Modding Kit` в Steam. После установки Kit вы найдёте редактор XML внутри папки `XMLEditor` в корневом каталоге игры. -Starting the XML editor for the first time, you will be asked to adjust the settings for the editor. Choose yes, and you will see the settings window. +При первом запуске редактора XML вам будет предложено настроить параметры редактора. Выберите "да", и вы увидите окно настроек. -First, you need to select your game folder. It defaults to the Steam version of the game. Other settings are optional, and you can leave them as they are. +Сначала вам нужно выбрать папку с игрой. По умолчанию используется версия игры из Steam. Остальные настройки необязательны, и вы можете оставить их как есть. -- **Game Folder**: The folder where your game is installed. If the path is not valid, you’ll get a red warning. The editor cannot function without the correct folder setup. -- **Editor Theme**: Changes the overall color for the editor and editor windows. -- **Use accent colors for windows**: Changes the window and title colors based on the accent color. -- **Disable warnings showing in the inspector**: Disables any warnings that might be shown in the inspector. Generally not recommended unless you know what you are doing. -- **Enable XSLT editing (experimental)**: Enables the XSLT editing functionality for the editor. XSLT editing works but is experimental and may not be very stable. Some features that exist on direct XML editing may not be available in the XSLT mode. +- **Game Folder (Папка игры)**: папка, в которой установлена ваша игра. Если путь недействителен, вы получите красное предупреждение. Редактор не может работать без правильно настроенной папки. +- **Editor Theme (Тема редактора)**: изменяет общую цветовую схему редактора и окон редактора. +- **Use accent colors for windows (Использовать акцентные цвета для окон)**: изменяет цвета окон и заголовков на основе акцентного цвета. +- **Disable warnings showing in the inspector (Отключить отображение предупреждений в инспекторе)**: отключает любые предупреждения, которые могут отображаться в инспекторе. Обычно не рекомендуется, если вы не уверены в том, что делаете. +- **Enable XSLT editing (experimental) (Включить редактирование XSLT (экспериментально))**: включает функциональность редактирования XSLT для редактора. Редактирование XSLT работает, но является экспериментальным и может быть не очень стабильным. Некоторые функции, доступные при прямом редактировании XML, могут быть недоступны в режиме XSLT. -The editor configuration file is saved directly next to the Bannerlord configuration file folder - `Documents\Mount and Blade II Bannerlord\Configs\xml_editor_config.json`. If any problem occurs with your settings, you can always delete the configuration file and restart the editor, which will recreate the settings file. +Файл конфигурации редактора сохраняется прямо рядом с папкой конфигурационного файла Bannerlord — `Documents\Mount and Blade II Bannerlord\Configs\xml_editor_config.json`. Если с вашими настройками возникнет какая-либо проблема, вы всегда можете удалить файл конфигурации и перезапустить редактор, который заново создаст файл настроек. -You can access settings from the main window toolbar, `File` -> `Settings`, or by choosing the `Change Settings` option inside the Module Selection Window. +Вы можете получить доступ к настройкам из панели инструментов главного окна, `File` -> `Settings`, или выбрав опцию `Change Settings` в окне выбора модуля. -After confirming your settings, click the `Save and Close` button. You’ll be navigated to the Module Selection window. -##### What is an Active Module? -An active module is used to describe your intent to the editor. It allows the editor to choose between directly editing the XML file or creating a rule by creating an XSLT file. +После подтверждения настроек нажмите кнопку `Save and Close`. Вы перейдёте в окно выбора модуля. +##### Что такое активный модуль? +Активный модуль используется для описания редактору ваших намерений. Он позволяет редактору выбирать между прямым редактированием XML-файла или созданием правила путём создания файла XSLT. -In the module selection window, you are going to see modules that are located in the game folder that you have chosen. From here, you want to select the module that you want your work to be part of. XML Editor only supports direct editing of your or third-party modules. If you want to modify the values of the official modules, you’ll need to select your mod as active and use XSLT editing to edit official modules. -#### Editor Interface and Editing XML Files -After choosing the module that you want to work on, you are going to be greeted with the XML editor. In our case, we’ve chosen an empty mod that only has an `items.xml` file related to it. +В окне выбора модуля вы увидите модули, расположенные в выбранной вами папке игры. Отсюда вы хотите выбрать модуль, частью которого должна быть ваша работа. Редактор XML поддерживает только прямое редактирование ваших собственных или сторонних модулей. Если вы хотите изменить значения официальных модулей, вам нужно выбрать свой мод как активный и использовать редактирование XSLT для редактирования официальных модулей. +#### Интерфейс редактора и редактирование XML-файлов +После выбора модуля, с которым вы хотите работать, перед вами откроется редактор XML. В нашем случае мы выбрали пустой мод, у которого есть только файл `items.xml`. -To quickly go over the starting interface; +Чтобы быстро пройтись по начальному интерфейсу: -- At the top, you can see the editor toolbar. You can access some quick operations from here, like reloading the editor or opening some additional editor windows, like the dependency editor. -- The center part is your main editor. Currently, it is displaying the schema files that are related to the game. Selecting any of the schemas will show you related XML files to that schema. -- At the bottom, there is an active module selection button. It shows you which module is currently active, and if you want, you can click on it to change your active module. Changing the active module will reload the editor. +- Вверху вы видите панель инструментов редактора. Отсюда вы можете получить доступ к некоторым быстрым операциям, например перезагрузке редактора или открытию дополнительных окон редактора, таких как редактор зависимостей. +- Центральная часть — это ваш основной редактор. В настоящий момент он отображает файлы схем, связанные с игрой. Выбор любой из схем покажет вам связанные с этой схемой XML-файлы. +- Внизу находится кнопка выбора активного модуля. Она показывает, какой модуль в данный момент активен, и при желании вы можете нажать на неё, чтобы изменить активный модуль. Изменение активного модуля перезагрузит редактор. -Since our example mod only has an `items.xml` which is related to the Items schema, we will continue our guide by selecting the Items schema. +Поскольку наш пример мода содержит только `items.xml`, связанный со схемой Items, мы продолжим наше руководство, выбрав схему Items. -Selecting a schema opens us to the document explorer window. The document explorer shows us every XML file that is related to the selected schema. You can also create a new XML document for the selected module and schema. The names of these files are shown as `[Module Name].[Xml Name]`. Let’s continue with selecting the Example Mod.items file. +Выбор схемы открывает окно обозревателя документов. Обозреватель документов показывает все XML-файлы, связанные с выбранной схемой. Вы также можете создать новый XML-документ для выбранного модуля и схемы. Названия этих файлов отображаются как `[Module Name].[Xml Name]`. Продолжим, выбрав файл Example Mod.items. -Once we select the target document, we are greeted with the `Element Explorer` window, which shows us the top-level elements in our XML file. You can compare the Element Explorer with the exact same document screenshot we’ve added below to help you understand exactly what you are seeing. On the bottom, you can see a button to create new top-level elements and the save button for the file to save your changes. +После выбора целевого документа перед нами открывается окно `Element Explorer` (Обозреватель элементов), которое показывает нам элементы верхнего уровня в нашем XML-файле. Вы можете сравнить обозреватель элементов с тем же самым скриншотом документа, который мы добавили ниже, чтобы помочь вам понять именно то, что вы видите. Внизу вы увидите кнопку для создания новых элементов верхнего уровня и кнопку сохранения файла для сохранения ваших изменений. -To edit one of these elements, you can click on the element in the Element Explorer window. This will open us to our final window, the `Inspector Window`. Inspector Window allows you to see all the attributes and child elements that are related to the selection in the Element Explorer window. +Чтобы отредактировать один из этих элементов, вы можете нажать на элемент в окне обозревателя элементов. Это откроет наше последнее окно — `Inspector Window` (окно инспектора). Окно инспектора позволяет вам увидеть все атрибуты и дочерние элементы, связанные с выбором в окне обозревателя элементов. -In the Inspector Window, every dropdown represents an XML element. You can do element-related changes by clicking on the cogwheel icon next to the element that you want to apply changes to. You can make changes like creating a child element or deleting the selected element. +В окне инспектора каждый выпадающий список представляет собой XML-элемент. Вы можете выполнять изменения, связанные с элементами, нажимая на значок шестерёнки рядом с элементом, к которому вы хотите применить изменения. Вы можете вносить такие изменения, как создание дочернего элемента или удаление выбранного элемента. -Under each dropdown, you can see fields being displayed. These fields are attributes of the XML element. `Undefined` means that the attribute does not exist. It’s marked this way to make sure we can differentiate between empty values and attributes that don’t have a value. Right-clicking on fields will also show you some options, like removing attributes from the element. +Под каждым выпадающим списком вы увидите отображаемые поля. Эти поля являются атрибутами XML-элемента. `Undefined` означает, что атрибут не существует. Это отмечено таким образом, чтобы мы могли различать пустые значения и атрибуты, у которых нет значения. Щелчок правой кнопкой мыши по полям также покажет вам некоторые опции, например удаление атрибутов из элемента. -The fields in the XML editor are smart. They try to show appropriate fields, like a checkbox for a boolean field, and fall back to a text field. They also check the requirements from the schema file and warn you if there are any problems. Fields with `Required` marked next to them are required by the schema file. If the new file is not compatible with the schema file, or a required field is missing, it will prevent you from saving the file. You’ll be displayed with appropriate errors so that you can fix them. +Поля в редакторе XML являются интеллектуальными. Они стараются отображать подходящие поля, например флажок для булевого поля, и переключаются на текстовое поле, если это не подходит. Они также проверяют требования из файла схемы и предупреждают вас, если есть какие-либо проблемы. Поля, рядом с которыми отмечено `Required` (обязательно), требуются файлом схемы. Если новый файл несовместим с файлом схемы или отсутствует обязательное поле, это предотвратит сохранение файла. Вам будут показаны соответствующие ошибки, чтобы вы могли их исправить. -After making changes, make sure to click the save button. It’s also important to note that there is no element-level save feature. Once you make changes, you need to save the entire document. +После внесения изменений обязательно нажмите кнопку сохранения. Также важно отметить, что функции сохранения на уровне элемента не существует. После внесения изменений вам нужно сохранить весь документ. -#### Editing Official Modules using XSLT -To edit official modules, you need to enable the XSLT editing mode. Open the settings window from `File` -> `Settings`, and make sure the `Enable XSLT editing` box is checked. Once that is done, if we click on any schema file, we are also going to see related XML files from other modules. We can differentiate the XSLT editing by the yellow warning icon on the right side of the XML file. +#### Редактирование официальных модулей с помощью XSLT +Чтобы редактировать официальные модули, вам нужно включить режим редактирования XSLT. Откройте окно настроек через `File` -> `Settings` и убедитесь, что флажок `Enable XSLT editing` установлен. После этого, если мы нажмём на любой файл схемы, мы также увидим связанные XML-файлы из других модулей. Мы можем отличить редактирование XSLT по жёлтому значку предупреждения справа от XML-файла. -For demo purposes, we will continue by selecting the `mpitems` file, which is part of the Native module of the game. +В демонстрационных целях мы продолжим, выбрав файл `mpitems`, который является частью модуля Native игры. -We can now see the elements that are part of the `Native.mpitems` file. One thing to note here is that XSLT editing does not support deleting an element. Instead, we can replace the element with an empty one. Let’s continue by choosing an element to edit. +Теперь мы можем видеть элементы, являющиеся частью файла `Native.mpitems`. Здесь стоит отметить, что редактирование XSLT не поддерживает удаление элемента. Вместо этого мы можем заменить элемент на пустой. Продолжим, выбрав элемент для редактирования. -We’ve chosen the `mp_pointed_skullcap_over_cloth_headwrap` item. You can see that there is an error in the inspector preventing us from making any edits. That is because to make XSLT edits, our module needs to be dependent on the target module, Native, in this case. We can quickly fix this error by heading over to the `Window` -> `Dependency Editor`. +Мы выбрали предмет `mp_pointed_skullcap_over_cloth_headwrap`. Вы можете увидеть, что в инспекторе есть ошибка, препятствующая внесению каких-либо изменений. Это происходит потому, что для внесения изменений через XSLT наш модуль должен зависеть от целевого модуля, в данном случае Native. Мы можем быстро исправить эту ошибку, перейдя в `Window` -> `Dependency Editor`. -`Dependency Editor` allows us to edit the dependencies of our module. On the left side, we see modules that we are not dependent upon. We can click on a module on the left and add it as a dependency. We will choose Native, since mpitems is part of the Native, and then choose `Add Dependency`. In the end, it will look like this: +`Dependency Editor` (редактор зависимостей) позволяет нам редактировать зависимости нашего модуля. Слева мы видим модули, от которых мы не зависим. Мы можем нажать на модуль слева и добавить его как зависимость. Мы выберем Native, поскольку mpitems является частью Native, а затем выберем `Add Dependency`. В итоге это будет выглядеть так: -We can now close the Dependency Editor and return to the Inspector. You’ll see that the error is gone, and there is only a warning, telling us that we are using XSLT and not direct XML editing. We can ignore this warning. +Теперь мы можем закрыть редактор зависимостей и вернуться к инспектору. Вы увидите, что ошибка исчезла, и осталось только предупреждение, сообщающее нам, что мы используем XSLT, а не прямое редактирование XML. Это предупреждение можно игнорировать. -Our setup is done, and we can continue editing the element just like we are editing some other XML element. On the backend, the editor will be translating these changes to XSLT. You can find the resulting XSLT files directly under your module’s `ModuleData` folder, in a folder called `XSLT`. Note that some functionality in the XML editing may not be available in the XSLT editing mode. \ No newline at end of file +Наша настройка завершена, и мы можем продолжать редактировать элемент так же, как мы редактировали бы любой другой XML-элемент. В фоновом режиме редактор будет переводить эти изменения в XSLT. Результирующие файлы XSLT вы можете найти непосредственно в папке `ModuleData` вашего модуля, в папке с названием `XSLT`. Обратите внимание, что некоторая функциональность, доступная при редактировании XML, может быть недоступна в режиме редактирования XSLT. diff --git a/docs/content/russian/Editor/Resource Editors/cloth_simulation.md b/docs/content/russian/Editor/Resource Editors/cloth_simulation.md index bb2cc72a..09245127 100644 --- a/docs/content/russian/Editor/Resource Editors/cloth_simulation.md +++ b/docs/content/russian/Editor/Resource Editors/cloth_simulation.md @@ -1,125 +1,126 @@ +++ -title = "Cloth Simulation" +title = "Симуляция ткани" +ai_translated = true [menu.main] identifier = "cloth_simulation" parent = "core_components" +++ -## Preparing Mesh -Cloth simulation system uses alpha channels of vertices of meshes. Values in the alpha channel represents how much a vertex can move away from its original position. 0.1 of alpha means vertex can be moved 0.1 units from its original position by cloth simulation. If you set zero to alpha value that means that vertex will be fixed to its position and will not be updated by simulation. +## Подготовка меша +Система симуляции ткани использует альфа-каналы вершин мешей. Значения в альфа-канале показывают, насколько сильно вершина может отклониться от своего исходного положения. Значение альфа 0,1 означает, что вершина может быть смещена на 0,1 единицы от исходного положения в результате симуляции ткани. Если установить для альфа-значения ноль, это означает, что вершина будет зафиксирована в своей позиции и не будет обновляться симуляцией. | Shaded | Vertex Alpha | | ------ | ------------ | |  |  | -Black parts are driven by skinning system while white parts are simulated. It is worth to mention that skinning calculations are done for all vertices whether they are fixed or not. Positions of skinned vertices are used as anchor points for simulated vertices. You can imagine that a simulated vertex can only move inside a sphere with radius R and center C. Here alpha channel of the vertex color is used as radius and skinned position is used as center. +Чёрные участки управляются системой скиннинга, в то время как белые участки симулируются. Стоит отметить, что расчёты скиннинга выполняются для всех вершин, независимо от того, зафиксированы они или нет. Позиции скиннингованных вершин используются как опорные точки (anchor points) для симулируемых вершин. Можно представить, что симулируемая вершина может перемещаться только внутри сферы с радиусом R и центром C. Здесь альфа-канал цвета вершины используется как радиус, а позиция после скиннинга — как центр. | Shaded | Vertex Alpha | | ------ | ------------ | |  |  | -## Simulation Types -### Direct simulation -In direct simulation, vertices of rendered mesh are simulated directly by cloth simulation. This technique can be used for meshes with simple topology(like grid) and small amount of vertices. As the number of vertices increases performance hit of simulation will be greater. +## Типы симуляции +### Прямая симуляция (Direct simulation) +При прямой симуляции вершины отрисовываемого меша симулируются напрямую системой симуляции ткани. Эта техника может использоваться для мешей с простой топологией (например, сетка) и небольшим количеством вершин. По мере увеличения количества вершин нагрузка на производительность от симуляции будет расти. -### Mapped simulation -In some cases, your mesh may not be suitable for cloth simulation. Some examples are armors with double sided polygons, clothes with more than one layer or meshes with high numbers of polygons. For such cases a separate mesh can be used for simulation. If a separate simulation mesh is used vertices of this mesh are simulated by cloth simulation. Vertices of original mesh will be mapped to simulated mesh and move with them. +### Маппированная симуляция (Mapped simulation) +В некоторых случаях ваш меш может не подходить для симуляции ткани. Примеры: доспехи с двусторонними полигонами, одежда с более чем одним слоем или меши с большим количеством полигонов. Для таких случаев можно использовать отдельный меш для симуляции. Если используется отдельный симуляционный меш, вершины именно этого меша симулируются системой симуляции ткани. Вершины исходного меша будут замаплены (mapped) на симулируемый меш и будут перемещаться вместе с ним.   -In the above images, meshes on the right side are used for simulation and the left ones are rendered according to simulated results. -To achieve realistic results, your simulation mesh should tightly map to render mesh and it must never cover it. In other words, render mesh should never penetrate to simulation mesh. If it does, since collision calculations are done for simulation mesh you may see collision artifacts like penetrating leg to armor. +На изображениях выше меши справа используются для симуляции, а меши слева отрисовываются в соответствии с результатами симуляции. +Чтобы добиться реалистичных результатов, ваш симуляционный меш должен плотно соответствовать отрисовываемому мешу и никогда не должен его покрывать. Другими словами, отрисовываемый меш никогда не должен проникать внутрь симуляционного меша. Если это происходит, поскольку расчёты коллизий выполняются для симуляционного меша, вы можете увидеть артефакты коллизий, например, ногу, проникающую сквозь доспех. -## Cloth Editor -To enable cloth simulation for a mesh some ingame settings must be adjusted. Cloth editor is used to setup a mesh for simulation. Cloth editor can be opened from toolbar menu in editor. +## Редактор ткани (Cloth Editor) +Чтобы включить симуляцию ткани для меша, необходимо настроить некоторые игровые параметры. Редактор ткани используется для настройки меша для симуляции. Редактор ткани можно открыть из меню панели инструментов редактора.  -### Preview properties -#### Preview mesh -To start working with a mesh you should select it from Preview mesh menu and select the sub meshes which will be simulated from Render mesh cloth properties panel. If alpha channels of mesh painted properly it should start to be simulated on the preview window. +### Свойства предпросмотра (Preview properties) +#### Preview mesh (меш предпросмотра) +Чтобы начать работу с мешем, выберите его в меню Preview mesh и выберите подмеши, которые будут симулироваться, на панели свойств ткани отрисовываемого меша (Render mesh cloth properties). Если альфа-каналы меша правильно прокрашены, симуляция должна начаться в окне предпросмотра. -#### Simulation mesh -If you want to use a separate simulation mesh, select it from Simulation mesh menu. Alpha channel of this mesh must also be painted because it is the actual mesh being simulated. In this case alpha channel of preview mesh is used to determine if a vertex will be mapped to the simulation mesh or it will be rendered with original skinning data. Alpha values greater than zero means that vertex must be mapped to simulation mesh. Vertices with zero alpha values will use the original skinning data. Since simulation mesh has less polygon count than the original mesh, this can be used to increase skinning quality of original mesh for non-simulated parts. +#### Simulation mesh (симуляционный меш) +Если вы хотите использовать отдельный симуляционный меш, выберите его в меню Simulation mesh. Альфа-канал этого меша также должен быть прокрашен, так как именно этот меш фактически симулируется. В этом случае альфа-канал меша предпросмотра используется, чтобы определить, будет ли вершина замаплена на симуляционный меш или будет отрисовываться с использованием исходных данных скиннинга. Значения альфа больше нуля означают, что вершина должна быть замаплена на симуляционный меш. Вершины с нулевым значением альфа будут использовать исходные данные скиннинга. Поскольку симуляционный меш имеет меньшее количество полигонов, чем исходный меш, это можно использовать для повышения качества скиннинга исходного меша для несимулируемых частей. -#### Helper mesh -You can select a helper mesh to preview your actual simulation mesh with an arbitrary mesh. Selecting a horse mesh for a simulated mane mesh is a good example. +#### Helper mesh (вспомогательный меш) +Вы можете выбрать вспомогательный меш, чтобы предпросматривать ваш фактический симуляционный меш с помощью произвольного меша. Хороший пример — выбор меша лошади для симулируемого меша гривы. -#### Preview skeleton -If you want to work on a skinned mesh and preview collision capsules and animations, you should select corresponding skeleton. +#### Preview skeleton (скелет предпросмотра) +Если вы хотите работать со скиннингованным мешем и просматривать коллизионные капсулы и анимации, выберите соответствующий скелет. -#### Preview body -You can assign an existing collision body to your Preview mesh with Preview body menu. Modification of collision bodies can be done from Cloth Bodies panel. +#### Preview body (тело предпросмотра) +Вы можете назначить существующее коллизионное тело вашему мешу предпросмотра через меню Preview body. Изменение коллизионных тел можно выполнить на панели Cloth Bodies. -#### Preview animation name -You can test your cloth with an animation. You must write its name in asset folder, not the one in animations*.xml and its start and end frame numbers and duration. You can start and stop animation with Toggle Animation button. +#### Preview animation name (имя анимации предпросмотра) +Вы можете протестировать вашу ткань с анимацией. Необходимо указать её имя в папке asset, а не то, что указано в animations*.xml, а также номера начального и конечного кадра и длительность. Запускать и останавливать анимацию можно кнопкой Toggle Animation. -#### Scene update coef -Slow motion can be simulated by decreasing this value. Default value is 1 which means all simulations are done normally. +#### Scene update coef (коэффициент обновления сцены) +Эффект замедленной съёмки можно симулировать, уменьшая это значение. Значение по умолчанию — 1, что означает, что все симуляции выполняются в нормальном режиме. -#### Render mesh cloth properties -You can select which submeshes will be simulated by checking checkbox next to each submesh. -Different cloth materials can be assigned to each submesh by Cloth material column. Max distance multiplier is used to scale vertex color paintings of mesh which controls how much a vertex can move away from its original position. 0.5 value of vertex alpha with 3.0 max distance multiplier value means that, that vertex can move 1.5 units away from its original position. +#### Render mesh cloth properties (свойства ткани отрисовываемого меша) +Вы можете выбрать, какие подмеши будут симулироваться, установив флажок рядом с каждым подмешем. +Разным подмешам можно назначить разные материалы ткани через столбец Cloth material. Параметр Max distance multiplier используется для масштабирования прокрашенных значений цвета вершин, которые определяют, насколько далеко вершина может сместиться от своей исходной позиции. Значение альфа вершины 0,5 при значении Max distance multiplier 3,0 означает, что эта вершина может сместиться на 1,5 единицы от своей исходной позиции. \\ -If you are using a separate simulation mesh, max distance value and cloth material of simulation mesh overrides these settings. All submeshes will use same cloth material assigned to simulation mesh. +Если вы используете отдельный симуляционный меш, значение max distance и материал ткани симуляционного меша переопределяют эти настройки. Все подмеши будут использовать тот же материал ткани, что назначен симуляционному мешу. -#### Simulation mesh cloth properties -If you use a separate simulation mesh, you can adjust its settings from here just like render mesh properties mentioned above. Cloth material and max distance value selected here will be used for all sub meshes of render mesh. +#### Simulation mesh cloth properties (свойства ткани симуляционного меша) +Если вы используете отдельный симуляционный меш, вы можете настроить его параметры здесь так же, как и свойства отрисовываемого меша, упомянутые выше. Материал ткани и значение max distance, выбранные здесь, будут использоваться для всех подмешей отрисовываемого меша. {{% notice warning %}} -It is important to note that you must save your settings by pressing Save mesh settings button. +Важно отметить, что вы должны сохранить свои настройки, нажав кнопку Save mesh settings. {{% /notice %}} -### Collision Bodies -Collision presets can be created and modified from Collision bodies window. You can open Collision bodies window from Edit > Edit collision bodies menu. +### Коллизионные тела (Collision Bodies) +Пресеты коллизий можно создавать и изменять в окне Collision bodies. Открыть окно Collision bodies можно через меню Edit > Edit collision bodies.  -A capsule consists of two end points. These points can be skinned to a skeleton separately by assigning owner bones and weights. One capsule point can be skinned to at most two bones. Like mesh skinning, weights are used to determine influence of that bone on the selected capsule. +Капсула состоит из двух конечных точек. Эти точки можно скиннинговать на скелет отдельно, назначая им кости-владельцы (owner bones) и веса. Одна точка капсулы может быть привязана максимум к двум костям. Как и при скиннинге меша, веса определяют степень влияния этой кости на выбранную капсулу. -### Cloth materials -All simulation parameters to customize cloth behaviour is supplied with cloth materials. Cloth material presets can be created and modified from Material templates window. +### Материалы ткани (Cloth materials) +Все параметры симуляции для настройки поведения ткани задаются материалами ткани. Пресеты материалов ткани можно создавать и изменять в окне Material templates.  -You can open this window from Edit > Edit merial templates menu. -Materials shown in this windows are presets so changing these presets does not affect configurations of existing cloth meshes. To change parameters of an existing cloth mesh, you can click Change parameters button in Simulation/Render mesh properties panel and adjust each settings in Mesh specific parameters window. +Открыть это окно можно через меню Edit > Edit merial templates. +Материалы, показанные в этом окне, являются пресетами, поэтому изменение этих пресетов не влияет на конфигурации уже существующих мешей ткани. Чтобы изменить параметры существующего меша ткани, нажмите кнопку Change parameters на панели свойств симуляционного/отрисовываемого меша и настройте каждый параметр в окне Mesh specific parameters.   -Current parameters are as follows: +Текущие параметры следующие: -#### Bending, Stretching, Shearing, Stiffness -Determines how much a fabric constraint will resist to the corresponding case. +#### Bending, Stretching, Shearing, Stiffness (изгиб, растяжение, сдвиг, жёсткость) +Определяет, насколько сильно ограничение ткани будет сопротивляться соответствующему воздействию. -#### Anchor Stiffness -This constraint strictly limits the freedom of a vertex. It tries to keep distances constant between simulated and fixed vertices. You can try to increase this value if your mesh stretches too much. +#### Anchor Stiffness (жёсткость привязки) +Это ограничение строго лимитирует свободу вершины. Оно пытается сохранять постоянное расстояние между симулируемыми и фиксированными вершинами. Вы можете попробовать увеличить это значение, если ваш меш слишком сильно растягивается. -#### Damping -Dampening values for vertices. Determines the fraction of current frame's velocity to transfer to the next frame. +#### Damping (демпфирование) +Значения демпфирования для вершин. Определяют долю скорости текущего кадра, которая переносится на следующий кадр. -#### Linear Inertia -Since our cloth simulation is done in local space, global frame changes are transferred to cloth virtually. This value determines how much of acceleration of entity will be transferred to cloth. You can test this by adding a cloth mesh into a scene and shake its entity randomly. +#### Linear Inertia (линейная инерция) +Поскольку наша симуляция ткани выполняется в локальном пространстве, глобальные изменения кадра передаются ткани виртуально. Это значение определяет, какая часть ускорения сущности будет передана ткани. Вы можете протестировать это, добавив меш ткани в сцену и случайным образом потрясти его сущность. -#### Air drag -For a cloth mesh moving with a constant velocity this value determines how much air force will affect its vertices. +#### Air drag (сопротивление воздуха) +Для меша ткани, движущегося с постоянной скоростью, это значение определяет, насколько сильно сила воздуха будет влиять на его вершины. -#### Wind -You can control how much wind force the cloth will use. This value is a multiplier for actual wind force of scene. If there is no wind in the scene increasing this value has no effect. +#### Wind (ветер) +Вы можете контролировать, насколько сильно сила ветра будет воздействовать на ткань. Это значение является множителем для фактической силы ветра в сцене. Если в сцене нет ветра, увеличение этого значения не даст эффекта. -#### Gravity -Constant gravity force affecting each simulated vertex. You can decrease this value to achieve a silky cloth behaviour. +#### Gravity (гравитация) +Постоянная сила гравитации, воздействующая на каждую симулируемую вершину. Вы можете уменьшить это значение, чтобы добиться шелковистого поведения ткани. -#### Iteration Frequency -How many times a cloth mesh will be simulated in a second. You can leave this parameter with its default value unless your mesh has big triangles or it moves so fast that collision capsules can not catch simulated vertices. Increasing this value results in more stable collision behaviour but performance hit also increases linearly. +#### Iteration Frequency (частота итераций) +Сколько раз меш ткани будет симулироваться в секунду. Это значение можно оставить по умолчанию, если только ваш меш не имеет крупных треугольников или не движется настолько быстро, что коллизионные капсулы не успевают "поймать" симулируемые вершины. Увеличение этого значения приводит к более стабильному поведению коллизий, но нагрузка на производительность также растёт линейно. -#### Precise Simulation -We trade accuracy with performance by doing some compressions during simulation. As a result simulated mesh might move to a different state than its rest state slightly. If this accuracy is important for your mesh, you can enable this option to get more correct results. +#### Precise Simulation (точная симуляция) +Мы жертвуем точностью ради производительности, применяя некоторые сжатия во время симуляции. В результате симулируемый меш может немного отклоняться от своего состояния покоя. Если точность важна для вашего меша, вы можете включить эту опцию для получения более корректных результатов. -#### Dummy Collision Particles -If simulated mesh has big triangle sizes with respect to collision capsules, capsules may not collide with cloth mesh properly. To overcome this we place dummy vertices in every triangle of mesh. These vertices are not simulated but only used during collision stage. This option has big performance hit so you should avoid enabling this as much as possible. +#### Dummy Collision Particles (фиктивные частицы коллизии) +Если симулируемый меш имеет крупные треугольники относительно коллизионных капсул, капсулы могут некорректно сталкиваться с мешем ткани. Чтобы решить эту проблему, мы размещаем фиктивные вершины в каждом треугольнике меша. Эти вершины не симулируются, а используются только на этапе коллизии. Эта опция сильно влияет на производительность, поэтому её следует включать как можно реже. -## Cloth Content Files -Our simulation system generates two files with *.tcc and *.tcm extensions. -Tcc files contains preprocessed data used by cloth simulation like constraint indices, constraint lengths etc. -Tcm files contains mapping data of a render mesh to a simulation mesh. -You must commit both these files to Plastic SCM to ensure that nobody will wait for cooking process to complete during scene loading stage. \ No newline at end of file +## Файлы контента ткани (Cloth Content Files) +Наша система симуляции генерирует два файла с расширениями *.tcc и *.tcm. +Файлы Tcc содержат предварительно обработанные данные, используемые симуляцией ткани, такие как индексы ограничений, длины ограничений и т. д. +Файлы Tcm содержат данные маппинга отрисовываемого меша на симуляционный меш. +Вы обязательно должны закоммитить оба этих файла в Plastic SCM, чтобы никому не приходилось ждать завершения процесса компиляции (cooking) при загрузке сцены. diff --git a/docs/content/russian/Editor/Resource Editors/decals.md b/docs/content/russian/Editor/Resource Editors/decals.md new file mode 100644 index 00000000..28f360a0 --- /dev/null +++ b/docs/content/russian/Editor/Resource Editors/decals.md @@ -0,0 +1,32 @@ ++++ +title = "Декали" +ai_translated = true + +[menu.main] +identifier = "decal" +parent = "core_components" ++++ + +## Что такое декаль? + +Декали — это способ проецирования материалов на другую геометрию. Они могут влиять на следующие каналы PBR-конвейера затенения: Albedo, Normal, Specular, Gloss и Occlusion. Таким образом, они изменяют конечный внешний вид других мешей и материалов. Их можно использовать для добавления разнообразия в сцену, например, грязи, слякоти, мха. Также это полезный инструмент для устранения повторяющихся текстурных тайлов на мешах. Их проекционная геометрия — кубы, и проекция выполняется в направлении оси Z. + +## Как настроить материал декали? + +Прежде всего, шейдер материала должен быть "Decal". Diffuse, NormalMap и SpecularMap можно установить на любую текстуру. Модель затенения будет такой же, как у "pbr_metallic". + + +#### Флаги шейдера материала + +Флаги шейдера материала определяют, какие свойства затенения будут использоваться, и типы объектов, на которых декаль будет видна. Примечание: флаг "use_albedo" обязателен. Типичный пример материала декали, который будет виден на всех материалах, показан ниже. + + +#### Обязательные настройки на вкладке 'Others' + +Чтобы декаль отображалась корректно, флаги "Cull Front Faces" и "Don't Modify Depth Buffer" должны быть включены. + + +## Как настроить префаб декали? + +Чтобы создать сущность/префаб декали, нужно добавить специальный меш (Decal Mesh) к пустой сущности. Затем материал этого меша нужно изменить на материал, подготовленный в первом разделе. Наконец, в разделе Components/Meta Mesh/Custom Mesh Parameters следует соответствующим образом задать значения UV Scale X/Y. Для обычной текстуры оба значения должны быть равны 1. Для текстуры типа атлас значения UV Scale и UV Offset должны быть установлены так, чтобы фокусироваться на нужной позиции текстуры внутри атласа. + diff --git a/docs/content/russian/Editor/Scene Editor/alignment_and_snapping.md b/docs/content/russian/Editor/Scene Editor/alignment_and_snapping.md index faf12ce6..7be4d258 100644 --- a/docs/content/russian/Editor/Scene Editor/alignment_and_snapping.md +++ b/docs/content/russian/Editor/Scene Editor/alignment_and_snapping.md @@ -1,78 +1,79 @@ +++ -title = "Alignment and Snapping Tools" +title = "Инструменты выравнивания и привязки" +ai_translated = true [menu.main] identifier = "alignment_and_snapping" parent = "core_components" +++ -## Pivot Alignment Tool -The Pivot alignment tool applies the chosen transform values of one entity to another entity. The tool makes it easier for users to create overlapping or precisely aligned entities. -If an entitity is selected in the editor, the user can set up the alignment tool by pressing Alt + A. This will register the currently selected entity as the input entity. Selecting a second entity with the left mouse button, will then open the interface screen of the alignment tool. +## Инструмент выравнивания по опорной точке (Pivot Alignment Tool) +Инструмент выравнивания по опорной точке (Pivot alignment tool) применяет выбранные значения трансформации одного объекта к другому объекту. Этот инструмент облегчает пользователям создание перекрывающихся или точно выровненных объектов. +Если объект выбран в редакторе, пользователь может настроить инструмент выравнивания, нажав Alt + A. Это зарегистрирует текущий выбранный объект в качестве входного объекта. Выбор второго объекта с помощью левой кнопки мыши затем откроет экран интерфейса инструмента выравнивания.  -(Pivot Alignment Tool User Interface) +(Пользовательский интерфейс инструмента выравнивания по опорной точке) -* Translation checkboxes will translate first entity on the given axis/axes. -* Rotation checkboxes will rotate the first entity without breaking the local scale. Up, side and forward vectors will be aligned depending on the checkboxes. -* If the scale checkboxes are checked, first entity’s scale component of the selected axis or axes will be set as second entity’s scale value which is shown at the inspector. -* If checkboxes are unchecked, first entity will be transformed to its initial frame. -* Align by Pivot button will apply the alignment depending on the active checkboxes and close the interface. -* Revert and Close button will transform the entity to its initial frame and revert any transform operation applied to pivot. +* Флажки Translation (перемещение) переместят первый объект по заданной оси/осям. +* Флажки Rotation (вращение) повернут первый объект, не нарушая локальный масштаб. Векторы вверх, в сторону и вперёд будут выровнены в зависимости от установленных флажков. +* Если установлены флажки scale (масштаб), компонент масштаба первого объекта по выбранной оси или осям будет установлен равным значению масштаба второго объекта, которое отображается в инспекторе. +* Если флажки сняты, первый объект будет преобразован в его исходный кадр (frame). +* Кнопка Align by Pivot (Выровнять по опорной точке) применит выравнивание в зависимости от активных флажков и закроет интерфейс. +* Кнопка Revert and Close (Отменить и закрыть) преобразует объект в его исходный кадр и отменит любую операцию трансформации, применённую к опорной точке. -### Example Usage +### Пример использования  -(Initial position of bowl and candle) +(Исходное положение миски и свечи)  -(Pivot alignment in only y-orientation) +(Выравнивание по опорной точке только по оси Y)  -(Complete pivot alignment) +(Полное выравнивание по опорной точке) -## Surface Snapping Feature -The Surface Snapping Feature allows a user to snap an entity's pivot to the surface of another entity. Holding down the I hot-key continuously snaps the pivot of the currently selected entity to a surface that the mouse cursor intersects with. - Control + Z reverts the transformation. This feature aligns the entity’s local y vector with the intersection point’s normal map, so it won’t require the user to make additional adjustments to align the entity with the surface. +## Функция привязки к поверхности (Surface Snapping Feature) +Функция привязки к поверхности (Surface Snapping Feature) позволяет пользователю привязать опорную точку объекта к поверхности другого объекта. Удержание горячей клавиши I непрерывно привязывает опорную точку текущего выбранного объекта к поверхности, которую пересекает курсор мыши. +Control + Z отменяет трансформацию. Эта функция выравнивает локальный вектор Y объекта с нормалью точки пересечения, поэтому пользователю не потребуется делать дополнительные корректировки для выравнивания объекта с поверхностью. - Beware that this will lead to clipping, if the pivot of the entity that you seek to snap to a surface is not located on its own surface. +Учтите, что это приведёт к наложению геометрии (clipping), если опорная точка объекта, который вы хотите привязать к поверхности, не находится на его собственной поверхности. -### Example Usage +### Пример использования  -(Pot is snapped to the side surface of the box.) +(Горшок привязан к боковой поверхности коробки.)  -(Pot is snapped to the upper surface of the box.) +(Горшок привязан к верхней поверхности коробки.)  -(Pots are surface snapped to each other.) +(Горшки привязаны друг к другу по поверхности.) -## Vertex Snapping Feature -The Vertex snapping feature allows users to choose any vertex from a selected entity and place that vertex in the same position as any vertex from another entity of their choosing. +## Функция привязки по вершинам (Vertex Snapping Feature) +Функция привязки по вершинам (Vertex snapping feature) позволяет пользователям выбрать любую вершину выбранного объекта и разместить эту вершину в той же позиции, что и любая вершина другого объекта по их выбору.  -(Two fence entities are vertex snapped to each other.) +(Два объекта забора привязаны друг к другу по вершинам.) -Alt + V activates and deactivates the vertex snapping feature. It only becomes active if an entity has been selected in the editor. There is a button on the editor toolbar as well, which acts like the hot-key. +Alt + V активирует и деактивирует функцию привязки по вершинам. Она становится активной только если в редакторе выбран объект. На панели инструментов редактора также есть кнопка, которая действует так же, как горячая клавиша.  -(Toolbar button for activating/deactivating vertex snapping) +(Кнопка панели инструментов для активации/деактивации привязки по вершинам) -After activating the tool and while the left mouse button is in a “down” state, the chosen entity’s selected vertex will continuously snap to the vertex of another, highlighted entity that is closest to the mouse ray’s intersection point. If the distance between the intersection point and the closest vertex is bigger than 2.0f or there is no second entity highlighted, nothing will happen. +После активации инструмента и пока левая кнопка мыши находится в "нажатом" состоянии, выбранная вершина выбранного объекта будет непрерывно привязываться к вершине другого, выделенного объекта, ближайшей к точке пересечения луча мыши. Если расстояние между точкой пересечения и ближайшей вершиной превышает 2.0f, или если не выделен второй объект, ничего не произойдёт. -Also, a yellow sphere will be rendered on the vertex to provide head-up display. Thus, user can choose any vertex by moving the mouse. This will be the first vertex. Also, sphere is scaled with respect to camera position’s distance. +Кроме того, на вершине будет отображена жёлтая сфера для наглядного отображения (head-up display). Таким образом, пользователь может выбрать любую вершину, перемещая мышь. Это будет первая вершина. Также сфера масштабируется в зависимости от расстояния до позиции камеры.  -(Current vertex is shown with yellow sphere.) +(Текущая вершина показана жёлтой сферой.) -After deciding on the first vertex, the snap operation can be done by holding down the left mouse button and moving the mouse. - -### Example Usage +После выбора первой вершины операцию привязки можно выполнить, удерживая левую кнопку мыши и перемещая мышь. + +### Пример использования  -(First vertex is shown with yellow sphere.) +(Первая вершина показана жёлтой сферой.)  -(Snapping path is shown with a yellow line.) +(Путь привязки показан жёлтой линией.)  -(If snapping is successful line color becomes green.) +(Если привязка успешна, цвет линии становится зелёным.)  -(Two cubes are snapped to each other by vertex.) +(Два куба привязаны друг к другу по вершине.) -If user releases the left mouse button when the line’s color is green, the snap will be successful. If user releases the left mouse button when the line’s color is yellow, there won’t be any snap and entity will be translated to its initial frame. +Если пользователь отпускает левую кнопку мыши, когда цвет линии зелёный, привязка будет успешной. Если пользователь отпускает левую кнопку мыши, когда цвет линии жёлтый, привязки не произойдёт, и объект будет перемещён в исходный кадр. -### Axis Constraints -When snap tool is active, you will see a gizmo on top of the nearest vertex. You can use axes of this gizmo to constraint axial movement or drag from middle to snap freely. \ No newline at end of file +### Ограничения по осям (Axis Constraints) +Когда инструмент привязки активен, вы увидите гизмо (gizmo) поверх ближайшей вершины. Вы можете использовать оси этого гизмо, чтобы ограничить перемещение по оси, или перетащить от центра для свободной привязки. diff --git a/docs/content/russian/Editor/Scene Editor/distance_tool.md b/docs/content/russian/Editor/Scene Editor/distance_tool.md index c6eb0248..2586a88b 100644 --- a/docs/content/russian/Editor/Scene Editor/distance_tool.md +++ b/docs/content/russian/Editor/Scene Editor/distance_tool.md @@ -1,22 +1,23 @@ +++ -title = "Distance Tool" +title = "Инструмент измерения расстояния" +ai_translated = true [menu.main] identifier = "distance_tool" parent = "core_components" +++ -## Distance Measure Tool -The Distance Tool measures the distance between two points in the scene. -Distance measure mode can be activated by either pressing Alt + D shortcut or the respective button on the editor toolbar. +## Инструмент измерения расстояния (Distance Measure Tool) +Инструмент измерения расстояния (Distance Tool) измеряет расстояние между двумя точками в сцене. +Режим измерения расстояния можно активировать либо нажатием сочетания клавиш Alt + D, либо соответствующей кнопкой на панели инструментов редактора. -While holding the left mouse button, drag the mouse between two points in the scene to measure distance. The tool snaps to vertices if close enough to a one by default, holding down Left Shift overrides this. +Удерживая левую кнопку мыши, перетащите курсор между двумя точками в сцене, чтобы измерить расстояние. По умолчанию инструмент привязывается к вершинам (vertices), если находится достаточно близко к одной из них, удержание клавиши Left Shift отменяет эту привязку. -The tool can be de-activated by pressing Alt + D or the respective button on the editor toolbar again. For further use, the gizmos stay visible even after the tool is de-activated. Pressing Alt + Shift + D clears these gizmos from the screen. +Инструмент можно деактивировать, снова нажав Alt + D или соответствующую кнопку на панели инструментов редактора. Для дальнейшего использования гизмо остаются видимыми даже после деактивации инструмента. Нажатие Alt + Shift + D очищает эти гизмо с экрана.  -Helper Gizmos +Вспомогательные гизмо (Helper Gizmos) -* Green line shows the actual distance between points. -* Blue lines show the lateral and longtidunal distances. -* Yellow circle depicts the range. \ No newline at end of file +* Зелёная линия показывает фактическое расстояние между точками. +* Синие линии показывают боковое и продольное расстояния. +* Жёлтый круг обозначает диапазон. diff --git a/docs/content/russian/Editor/Scene Editor/editor_shortcuts.md b/docs/content/russian/Editor/Scene Editor/editor_shortcuts.md index bb90a425..cad9d625 100644 --- a/docs/content/russian/Editor/Scene Editor/editor_shortcuts.md +++ b/docs/content/russian/Editor/Scene Editor/editor_shortcuts.md @@ -1,69 +1,70 @@ +++ -title = "Editor Shortcuts" +title = "Горячие клавиши редактора" description = "" weight = 1 +ai_translated = true +++ -General Editor Usage | Shortcut | Editor State +Общее использование редактора | Горячая клавиша | Состояние редактора ------- | ------- | -------- -Show/hide helpers | H | Any mode -New scene | Alt + 1 | Any mode -Save scene | Alt + 2 | Any mode -Open scene | Alt + 3 | Any mode -Start mission | Alt + 4 | Any mode -Start mission as | Alt + 5 | Any mode -Scene Options | Alt + 6 | Any mode -Terrain Options | Alt + 7 | Terrain select -Terrain Elevation | Alt + 8 | Terrain Paint Elevate -Terrain Paint | Alt + 9 | Terrain Paint Paint -Shift between relevant 2 editor modes (select-add, select-elevatepaint etc) | Space | Any mode -Undo/Redo | Ctrl+Z, Ctrl+Y | Any mode +Показать/скрыть помощники | H | Любой режим +Новая сцена | Alt + 1 | Любой режим +Сохранить сцену | Alt + 2 | Любой режим +Открыть сцену | Alt + 3 | Любой режим +Запустить миссию | Alt + 4 | Любой режим +Запустить миссию как | Alt + 5 | Любой режим +Параметры сцены | Alt + 6 | Любой режим +Параметры ландшафта | Alt + 7 | Выбор ландшафта +Высота ландшафта | Alt + 8 | Рисование ландшафта - Подъём +Рисование ландшафта | Alt + 9 | Рисование ландшафта - Рисование +Переключение между двумя соответствующими режимами редактора (выбор-добавление, выбор-подъём/рисование и т. д.) | Пробел | Любой режим +Отменить/Повторить | Ctrl+Z, Ctrl+Y | Любой режим -Camera Controls | Shortcut | Editor State +Управление камерой | Горячая клавиша | Состояние редактора ------- | ------- | -------- -Focus on selected entity | F | Entity Select -Editor camera orbiting mode | Alt (Hold) + Right Mouse Button | Entity Select -Pan | Alt (Hold) + Middle Mouse Button | Entity Select -Zoom in/out | Alt (Hold) + Mouse scroll wheel | Entity Select -Camera speed increase/decrease | Ctrl + Mouse scroll wheel | Any mode -Camera speed set to 1 | Ctrl + Middle mouse button | Any mode +Сфокусироваться на выбранном объекте | F | Выбор объекта +Режим вращения камеры редактора (орбита) | Alt (удерживать) + правая кнопка мыши | Выбор объекта +Панорамирование | Alt (удерживать) + средняя кнопка мыши | Выбор объекта +Увеличение/уменьшение масштаба | Alt (удерживать) + колесо прокрутки мыши | Выбор объекта +Увеличение/уменьшение скорости камеры | Ctrl + колесо прокрутки мыши | Любой режим +Установить скорость камеры на 1 | Ctrl + средняя кнопка мыши | Любой режим -Prefab transform | Shortcut | Editor State +Трансформация префаба | Горячая клавиша | Состояние редактора ------- | ------- | -------- -Rotate while placing | Z, X, C, T, reset to default with R | Entity Add -Move entity with placing on terrain | Hold P | Entity Select -Move entity vertically | Hold N | Entity Select -Move entity on the XY plane | Hold G | Entity Select -Show translate triad | T | Entity Select -Show rotating triad | R | Entity Select -Show scaling triad | Y | Entity Select -Duplicate the entity dragging on the translate triad | Shift+Click or Shift+Drag to side | Entity Select -Hide any triad on selected entity | V | Entity Select -Triads shown based on local coordinates (default) | Alt+L | Entity Select -Triads shown based on world coordinates | Alt+W | Entity Select -Material of an object under mouse opens in material editor (or material comes to inspector) | M+Click | Entity Select +Вращение при размещении | Z, X, C, T, сброс к значению по умолчанию — R | Добавление объекта +Перемещение объекта с привязкой к ландшафту | Удерживать P | Выбор объекта +Перемещение объекта по вертикали | Удерживать N | Выбор объекта +Перемещение объекта по плоскости XY | Удерживать G | Выбор объекта +Показать триаду перемещения | T | Выбор объекта +Показать триаду вращения | R | Выбор объекта +Показать триаду масштабирования | Y | Выбор объекта +Дублировать объект перетаскиванием за триаду перемещения | Shift+Клик или Shift+Перетаскивание в сторону | Выбор объекта +Скрыть любую триаду на выбранном объекте | V | Выбор объекта +Триады отображаются на основе локальных координат (по умолчанию) | Alt+L | Выбор объекта +Триады отображаются на основе мировых координат | Alt+W | Выбор объекта +Материал объекта под курсором мыши открывается в редакторе материалов (или материал отображается в инспекторе) | M+Клик | Выбор объекта -Terrain | Shortcut | Editor State +Ландшафт | Горячая клавиша | Состояние редактора ------- | ------- | -------- -Select all terrain nodes | Ctrl + A | Terrain Select -Lower when rise selected | Alt + Click | Terrain Paint Elevate -Rise when lower selected | Alt + Click | Terrain Paint Elevate -Flatten when Rise or Lower selected | Ctrl + Left Mouse Click | Terrain Paint Elevate -Smoothen when Rise or Lower selected | Shift + Click | Terrain Paint Elevate -Transfer height value to Flatten (when flatten selected) | Alt + Click | Terrain Paint Elevate -Flora paint (Not from layers) | Left Mouse Click | Entity Paint -Resize currently selected flora | B (hold) + Mouse drag left/right | Entity Paint -Place 1 flora (flora seen on brush) | Ctrl + Left Mouse Click | Entity Paint +Выбрать все узлы ландшафта | Ctrl + A | Выбор ландшафта +Понижение при выбранном подъёме | Alt + Клик | Рисование ландшафта - Подъём +Подъём при выбранном понижении | Alt + Клик | Рисование ландшафта - Подъём +Выровнять при выбранном подъёме или понижении | Ctrl + левый клик мыши | Рисование ландшафта - Подъём +Сгладить при выбранном подъёме или понижении | Shift + Клик | Рисование ландшафта - Подъём +Перенести значение высоты в инструмент выравнивания (при выбранном выравнивании) | Alt + Клик | Рисование ландшафта - Подъём +Рисование флоры (не из слоёв) | Левый клик мыши | Рисование объектов +Изменить размер выбранной флоры | B (удерживать) + перетаскивание мыши влево/вправо | Рисование объектов +Разместить 1 объект флоры (флора, видимая на кисти) | Ctrl + левый клик мыши | Рисование объектов -Navmesh hotkeys | Shortcut | Editor State +Горячие клавиши навигационной сетки | Горячая клавиша | Состояние редактора ------- | ------- | -------- -Fill in closest 4 vertices (creates a quad) | Shift + Click | Navigation Mesh Add -Fill in the last 4 vertices (creates a quad) | Ctrl + Space | Navigation Mesh Add -Move vertex without selecting | Ctrl + Drag | Navigation Mesh Add -Delete face with mouse over (leaves vertices) | Alt + Click | Navigation Mesh Add -Delete face and remove all vertices | Alt + X + Click | Navigation Mesh Add -Selection mode - vertex | 1 | Navigation Mesh Select -Selection mode - edge | 2 | Navigation Mesh Select -Selection mode - face | 3 | Navigation Mesh Select -Select all vertices, edges or face (depends on the current selection) | Ctrl + A | Navigation Mesh Select -Delete selected vertices, edges or face | Delete | Navigation Mesh Select \ No newline at end of file +Заполнить ближайшие 4 вершины (создаёт четырёхугольник) | Shift + Клик | Добавление навигационной сетки +Заполнить последние 4 вершины (создаёт четырёхугольник) | Ctrl + Пробел | Добавление навигационной сетки +Переместить вершину без выбора | Ctrl + Перетаскивание | Добавление навигационной сетки +Удалить грань под курсором мыши (оставляет вершины) | Alt + Клик | Добавление навигационной сетки +Удалить грань и все вершины | Alt + X + Клик | Добавление навигационной сетки +Режим выбора - вершина | 1 | Выбор навигационной сетки +Режим выбора - ребро | 2 | Выбор навигационной сетки +Режим выбора - грань | 3 | Выбор навигационной сетки +Выбрать все вершины, рёбра или грани (в зависимости от текущего выбора) | Ctrl + A | Выбор навигационной сетки +Удалить выбранные вершины, рёбра или грани | Delete | Выбор навигационной сетки diff --git a/docs/content/russian/Editor/Scene Editor/entity_inspector.md b/docs/content/russian/Editor/Scene Editor/entity_inspector.md index 28d98205..c1006cec 100644 --- a/docs/content/russian/Editor/Scene Editor/entity_inspector.md +++ b/docs/content/russian/Editor/Scene Editor/entity_inspector.md @@ -1,61 +1,62 @@ +++ -title = "Entity Inspector" +title = "Инспектор сущности (Entity Inspector)" description = "" weight = 20 +ai_translated = true +++ -### Transform Panel ### +### Панель Transform (Transform Panel) ###  -Transform panel allows you to change position, rotation and scale properties of the selected entities. -All of these values are relative to the parent of the selected entity. If Entity has no parent, then they are the Global values. (in [World]({{< ref "#world-space" >}}) space). +Панель Transform позволяет изменять свойства положения, вращения и масштаба выбранных сущностей. +Все эти значения относительны родителю выбранной сущности. Если у сущности нет родителя, то это глобальные значения (в пространстве [World]({{< ref "#world-space" >}})). -#### Scale #### -##### Locked ##### +#### Масштаб (Scale) #### +##### Заблокировано (Locked) #####  -If the lock icon is in locked state, changing any component of scale parameter will set all scale components to the same value, entity will be in uniform scaling mode. -##### Unlocked ##### +Если иконка замка находится в заблокированном состоянии, изменение любого компонента параметра масштаба установит одинаковое значение для всех компонентов масштаба, сущность будет находиться в режиме равномерного масштабирования. +##### Разблокировано (Unlocked) #####  -If the lock icon is in unlocked state, every scale component can be changed independently, and will allow non-uniform scaling. +Если иконка замка находится в разблокированном состоянии, каждый компонент масштаба можно изменять независимо, что позволяет неравномерное масштабирование. -### Transform with Gizmo ### +### Transform с помощью гизмо (Gizmo) ### -#### Transform modes #### +#### Режимы трансформации #### -All of the transformation can also be done using Gizmo. -Gizmo can be activated by selecting an entity (or multiple entities) and pressing one of the hotkeys below. +Все трансформации также можно выполнять с помощью гизмо (Gizmo). +Гизмо можно активировать, выбрав сущность (или несколько сущностей) и нажав одну из горячих клавиш ниже. -Rotate | Translate | Scale +Поворот (Rotate) | Перемещение (Translate) | Масштаб (Scale) ---- | ---- | ---- -Hotkey: R | Hotkey: T | Hotkey: Y +Горячая клавиша: R | Горячая клавиша: T | Горячая клавиша: Y  |  |  -#### Transform spaces #### +#### Пространства трансформации #### -Gizmo can work in three different spaces; [World]({{< ref "#world-space" >}}) space, [Local]({{< ref "#local-space" >}}) space and [Screen]({{< ref "#screen-space" >}}) space. +Гизмо может работать в трёх разных пространствах: [World]({{< ref "#world-space" >}}) (мировое пространство), [Local]({{< ref "#local-space" >}}) (локальное пространство) и [Screen]({{< ref "#screen-space" >}}) (экранное пространство). -##### World space ##### +##### Мировое пространство (World space) ##### -World coordinates is just a fixed, parent coordinate system. This is the global coordinate system that everything is defined relative to. -World Coordinate has a fixed [1, 0, 0] in the X direction, [0, 1, 0] in the Y direction, and [0, 0, 1] in the Z direction. +Мировые координаты — это просто фиксированная, родительская система координат. Это глобальная система координат, относительно которой определено всё остальное. +Мировая система координат имеет фиксированное значение [1, 0, 0] по направлению X, [0, 1, 0] по направлению Y и [0, 0, 1] по направлению Z. -##### Local space ##### -Local coordinates are relative to the entity itself, every transform is defined such as that the center of the entity is center of the universe. +##### Локальное пространство (Local space) ##### +Локальные координаты относительны самой сущности — каждая трансформация определена так, что центр сущности является центром вселенной. -##### Screen space ##### -Screen space coordinates are relative to the camera. Right of your viewport is always the X axis, Top is always the Y axis, and forward is always the -Z (minus Z) axis. +##### Экранное пространство (Screen space) ##### +Координаты экранного пространства относительны камере. Правая сторона вашего вьюпорта всегда является осью X, верх всегда является осью Y, а вперёд всегда является осью -Z (минус Z). -### Entity Tag System ### -An entity on editor can be identified by a tag defined by the user. +### Система тегов сущностей (Entity Tag System) ### +Сущность в редакторе может быть идентифицирована с помощью тега, определённого пользователем. -#### Adding Tags -In the Entity Inspector, under the "Tags" title, there is a button with label "Add New Tag". This button opens a window asking for the name of the tag. +#### Добавление тегов +В инспекторе сущности (Entity Inspector), под заголовком «Tags», есть кнопка с надписью «Add New Tag». Эта кнопка открывает окно с запросом имени тега. -#### Using an Existing Tag -After clicking on the "Add New Tag" button, from the dropdown menu in the window, you can select tags, which were added to the current scene entities before. +#### Использование существующего тега +После нажатия кнопки «Add New Tag» в выпадающем меню окна можно выбрать теги, которые ранее были добавлены к другим сущностям текущей сцены. -#### A Special Case: Prefabs -If you are modifying a prefab entity, adding tags to the prefab does not break it. In other words, if you change the prefab after tagging the prefab entity in the scene, the scene entity will have all the changes as well. -The tags are stored in the xml files with "< tags >... < / tags >" syntax. (without the white spaces between characters) \ No newline at end of file +#### Особый случай: префабы (Prefabs) +Если вы изменяете сущность-префаб, добавление тегов к префабу не нарушает его работу. Другими словами, если вы измените префаб после присвоения тега сущности-префабу на сцене, сущность на сцене получит все изменения тоже. +Теги хранятся в XML-файлах в формате «< tags >... < / tags >» (без пробелов между символами). diff --git a/docs/content/russian/Editor/Scene Editor/level_system.md b/docs/content/russian/Editor/Scene Editor/level_system.md index bd3e9507..43f7098a 100644 --- a/docs/content/russian/Editor/Scene Editor/level_system.md +++ b/docs/content/russian/Editor/Scene Editor/level_system.md @@ -1,21 +1,22 @@ +++ -title = "Scene Level System" +title = "Система уровней сцены" +ai_translated = true [menu.main] identifier = "level_system" parent = "core_components" +++ -## Level System -New level system replaces the old, hardcoded system with a much more extandable and unified system. \\ -Adding a new level (or deleting an existing one) to a scene can be done in Levels panel under SceneOptions inspector. +## Система уровней +Новая система уровней заменяет старую, жёстко закодированную систему гораздо более расширяемой и унифицированной системой. \\ +Добавление нового уровня (или удаление существующего) на сцену можно выполнить на панели Levels в инспекторе SceneOptions.  -## Levels in Game +## Уровни в игре #### - Bannerlord - -Currently, Bannerlord recognizes a few levels that has a meaning in-game. \\ -Which are: \\ +В настоящее время Bannerlord распознаёт несколько уровней, имеющих значение в игре. \\ +А именно: \\ 1) level_1 \\ 2) level_2 \\ 3) level_3 \\ @@ -23,39 +24,39 @@ Which are: \\ 5) civilian -## Setting Entity visibilities -Making an entity only visible in a certain level combinations can be done with selecting an entity then going in Scene Level Visibilities panel under Entity Inspector. +## Настройка видимости объектов +Сделать объект видимым только при определённых комбинациях уровней можно, выбрав объект, а затем перейдя на панель Scene Level Visibilities в Entity Inspector.  -Select the levels you want this entity to be visible. -Entity levels in missions are checked as a whole. -### Example -If you select both level_1 and siege, and if you open a mission that has _level\_2_ and siege, this entity will NOT be visible since it does not has "level_2". \\ -If you select both level_1 and siege, and if you open a mission that has level_1 and _civilian_, this entity will NOT be visible since it does not has "siege". \\ -It will only and only be visible if you open a mission that has level_1 and siege. +Выберите уровни, на которых вы хотите, чтобы этот объект был видим. +Уровни объекта в миссиях проверяются как единое целое. +### Пример +Если вы выбрали и level_1, и siege, и вы открываете миссию, в которой есть _level\_2_ и siege, этот объект НЕ будет видим, поскольку в ней отсутствует "level_2". \\ +Если вы выбрали и level_1, и siege, и вы открываете миссию, в которой есть level_1 и _civilian_, этот объект НЕ будет видим, поскольку в ней отсутствует "siege". \\ +Он будет видим только и исключительно в том случае, если вы откроете миссию, в которой есть и level_1, и siege. -So if you want an entity to be visible in both level_1 and level_2 and only in civilian mission, select level_1, level_2, and civilian; \\ - so this entity will not be visible in ANY siege missions, and will not be visible in ANY mission as level_3. +Так что если вы хотите, чтобы объект был видим и на level_1, и на level_2, но только в режиме civilian, выберите level_1, level_2 и civilian; \\ + таким образом этот объект не будет видим НИ В ОДНОЙ миссии осады (siege), и не будет видим ни в одной миссии как level_3. -## Testing visibility in editor +## Проверка видимости в редакторе  -There are two options to see entities with different level visibilities. +Есть два варианта, чтобы увидеть объекты с разной видимостью уровней. -__1) Require all levels (Same as missions)__ \\ -__2) Require at least one level (Editor only, to see all entities at once)__ +__1) Require all levels (Требовать все уровни) (так же, как в миссиях)__ \\ +__2) Require at least one level (Требовать хотя бы один уровень) (только в редакторе, чтобы увидеть все объекты сразу)__ -### Require all levels -In this mode, visibility system will work as same as the missions, you can use this mode to test what entities will be visible in what combinations. \\ -If you select level_1 and siege, you will only see entities that has __both__ level_1 and siege, not the others. +### Require all levels (Требовать все уровни) +В этом режиме система видимости будет работать так же, как и в миссиях, вы можете использовать этот режим, чтобы проверить, какие объекты будут видимы при каких комбинациях. \\ +Если вы выберете level_1 и siege, вы увидите только те объекты, у которых есть __и__ level_1, __и__ siege, но не остальные. -### Require at least one level -This is an editor only mode, if you select a level, it will be visible, no matter what combinations that entity has; if entity has that level, it will be visible. \\ -Can be useful if you want to see all _civilian_ entities no matter what level they are, or you can see _level\_1_ entites no matter if they are siege or civilian. +### Require at least one level (Требовать хотя бы один уровень) +Это режим, доступный только в редакторе: если вы выберете уровень, объект будет видим независимо от того, какие комбинации уровней у него есть; если у объекта есть этот уровень, он будет видим. \\ +Это может быть полезно, если вы хотите увидеть все объекты _civilian_ независимо от того, на каком они уровне, или вы можете увидеть объекты _level\_1_ независимо от того, относятся ли они к siege или civilian. -## Testing a scene +## Тестирование сцены  -For this purpose, __Start mission as__ window modified in a way that allows you to select level combinations. -If you want to test a castle scene with level_1 and siege mode, Select these leves and press OK. The mission will start in Level 1 Siege mode. +Для этой цели окно __Start mission as__ было изменено таким образом, чтобы позволить вам выбирать комбинации уровней. +Если вы хотите протестировать сцену замка в режиме level_1 и siege, выберите эти уровни и нажмите OK. Миссия запустится в режиме Level 1 Siege. diff --git a/docs/content/russian/Editor/Scene Editor/mass_selection.md b/docs/content/russian/Editor/Scene Editor/mass_selection.md index 9e2dfdd9..d482497a 100644 --- a/docs/content/russian/Editor/Scene Editor/mass_selection.md +++ b/docs/content/russian/Editor/Scene Editor/mass_selection.md @@ -1,5 +1,6 @@ +++ -title = "Mass Selection" +title = "Массовый выбор (Mass Selection)" +ai_translated = true [menu.main] identifier = "mass_selection" @@ -8,9 +9,9 @@ parent = "entity_inspector"  -Mass Selection script allows you to select objects in a box and apply random rotations to selected objects. You can relocate and resize the selection box with translating, rotating and scaling entity which has "mass_selection" script. -Bounding Box Constraint property allows you to select objects which has smaller bounding box than it's value. +Скрипт Mass Selection позволяет выбирать объекты в пределах прямоугольной области (box) и применять случайные повороты к выбранным объектам. Вы можете перемещать и изменять размер области выбора с помощью перемещения, поворота и масштабирования сущности, к которой прикреплён скрипт "mass_selection". +Свойство Bounding Box Constraint позволяет выбирать объекты, ограничивающий прямоугольник (bounding box) которых меньше заданного значения. -Locate Selection Box | After Select Objects | After Apply Random Rotations +Расположение области выбора | После выбора объектов | После применения случайных поворотов ---- | ---- | ---- - |  |  \ No newline at end of file + |  |  diff --git a/docs/content/russian/Editor/Scene Editor/nav_mesh.md b/docs/content/russian/Editor/Scene Editor/nav_mesh.md index 4d13f6e5..4a5b7a96 100644 --- a/docs/content/russian/Editor/Scene Editor/nav_mesh.md +++ b/docs/content/russian/Editor/Scene Editor/nav_mesh.md @@ -1,115 +1,116 @@ +++ -title = "Navmesh" -description = "Navigation Mesh Modeling Creation Guides and Examples" +title = "Навмеш" +description = "Руководства и примеры по созданию навигационной сетки" weight = 1 +ai_translated = true +++ ------------------ -### What is the Navigation Mesh? ### -Navigation Mesh is a compilation of models created by the scene designer for the use of AI to make sure they can move around without colliding with the physic objects in the scene. +### Что такое навигационная сетка (Navigation Mesh)? ### +Навигационная сетка — это набор моделей, созданных дизайнером сцены для использования ИИ, чтобы гарантировать, что он может перемещаться, не сталкиваясь с физическими объектами на сцене. ------------------ -### What are the important rules for Navigation Mesh? ### -a. 1,5 Meter Rule: Designers needs to arrange the navigation mesh in a 1.5-meter diameter when creating on terrain or other objects that can be walked on or can stand on (Rooftops, castle walls etc.) This diameter needs to be in 1.5 meters on a vertical axis. If this 1.5 rule is not applied, AI won’t be able to find the way when walking. +### Какие важные правила существуют для навигационной сетки? ### +a. Правило 1,5 метра: При создании сетки на местности или других объектах, по которым можно ходить или на которых можно стоять (крыши, стены замка и т. д.), дизайнерам необходимо располагать навигационную сетку с учётом диаметра 1,5 метра. Этот диаметр должен соблюдаться по вертикальной оси на 1,5 метра. Если это правило 1,5 метра не соблюдается, ИИ не сможет найти путь при ходьбе. -b. Spawn Point Pivot Points: Each spawn point in a scene has pivot points. Navmesh polygon faces have to include these spawn point pivot points. Otherwise, spawn points will not work. +b. Опорные точки (Pivot Points) точек спавна: У каждой точки спавна на сцене есть опорные точки. Грани полигонов навмеша должны включать эти опорные точки точек спавна. В противном случае точки спавна не будут работать. -c. Existing Trees: Each tree in a scene has a physical object which we call ‘capsules’. AI will see these capsules automatically when in a battle. Because of this, AI won’t walk into trees. Navmesh can be applied under trees. +c. Существующие деревья: У каждого дерева на сцене есть физический объект, который мы называем «капсулой» (capsule). ИИ автоматически видит эти капсулы во время боя. Из-за этого ИИ не будет врезаться в деревья. Навмеш можно наносить под деревьями. -d. Terrain Angle: There are some areas that won’t be traversable because of their steep angle. These areas can be enabled with: Shaded > Debug - Terrain Angle. On the opened Angel Limit window, designers can input "50" to enable these. You can see two areas which are green and red. Green areas are traversable and red areas aren't. +d. Угол местности (Terrain Angle): Есть некоторые области, которые будут непроходимыми из-за их крутого угла наклона. Эти области можно включить через: Shaded > Debug - Terrain Angle. В открывшемся окне Angle Limit дизайнеры могут ввести «50», чтобы включить их отображение. Вы увидите две области, зелёную и красную. Зелёные области проходимы, а красные — нет. -e. Where to apply Navemesh: Navigation Mesh should be applied to every surface upon which players can walk. Navigation mesh should not be applied under the physical objects. Since the AI can’t jump, areas which can be accessible with jumping should not contain the navigation mesh. +e. Где применять навмеш: Навигационную сетку следует наносить на каждую поверхность, по которой могут ходить игроки. Навигационную сетку не следует наносить под физическими объектами. Поскольку ИИ не умеет прыгать, в областях, доступных только посредством прыжка, не должно быть навигационной сетки. -**There is no "Undo" operation in the Navigation Mesh. If you press CTRL + Z, the last scene change will be reverted. Do not try to undo when applying Navigation Mesh** +**В навигационной сетке нет операции «Undo» (отмены). Если вы нажмёте CTRL + Z, последнее изменение сцены будет отменено. Не пытайтесь использовать отмену при работе с навигационной сеткой** ------------------ -### How many types of Navigation Mesh need to be applied? ### -There are three types of Navigation Mesh: +### Сколько типов навигационной сетки нужно применять? ### +Существует три типа навигационной сетки: -1.Basic navigation mesh areas (without an ID, ID:0), for example, battle_terrain, hideout or lords hall. -2.Village Scenes. Scenes like villages have multiple navigation mesh ID’s. -3.Siege-Town scenes. In these kind of scenes, there are two main visibility modes for Civilian and Siege. The town scene in civilian mode can be seen as a big village scene. But on Siege mode, there are some places and cases that demand Navigation Mesh faces to have special ID’s. +1.Базовые области навигационной сетки (без ID, ID:0), например battle_terrain, hideout или lords hall. +2.Сцены деревень. У таких сцен, как деревни, есть несколько ID навигационной сетки. +3.Сцены осады города (Siege-Town). В таких сценах есть два основных режима видимости: гражданский (Civilian) и осадный (Siege). Сцену города в гражданском режиме можно рассматривать как большую деревенскую сцену. Но в режиме осады есть места и случаи, требующие, чтобы грани навигационной сетки имели специальные ID. ------------------ -### Navigation Mesh Modeling Foreknowledge ### +### Предварительные знания о моделировании навигационной сетки ### -**When opening the editor you will see a toolbar as shown in the photo below.** +**При открытии редактора вы увидите панель инструментов, как показано на фото ниже.**  -**The icon in the red square is for the Navigation Mesh. When you click on it, you will see that the “NavigationMeshInspector” is opened in the inspector.** +**Иконка в красном квадрате предназначена для навигационной сетки. Когда вы нажмёте на неё, вы увидите, что в инспекторе откроется «NavigationMeshInspector».**  -**After the Navigation Mesh Inspector is opened you will see ‘Editor Mode: Navigation Mesh Select’ in the UI.** +**После открытия инспектора навигационной сетки вы увидите в интерфейсе надпись «Editor Mode: Navigation Mesh Select».**  -**All the dropdown menu functions in the Navigation Mesh Inspector can be used in the Navigation Mesh Select mode. Hitting 1,2 or 3 on the keyboard will select these faces:** -**1: Vertices 2: Edges 3: Faces.** +**Все функции выпадающего меню в инспекторе навигационной сетки можно использовать в режиме Navigation Mesh Select. Нажатие клавиш 1, 2 или 3 на клавиатуре выберет следующие элементы:** +**1: Вершины (Vertices) 2: Рёбра (Edges) 3: Грани (Faces).** ------------------ -### Navigation Mesh Modeling ### +### Моделирование навигационной сетки ### -**Until now we spoke about the **Navigation Mesh Select Tool mode. Another editor mode for Navigation Mesh is Navigtation Mesh Add mode.** +**До сих пор мы говорили о режиме инструмента Navigation Mesh Select. Другой режим редактора для навигационной сетки — это режим Navigation Mesh Add.**   -**To open this mode you can press the ‘Spacebar’ key. You will see a vertex preview in the mouse pointer.** +**Чтобы открыть этот режим, нажмите клавишу «Spacebar» (пробел). Вы увидите предпросмотр вершины на указателе мыши.** -**After pointing out 4 different points in the map, press CTRL+Space to create the Navigation Mesh polygon.** +**После указания 4 разных точек на карте нажмите CTRL+Space, чтобы создать полигон навигационной сетки.** | ---- | ----  |  -**The shortcut table below can be helpful after the polygon creation phase. Below that, you also have the explanation of the tools available under the Generation Tools tab in the Navigation Mesh Inspector.** +**Таблица сочетаний клавиш ниже может быть полезна после этапа создания полигона. Под ней также приведено объяснение инструментов, доступных на вкладке Generation Tools в инспекторе навигационной сетки.** -Navmesh hotkeys | Shortcut | Editor State +Горячие клавиши навмеша | Сочетание клавиш | Состояние редактора ------- | ------- | -------- -Fill in closest 4 vertices (creates a quad) | Shift + Click | Navigation Mesh Add -Fill in the last 4 vertices (creates a quad) | Ctrl + Space | Navigation Mesh Add -Move vertex without selecting | Ctrl + Drag | Navigation Mesh Add -Delete face with mouse over (leaves vertices) | Alt + Click | Navigation Mesh Add -Delete face and remove all vertices | Alt + X + Click | Navigation Mesh Add -Selection mode - vertex | 1 | Navigation Mesh Select -Selection mode - edge | 2 | Navigation Mesh Select -Selection mode - face | 3 | Navigation Mesh Select -Select all vertices, edges or face (depends on the current selection) | Ctrl + A | Navigation Mesh Select -Delete selected vertices, edges or face | Delete | Navigation Mesh Select +Заполнить ближайшие 4 вершины (создаёт квад) | Shift + клик | Navigation Mesh Add +Заполнить последние 4 вершины (создаёт квад) | Ctrl + Space | Navigation Mesh Add +Переместить вершину без выделения | Ctrl + перетаскивание | Navigation Mesh Add +Удалить грань под курсором (вершины остаются) | Alt + клик | Navigation Mesh Add +Удалить грань и все вершины | Alt + X + клик | Navigation Mesh Add +Режим выделения — вершина | 1 | Navigation Mesh Select +Режим выделения — ребро | 2 | Navigation Mesh Select +Режим выделения — грань | 3 | Navigation Mesh Select +Выделить все вершины, рёбра или грани (в зависимости от текущего режима выделения) | Ctrl + A | Navigation Mesh Select +Удалить выделенные вершины, рёбра или грани | Delete | Navigation Mesh Select -### Generation Tools +### Инструменты генерации -The most useful and used tools are: +Самые полезные и часто используемые инструменты: -* Extrude: Extrusion along the selected edge's (or edges') axis. -* Fill: Fills between the selected navigation mesh vertices (or edges) and forms a face. -* Grow Selection: Grows the selection by selecting the adjacent elements to the selected elements (works for all vertex, edge and face structures). -* Connect: Connects the selected two navigation mesh vertices by drawing an edge between them. -* Weld: Removes vertices forming the edge and makes the edge one single vertex. It connects the old adjacent vertices to the newly generated vertex. +* Extrude (Выдавливание): выдавливание вдоль оси выбранного ребра (или рёбер). +* Fill (Заполнение): заполняет пространство между выбранными вершинами (или рёбрами) навигационной сетки и образует грань. +* Grow Selection (Расширение выделения): расширяет выделение, добавляя соседние элементы к выбранным элементам (работает для всех структур — вершин, рёбер и граней). +* Connect (Соединение): соединяет две выбранные вершины навигационной сетки, проводя между ними ребро. +* Weld (Сварка): удаляет вершины, образующие ребро, и превращает ребро в одну единственную вершину. Соединяет старые соседние вершины с новой созданной вершиной. ------------------ -### Navigation Mesh Modeling on Scene Types ### +### Моделирование навигационной сетки для разных типов сцен ### -**We discussed briefly how to create and apply the Navigation Mesh. Let’s consolidate this information by creating a Navigation Mesh for a village scene with the help of some screenshots along the way.** +**Мы кратко обсудили, как создавать и применять навигационную сетку. Давайте закрепим эту информацию, создав навигационную сетку для сцены деревни с помощью нескольких скриншотов.** -#### 1.Village Scene #### +#### 1. Сцена деревни #### -**After opening a village scene, let’s navigate to the Visibility tab and change it as seen in the screenshot below to work more comfortably. Visibility Masks > Game Entities (Uchecked), Particle Systems (Unchecked), Layer Flora (Unchecked), Show Paths (Unchecked) Physics Options > Show Entity Physics (Checked).** +**После открытия сцены деревни перейдём на вкладку Visibility и изменим настройки, как показано на скриншоте ниже, чтобы работать удобнее. Visibility Masks > Game Entities (не отмечено), Particle Systems (не отмечено), Layer Flora (не отмечено), Show Paths (не отмечено). Physics Options > Show Entity Physics (отмечено).** | ---- | ----  |  -**Click on the Navigation Mesh Icon on the toolbar and open the Navigation Mesh Inspector tab on the right side. After that, press 3 on your keyboard to open the Face mode. Change the ID part from 0 to 2.** +**Нажмите на иконку навигационной сетки на панели инструментов и откройте вкладку Navigation Mesh Inspector справа. После этого нажмите 3 на клавиатуре, чтобы открыть режим Face (грани). Измените часть ID с 0 на 2.**  -**Let’s create our first face. As seen in the screenshot below, place the vertices on top of the road and click CTRL+Space. You will see a Navigation Mesh Polygon created. We can place 2 more vertices near the existing polygon and press Shift+Left Mouse Button to create additional Polygons.** +**Давайте создадим нашу первую грань. Как показано на скриншоте ниже, разместите вершины поверх дороги и нажмите CTRL+Space. Вы увидите созданный полигон навигационной сетки. Мы можем разместить ещё 2 вершины рядом с существующим полигоном и нажать Shift+левая кнопка мыши, чтобы создать дополнительные полигоны.** || @@ -125,25 +126,25 @@ The most useful and used tools are: ------------------ -**By holding CTRL while navigating the mouse to the vertices we can see the yellow previews. Holding these vertices with Left Mouse Button will allow us to move the vertex freely.** +**Удерживая CTRL и наводя курсор мыши на вершины, мы увидим жёлтый предпросмотр. Удержание этих вершин левой кнопкой мыши позволит свободно их перемещать.**  -**In the Navigation Mesh Select mode, select what mode you want to use (1 (Vertex) 2 (Edge) 3 (Face)) and use Alt+Delete to remove. This will leave the vertices in the scene (If Edge 2 ((Edge)) and 3 ((Face)) are selected). If you want the vertices to be inactive you can press Alt+X+Delete keys.** -**The other remove method is in the Navigation Mesh Add mode. If we hover over the vertex, edge or faces with ALT button pressed we can see a red preview. We can remove them by clicking the Left Mouse Button.** +**В режиме Navigation Mesh Select выберите нужный режим (1 (вершина) 2 (ребро) 3 (грань)) и используйте Alt+Delete для удаления. Это оставит вершины на сцене (если выбраны режимы Edge 2 (ребро) и 3 (грань)). Если вы хотите, чтобы вершины стали неактивными, вы можете нажать клавиши Alt+X+Delete.** +**Другой способ удаления находится в режиме Navigation Mesh Add. Если мы наведём курсор на вершину, ребро или грань с зажатой клавишей ALT, мы увидим красный предпросмотр. Мы можем удалить их, щёлкнув левой кнопкой мыши.** -Navigation Mesh Select Mode-NavDelete | Navigation Mesh Add Mode-NavDelete +Режим Navigation Mesh Select — удаление | Режим Navigation Mesh Add — удаление ---- | ----  |  ------------------ -##### EASY AND FASTER NAVMESH CREATION TIP ##### +##### СОВЕТ ДЛЯ БОЛЕЕ ЛЁГКОГО И БЫСТРОГО СОЗДАНИЯ НАВМЕША #####  ------------------ -**Navigation Mesh needs to contain the spawn point pivot points. Let’s apply the navigation mesh as they are connected with all the roads and navigation mesh face on spawn points.** +**Навигационная сетка должна содержать опорные точки точек спавна. Давайте применим навигационную сетку так, чтобы она была соединена со всеми дорогами и гранями навигационной сетки в точках спавна.** | ---- | ---- @@ -153,7 +154,7 @@ Navigation Mesh Select Mode-NavDelete | Navigation Mesh Add Mode-NavDelete ------------------ -**Let’s press the Spacebar after creating a navigation mesh face to check that the ID is set to 2 and change the Editor mode to Navigation Mesh Select mode and press the "3" key on the keyboard. This process will ensure that we chose the navigation mesh face. After this, let’s select the face and make sure that the ID is 2 on the Navigation Mesh Inspector. We already saw it was 2 when we started but we are now sure it is 2. We can deselect what we chose by clicking on an empty space on Viewport. Now, we can press the Spacebar to change the Editor mode to the Navigation Mesh add and continue.** +**Нажмём Spacebar после создания грани навигационной сетки, чтобы проверить, что ID установлен на 2, и переключим режим редактора на Navigation Mesh Select, затем нажмём клавишу «3» на клавиатуре. Этот процесс гарантирует, что мы выбрали грань навигационной сетки. После этого выделим грань и убедимся, что ID равен 2 в инспекторе навигационной сетки. Мы уже видели, что он был равен 2 в начале, но теперь мы в этом окончательно убедились. Мы можем снять выделение, щёлкнув по пустому месту в видовом окне. Теперь мы можем нажать Spacebar, чтобы переключить режим редактора обратно на Navigation Mesh Add, и продолжить.**  @@ -161,61 +162,61 @@ Navigation Mesh Select Mode-NavDelete | Navigation Mesh Add Mode-NavDelete -**Please make sure your navigation mesh areas don't contain any physical objects.** +**Пожалуйста, убедитесь, что ваши области навигационной сетки не содержат физических объектов.** | ---- | ----  |  -**The animal spawn points can be seen in the screenshot below. To make sure the scene has animal spawn points you can click on the entity in the scene and check the text located on the bottom left of the screen.** +**Точки спавна животных можно увидеть на скриншоте ниже. Чтобы убедиться, что на сцене есть точки спавна животных, вы можете щёлкнуть по объекту на сцене и проверить текст, расположенный в нижнем левом углу экрана.**  -**To prevent animals from escaping let's apply navigation mesh like an island and use the mesh ID 2. After that, let’s change the ID of the surrounding mesh faces to 3. That way, the animals won't be connected with the rode and won't be able to escape.** +**Чтобы предотвратить побег животных, давайте применим навигационную сетку в виде острова и используем ID сетки 2. После этого изменим ID окружающих граней сетки на 3. Таким образом, животные не будут соединены с дорогой и не смогут сбежать.** | ---- | ----  |  -**There are special fields in the scenes that we call ‘common areas’. You can see these areas in the scene with a sphere. Let’s fill in this sphere with the navigation mesh faces that has the ID 2, while making sure there are no physical objects inside of them.** +**На сценах есть специальные поля, которые мы называем «общими зонами» (common areas). Вы можете увидеть эти зоны на сцене в виде сферы. Давайте заполним эту сферу гранями навигационной сетки с ID 2, убедившись, что внутри них нет физических объектов.** | ---- | ----  |  -**After making sure all the roads and spawn points are applied and connected to each other we have finished the phase one.** +**После того как мы убедились, что все дороги и точки спавна применены и соединены друг с другом, мы завершили первый этап.**  -**If there are any unwalkable terrain fields, you can click on the “Shaded” option in the dropdown menu located in the top bar. Choose the Terrain Angle in the “Debug” field and change the Angle Limit to 50. Now, we can see the red areas and apply navigation mesh according to this information.** +**Если есть какие-либо непроходимые участки местности, вы можете нажать на опцию «Shaded» в выпадающем меню в верхней панели. Выберите Terrain Angle в поле «Debug» и измените Angle Limit на 50. Теперь мы можем увидеть красные зоны и применить навигационную сетку с учётом этой информации.**  -**Let’s change the ID to 1 in the Navigation Mesh Inspector while making sure there are no selected navigation mesh faces. Let’s continue to apply navigation mesh while making sure there are no physical objects inside of them.** +**Изменим ID на 1 в инспекторе навигационной сетки, убедившись, что ни одна грань навигационной сетки не выбрана. Продолжим применять навигационную сетку, убедившись, что внутри неё нет физических объектов.**  -**Let’s complete the navigation mesh of the scene after we make sure every surface on the scene is inside of the borders (you can toggle the Border view with Visibility > Visibility Masks).** +**Завершим навигационную сетку сцены после того, как убедимся, что каждая поверхность на сцене находится внутри границ (вы можете переключить отображение границ через Visibility > Visibility Masks).**  -**The navigation mesh of this village scene is complete.** +**Навигационная сетка этой сцены деревни завершена.**  -**Now, let’s take a look at the scripting of the Navigation Mesh IDs. Navigate to the Prefabs tab and search for “navigation_mesh_deactivator” in the filter field. Let’s put that into the scene. Select the Navigation_Mesh_Deactivator entity in the scene tab. Let’s open the dropdown menus in the Entity Inspector > Scripts > NavigationMeshDeactivator. Set the DisableFaceWithId to 1 and DisableFaceWithIdForAnimals to 3.** +**Теперь давайте посмотрим на скриптинг ID навигационной сетки. Перейдите на вкладку Prefabs и найдите «navigation_mesh_deactivator» в поле фильтра. Поместим его на сцену. Выберем объект Navigation_Mesh_Deactivator на вкладке Scene. Откроем выпадающие меню в Entity Inspector > Scripts > NavigationMeshDeactivator. Установим DisableFaceWithId на 1, а DisableFaceWithIdForAnimals на 3.** | ---- | ----  |  -Save the scene. **The navigation mesh process for our village scene is completed.** +Сохраните сцену. **Процесс создания навигационной сетки для нашей сцены деревни завершён.** ------------------ -### The Logic of Navigation Mesh IDs ### -**The navigation mesh faces with the ID of 2, are the navigation mesh faces that the AI sees while we take a walk in a scene. These faces needs to be connected to each other. The faces which include the animal spawn points need to have the ID of 2, as well. The reason why these faces are not connected is because we don’t want the animals to walk on the roads as the human NPCs. To make sure that the animal spawn points are active their navigation mesh face ID has to be 2. To disconnect their connection with the road, we apply navigation mesh that surrounds the animal spawn point faces with the ID of 2 and give the new navigation mesh faces the ID of 3. After this we also include this to the navigation_mesh_deactivator script. The faces with the ID of 1 are the faces that are not active in the walk mode, but they have to be applied. When a village is raided all the navigation meshes are active, without looking out for the IDs. Those are activated when we take a walk in the scene.** +### Логика ID навигационной сетки ### +**Грани навигационной сетки с ID 2 — это грани навигационной сетки, которые видит ИИ, когда мы гуляем по сцене. Эти грани должны быть соединены друг с другом. Грани, включающие точки спавна животных, также должны иметь ID 2. Причина, по которой эти грани не соединены, заключается в том, что мы не хотим, чтобы животные ходили по дорогам, как человеческие NPC. Чтобы точки спавна животных были активны, ID их грани навигационной сетки должен быть равен 2. Чтобы разорвать их связь с дорогой, мы наносим навигационную сетку, окружающую грани точек спавна животных, с ID 2, и присваиваем новым граням навигационной сетки ID 3. После этого мы также добавляем это в скрипт navigation_mesh_deactivator. Грани с ID 1 — это грани, которые неактивны в режиме прогулки, но их всё равно нужно применить. Когда деревню штурмуют, все навигационные сетки становятся активными, независимо от ID. Они активируются, когда мы гуляем по сцене.** -Navigation Meshes with the ID of 2 are active | All the navigation meshes are active +Навигационные сетки с ID 2 активны | Все навигационные сетки активны ---- | ----  |  diff --git a/docs/content/russian/Editor/Scene Editor/nav_mesh_inspector.md b/docs/content/russian/Editor/Scene Editor/nav_mesh_inspector.md index 16579f2d..9f1b7343 100644 --- a/docs/content/russian/Editor/Scene Editor/nav_mesh_inspector.md +++ b/docs/content/russian/Editor/Scene Editor/nav_mesh_inspector.md @@ -1,81 +1,82 @@ +++ -title = "Navigation Mesh Inspector" +title = "Инспектор навигационной сетки (Navigation Mesh Inspector)" description = "" weight = 20 +ai_translated = true +++ -#### Tools -These tools help you to generate and manipulate the navigation mesh: +#### Инструменты +Эти инструменты помогают генерировать и редактировать навигационную сетку: -#### Generation Tools +#### Инструменты генерации  -* Auto Generate: As the name implies, automatically generates the navigation mesh with resppect to the parameters above. -* Generate Grids: Generates grid navigation mesh for the terrain only. It ignores the entities on the scene. -* Create New Face: Creates a new navigation mesh quad face on the coordinates where the camera is. +* Auto Generate: Как следует из названия, автоматически генерирует навигационную сетку с учётом параметров, указанных выше. +* Generate Grids: Генерирует сеточную навигационную сетку только для рельефа (terrain). Игнорирует сущности на сцене. +* Create New Face: Создаёт новую четырёхугольную грань навигационной сетки в координатах, где находится камера. * Extrude: -* Remove: Removes the selected navigation mesh edge. -* Fill: Fills between the selected navigation mesh vertices and forms a face. -* Grow Selection: Grows the selection by selecting the adjacent elements to the selected elements (Works for all vertex, edge and face structures) -* Connect: Connects the selected two navigation mesh vertices by drawing an edge between them. -* Subdivide: Divides the navigation mesh edge by putting a vertex on the middle of it. This vertex is connected to the adjacent vertices and divides the face of interest. -* Weld: Removes vertices forming the edge and makes the edge one single vertex. It connects the old adjacent vertices to the newly generated vertex. -* Import Faces From Prefabs: Imports faces which were exported for later use. -* Import Body: -* Make Quads When Possible: Selects adjacent triangle faces, which can construct quads (which do not form a concave polygon). This is not going to construct the most optimal nav mesh, having faces with the greatest surface areas, but it will locally select the triangles forming the greatest surface area. It will still reduce the total number of faces strongly. +* Remove: Удаляет выбранное ребро навигационной сетки. +* Fill: Заполняет пространство между выбранными вершинами навигационной сетки, образуя грань. +* Grow Selection: Расширяет выделение, добавляя элементы, соседние с уже выбранными (работает для всех структур — вершин, рёбер и граней). +* Connect: Соединяет две выбранные вершины навигационной сетки, проводя между ними ребро. +* Subdivide: Делит ребро навигационной сетки, помещая вершину в его середину. Эта вершина соединяется с соседними вершинами и делит соответствующую грань. +* Weld: Удаляет вершины, образующие ребро, и превращает ребро в одну вершину. Соединяет старые соседние вершины с новой вершиной. +* Import Faces From Prefabs: Импортирует грани, которые были экспортированы для последующего использования. +* Import Body: <неизвестно> +* Make Quads When Possible: Выбирает соседние треугольные грани, которые могут образовать четырёхугольники (не формирующие вогнутый многоугольник). Это не создаёт самую оптимальную навигационную сетку с гранями максимальной площади, но локально выбирает треугольники, образующие грань наибольшей площади. Тем не менее, это значительно сокращает общее число граней. -#### Debugging Tools +#### Инструменты отладки  -* X-Z Keys: Puts two different spheres per key, and when both are put, gives statistics about the path defined between these two spheres. -* Select Vertices Below Entities: The name implies the purpose. -* Select Unwalkable Edges: -* Fix Concave Faces: Makes the concave faces convex. -* Select Unconnected Faces: -* Calculate Auto Weld Points: -* Select Inverted Faces: Finds and selects the inverse faces, facing towards the terrain. -* Find Path: -* Paste Copied Faces: The name implies the purpose. -* Copy Selected Faces: The name implies the purpose. -* Export Faces as Prefab: Exports the selected faces for later use. -* Ensure Faces Are Not Below Ground: The name implies the puspose. -* Remove Unreachable Faces: Removes the faces which are not connected to any island, in which there is a spawn point. (Spawn points are decided according to the entities in Prefabs/editor_spawnpoints.xml, also entities containing AnimationPoint script.) -* Find Tight Faces: Finds faces whose surface area is below the desired value, and selects them. You can press the "delete" button to remove these faces. After doing this, do not forget to "Remove Unused Vertices", which I'll be mentioning a few lines below. -* Remove Unused Vertices: This will remove the vertices which are not connected to any face. -* Select Vertices At The Edges: Selects the vertices connected to only 2 edges, hence, not being a part of a continuous face component. -* Select Vertices Without Edges: This will just select the faces which are not connected to any edge or face. -* Mark Elevation Problem Faces: Faces having distance greater than 1.2 meters to the bottom (a mesh or the terrain) will be selected for debug purposes. +* X-Z Keys: Размещает по две разные сферы на клавишу, и когда обе размещены, выдаёт статистику о пути, определённом между этими двумя сферами. +* Select Vertices Below Entities: Название говорит само за себя. +* Select Unwalkable Edges: <неизвестно> +* Fix Concave Faces: Превращает вогнутые грани в выпуклые. +* Select Unconnected Faces: <неизвестно> +* Calculate Auto Weld Points: <неизвестно> +* Select Inverted Faces: Находит и выбирает инвертированные грани, обращённые к рельефу (terrain). +* Find Path: <неизвестно> +* Paste Copied Faces: Название говорит само за себя. +* Copy Selected Faces: Название говорит само за себя. +* Export Faces as Prefab: Экспортирует выбранные грани для последующего использования. +* Ensure Faces Are Not Below Ground: Название говорит само за себя. +* Remove Unreachable Faces: Удаляет грани, не связанные ни с одним островом, на котором есть точка появления (spawn point). (Точки появления определяются согласно сущностям в Prefabs/editor_spawnpoints.xml, а также сущностям, содержащим скрипт AnimationPoint.) +* Find Tight Faces: Находит грани, площадь поверхности которых меньше заданного значения, и выбирает их. Можно нажать кнопку "Delete", чтобы удалить эти грани. После этого не забудьте выполнить "Remove Unused Vertices", о чём будет сказано несколько строк ниже. +* Remove Unused Vertices: Удаляет вершины, не связанные ни с одной гранью. +* Select Vertices At The Edges: Выбирает вершины, связанные только с 2 рёбрами, то есть не являющиеся частью непрерывного компонента грани. +* Select Vertices Without Edges: Просто выбирает грани, не связанные ни с одним ребром или гранью. +* Mark Elevation Problem Faces: Для отладочных целей выбираются грани, расстояние которых до нижней поверхности (меша или рельефа) превышает 1,2 метра. -#### Auto Generation Parameters +#### Параметры автогенерации  -These parameters arrange the precision, extend and operation details of the navigation mesh generation. Explanation of the parameters are as following: +Эти параметры определяют точность, охват и детали операции генерации навигационной сетки. Пояснение параметров приведено ниже: -* Build Detailed Nav Mesh: Checking this box makes use of the following parameters and builds a detailed nav mesh according to them. If not checked, the following parameters won't make any difference. -* Cell Size: Defines the horizontal edge length of the sample voxel examined by the Recast Library. -* Cell Height: Defines the vertical edge length of the sample voxel examined by the Recast Library. -* Agent Max Slope: Maximum angle in which the agent can climb (in degrees). -* Agent Height: The name defines itself. -* Agent Max Climb: Maximum meters the agent can step on. -* Agent Radius: The name defines itself. -* Edge Max Length: Maximum possible edge length of the polygons generated by Recast. -* Edge Max Error: The maximum distance a simplfied contour's border edges should deviate the original raw contour. (Definition from the Recast document) -* Region Min Size: The minimum number of cells [voxels] allowed to form isolated island areas. (Definition from the Recast document) -* Region Merge Size: Any regions with a span count smaller than this value will, if possible, be merged with larger regions. (Definition from the Recast document) -* Detail Sample Distance: Sets the sampling distance to use when generating the detail mesh. (For height detail only.) (Definition from the Recast document) -* Detail Sample Max Error: The maximum distance the detail mesh surface should deviate from heightfield data. (For height detail only.) (Definition from the Recast document) +* Build Detailed Nav Mesh: Если этот флажок установлен, используются следующие параметры, и строится детализированная навигационная сетка в соответствии с ними. Если флажок не установлен, следующие параметры не будут иметь значения. +* Cell Size: Определяет длину горизонтального ребра воксела выборки, исследуемого библиотекой Recast. +* Cell Height: Определяет длину вертикального ребра воксела выборки, исследуемого библиотекой Recast. +* Agent Max Slope: Максимальный угол, на который агент может подниматься (в градусах). +* Agent Height: Название говорит само за себя. +* Agent Max Climb: Максимальное количество метров, на которое агент может наступить (ступенька). +* Agent Radius: Название говорит само за себя. +* Edge Max Length: Максимально возможная длина ребра полигонов, генерируемых Recast. +* Edge Max Error: Максимальное расстояние, на которое граничные рёбра упрощённого контура могут отклоняться от исходного необработанного контура. (Определение из документации Recast.) +* Region Min Size: Минимальное количество ячеек [вокселей], допустимое для формирования изолированных островных областей. (Определение из документации Recast.) +* Region Merge Size: Любые регионы с количеством спанов меньше этого значения будут, по возможности, объединены с более крупными регионами. (Определение из документации Recast.) +* Detail Sample Distance: Задаёт расстояние выборки, используемое при генерации детализированного меша. (Только для детализации по высоте.) (Определение из документации Recast.) +* Detail Sample Max Error: Максимальное расстояние, на которое поверхность детализированного меша может отклоняться от данных карты высот. (Только для детализации по высоте.) (Определение из документации Recast.) -### Auto Generation Steps -* First, fill in the blank fields in the parameters tab. You may prefer to stick to the default parameters as well. -* Click on the "Auto Generate" button (generation tools) and wait for the operation to end. -* Click on the "Make Quads When Possible" button (generation tools) to quadify the triangles which form a convex shape. -* Click on the "Find Tight Faces" button (debugging tools) to find and select the tight faces on the borders. -* Press the "Delete" button on the keyboard to delete these selected faces. -* If there are still tight faces appearing on the borders, apply the same procedure until it all ends. -* Click on the "Remove Unused Vertices" button (debugging tools) to remove vertices which are no longer connected to any face. -* Manually correct the regions which are broken due to the removed tight faces. -* You can debug and polish further using the tools mentioned before. +### Шаги автогенерации +* Сначала заполните пустые поля на вкладке параметров. Вы также можете придерживаться параметров по умолчанию. +* Нажмите кнопку "Auto Generate" (инструменты генерации) и дождитесь завершения операции. +* Нажмите кнопку "Make Quads When Possible" (инструменты генерации), чтобы превратить в четырёхугольники треугольники, образующие выпуклую форму. +* Нажмите кнопку "Find Tight Faces" (инструменты отладки), чтобы найти и выбрать узкие грани на границах. +* Нажмите клавишу "Delete" на клавиатуре, чтобы удалить выбранные грани. +* Если на границах всё ещё появляются узкие грани, повторяйте ту же процедуру, пока они не исчезнут. +* Нажмите кнопку "Remove Unused Vertices" (инструменты отладки), чтобы удалить вершины, больше не связанные ни с одной гранью. +* Вручную исправьте регионы, повреждённые из-за удалённых узких граней. +* Вы можете продолжить отладку и доработку с помощью упомянутых выше инструментов. diff --git a/docs/content/russian/Editor/Scene Editor/path_editing.md b/docs/content/russian/Editor/Scene Editor/path_editing.md index 0ebb76bf..8f1eb18a 100644 --- a/docs/content/russian/Editor/Scene Editor/path_editing.md +++ b/docs/content/russian/Editor/Scene Editor/path_editing.md @@ -1,16 +1,16 @@ +++ -title = "Path Editing" +title = "Редактирование путей" description = "" weight = 1 +ai_translated = true +++ -Level designer can easily add, edit or delete paths and path points by the scene editor. +Левел-дизайнер может легко добавлять, редактировать или удалять пути и точки путей (path points) с помощью редактора сцен (Scene Editor). -##### Adding a new path +##### Добавление нового пути -User can use the Add New Path button at the upper toolbar. User should enter a unique name for every path. After the path is added, the editor's editing state will become "Path Select". By spacing either space or the "Add a new path point" button from the upper toolbar, user can transition to the "Path Node Add" mode and start adding new path nodes. At every click one more path node will be added to the current selected path. By pressing space again, user can start selecting and editing the existing path nodes. Every path node has three transform points. These are the center(cube) and the two tangents(spheres). User can hover onto them and select them by pressing the left mouse button. Then, pressing "T" button will spawn the transformation triad which can be used to move these points. Every operation can be undone by the "Control z" key combination. Selected path nodes can be deleted via the "Del" key. A path can be deleted by selecting the path and hitting the "Del" button. Also, to select another path, one can just hover into one of its node poinmts and pressing the left mouse button. +Пользователь может использовать кнопку Add New Path (Добавить новый путь) на верхней панели инструментов. Для каждого пути пользователь должен ввести уникальное имя. После добавления пути состояние редактирования редактора станет «Path Select» (Выбор пути). Нажав пробел или кнопку «Add a new path point» (Добавить новую точку пути) на верхней панели инструментов, пользователь может перейти в режим «Path Node Add» (Добавление узла пути) и начать добавлять новые узлы пути. При каждом клике к текущему выбранному пути будет добавляться ещё один узел пути. Повторно нажав пробел, пользователь может начать выбирать и редактировать существующие узлы пути. У каждого узла пути есть три точки трансформации. Это центр (куб) и две касательные (сферы). Пользователь может навести на них курсор и выбрать их, нажав левую кнопку мыши. Затем нажатие кнопки «T» вызовет триаду трансформации, которую можно использовать для перемещения этих точек. Любую операцию можно отменить комбинацией клавиш «Control z». Выбранные узлы пути можно удалить клавишей «Del». Путь можно удалить, выбрав его и нажав кнопку «Del». Также, чтобы выбрать другой путь, можно просто навести курсор на одну из его точек узла и нажать левую кнопку мыши. -| Add a new path | Add a new path point | Select a path point | +| Добавление нового пути | Добавление новой точки пути | Выбор точки пути | | ------------ | ------------ | ------------ | |  |  |  | - diff --git a/docs/content/russian/Editor/Scene Editor/prt.md b/docs/content/russian/Editor/Scene Editor/prt.md index 1ad3fabf..d10bdf74 100644 --- a/docs/content/russian/Editor/Scene Editor/prt.md +++ b/docs/content/russian/Editor/Scene Editor/prt.md @@ -1,85 +1,84 @@ +++ -title = "Precomputed Radiance Transfer - GI System" +title = "Precomputed Radiance Transfer - система глобального освещения" +ai_translated = true [menu.main] identifier = "prt_system" parent = "core_components" +++ -We introduce a new global illumination system to the engine. It is based on a pre-baked system called "Precomputed Radiance Transfer". This technique allow us to bake the local ambient in the scene and display it in an optimized manner at runtime. Baked data is independent from the atmospheres. Thus, we can light the scene with the same bake data for every atmosphere. +Мы представляем новую систему глобального освещения (global illumination) в движке. Она основана на предварительно запекаемой системе под названием "Precomputed Radiance Transfer" (предварительно вычисленный перенос излучения). Эта техника позволяет нам запекать локальную окружающую среду (ambient) в сцене и отображать её оптимизированным образом во время выполнения. Запечённые данные не зависят от атмосфер. Таким образом, мы можем освещать сцену одними и теми же данными запекания для любой атмосферы. -| With | Without | +| С системой | Без системы | | ------ | ------------ | |  |  | -### Baking Procedure +### Процедура запекания -Scene baking is divided into a couple of parts: +Запекание сцены делится на несколько частей: -- First, the artist should place the border probes to identify the GI boundaries of the scene. +- Сначала художник должен разместить пограничные пробы (border probes), чтобы определить границы GI (глобального освещения) сцены. -Side Note 1: If you minimize the GI boundaries as much as possible(not extending it to distant places from navigatable area) , you can decrease the grid dimensions and thus you will have more precision inside the town where it matters the most. For town scenes, we generally use grid dimensions of 1.5 meters width and 2.5 meters height. +Примечание 1: Если минимизировать границы GI насколько это возможно (не распространяя их на удалённые места от проходимой зоны), можно уменьшить размеры сетки (grid), и таким образом у вас будет больше точности внутри города, где это наиболее важно. Для городских сцен мы обычно используем размеры сетки шириной 1,5 метра и высотой 2,5 метра. -Side Note 2: For the pixels outside the GI borders, we use a fallback probe from the scene. The default is the highest active probe near to the left corner of the GI order. Artist can select any other probe from the scene by first selecting probe and checking the "Fallback Probe" checkbox in the UI. +Примечание 2: Для пикселей за пределами границ GI мы используем резервную пробу (fallback probe) из сцены. По умолчанию это самая высокая активная проба, ближайшая к левому углу области GI. Художник может выбрать любую другую пробу из сцены, сначала выбрав пробу и отметив флажок "Fallback Probe" в интерфейсе.   -- AT the next pass, the GI probes are created. The initial positions of the probes computed automatically by using the navigation mesh of the scene. With the navigation mesh, we place the probes where the agents can move and also to everywhere visible from those navigation points. The probes are generated within a 3d grid structure. A directional ambient data is computed for every probe position. Using these ambient light values, every pixel in the screen is illuminated by the nearest 8 probes. In some cases, when the lighting between neighbour probes have a very high difference, light or shadow leaking can occur. In order to fix these issues, we render shadowmaps from the probes just like point lights. Probes with shadowmaps are named as "Visibility Probes". For memory usage issues, there is a limit for these Visibility Probes, which is 2048. At the automatic placement phase, the system also tries to find the most probable leak positions and assign those probes as Visibility Probes. It takes into account the ambient light difference. For additional leak fixes, the system leaves the last 5 percent Visibility Probe limit empty, so that the scene designer can fix the remaining leak issues. +- На следующем этапе создаются пробы GI. Начальные позиции проб вычисляются автоматически с использованием навигационной сетки (navigation mesh) сцены. С помощью навигационной сетки мы размещаем пробы там, где могут перемещаться агенты, а также везде, что видно из этих навигационных точек. Пробы генерируются в рамках 3D-сеточной структуры. Для каждой позиции пробы вычисляются данные направленного окружающего освещения (directional ambient). Используя эти значения окружающего освещения, каждый пиксель на экране освещается 8 ближайшими пробами. В некоторых случаях, когда разница в освещении между соседними пробами очень велика, может произойти утечка света или тени (light or shadow leaking). Чтобы исправить эти проблемы, мы рендерим карты теней (shadowmaps) от проб так же, как от точечных источников света. Пробы с картами теней называются "пробами видимости" (Visibility Probes). Из-за проблем с использованием памяти для таких проб видимости существует ограничение — 2048. На этапе автоматического размещения система также пытается найти наиболее вероятные места утечек и назначить соответствующие пробы в качестве проб видимости. При этом учитывается разница в окружающем освещении. Для дополнительного устранения утечек система оставляет пустыми последние 5 процентов лимита проб видимости, чтобы дизайнер сцены мог исправить оставшиеся проблемы с утечками.   -### PRT Files +### Файлы PRT -Just like the scene edit data system, prt data is divided into two parts. prt_data.bin is located inside the SceneObj folder and is the compressed version which is stripped of any editing data. This file should be sent to the source control. The other file is the edit data file. It is very big (at around 2 - 3 gb) and automaticaly sent to the edit data folder inside the network. Once you open a pre-baked scene in editor, only the compressed data is loaded. To be able to edit the bake data, you should Load the edit data with the 'Load' button in the "General Info" panel of the PrtInspector. +Как и в системе данных редактирования сцены, данные prt делятся на две части. Файл prt_data.bin находится внутри папки SceneObj и представляет собой сжатую версию, лишённую каких-либо данных редактирования. Этот файл следует отправлять в систему контроля версий. Другой файл — это файл данных редактирования. Он очень большой (около 2–3 ГБ) и автоматически отправляется в папку данных редактирования в сети. При открытии уже запечённой сцены в редакторе загружаются только сжатые данные. Чтобы иметь возможность редактировать данные запекания, вам нужно загрузить данные редактирования с помощью кнопки 'Load' на панели "General Info" инспектора PrtInspector. -**Important Node** : After any changes to the prt data, do not forget to save the data with the 'Save' button in the "General Info" panel of the PrtInspector. +**Важное замечание**: После внесения любых изменений в данные prt не забудьте сохранить данные с помощью кнопки 'Save' на панели "General Info" инспектора PrtInspector. -### PRT Operations +### Операции PRT  -- **Load** : Loads the edit data from the server. -- **Save** : Saves the current edit data to the server. -- **Auto Height Boundary** : Adjusts the PRT boundary probes's height to the min/max of the scene. -- **Bake Single Level** : Bakes the scene with the current levels, should be used for the interior scenes -- **Bake All Levels** : Bakes the scene with the pre-defined multiple levels(namely level-1/level-2/level-3 and siege/civilian) combinations. - - -### Probe Placement Parameters: -- **Grid Width** : Determines the probe grid cell size in XY plane. For towns, you can use 1.5. For interiors scenes, you can use between 0.5 to 1.0. -- **Grid Height** : Determines the probe grid cell height. For towns, you should use a value near 2.5. For interiors scenes, you can use between 0.5 to 1.0. - -### Selection Tools: -To ensure fast and smooth editing of probes, various selection tools are implemented. - -- **Select All** : Selects all probes. -- **Grow** : Grows the selection to include neighbour probes in XY plane. -- **Shrink** : Shrink the selection to only include the inner neighbour probes in XY plane. -- **Fill** : Finds the inner probes of the current selected probe group and selectes them. -- **Select Border** : Finds and selects the border probes of the current selection. -- **Select Inner Border** : Finds and selects the inner border of the current selection. -- **Select Outer Border** : Finds and selects the outer border of the current selection. -- **Lasso Tool** : We implemented a screen space lasso tool for easy selection of a group of probes. It can be started by pressing 'r' and finished by either double clik or pressing 'r' again. +- **Load (Загрузить)**: Загружает данные редактирования с сервера. +- **Save (Сохранить)**: Сохраняет текущие данные редактирования на сервер. +- **Auto Height Boundary (Автоматическая граница по высоте)**: Регулирует высоту граничных проб PRT в соответствии с минимумом/максимумом сцены. +- **Bake Single Level (Запечь один уровень)**: Запекает сцену с текущими уровнями, следует использовать для сцен интерьеров. +- **Bake All Levels (Запечь все уровни)**: Запекает сцену с заранее определёнными комбинациями нескольких уровней (а именно level-1/level-2/level-3 и siege/civilian). - -### Visibility Tools +### Параметры размещения проб: +- **Grid Width (Ширина сетки)**: Определяет размер ячейки сетки проб в плоскости XY. Для городов можно использовать значение 1,5. Для сцен интерьеров можно использовать значение от 0,5 до 1,0. +- **Grid Height (Высота сетки)**: Определяет высоту ячейки сетки проб. Для городов следует использовать значение около 2,5. Для сцен интерьеров можно использовать значение от 0,5 до 1,0. + +### Инструменты выделения: +Для обеспечения быстрого и плавного редактирования проб реализованы различные инструменты выделения. -- **Show Active Probes** : Shows all active probes -- **Show Deactive Probes** : Show deactived probes. -- **Show Visibility Probes** : Show the Visibility probes (the ones with the visibility calculation to prevent leaking). -- **Level To Show** : Selects the Z level to show. -1 means all levels. -- **Show Probe Radius** : Determines the probe radius for debug visualization. -- **Box Tool** : Enables a mode where you . +- **Select All (Выбрать всё)**: Выбирает все пробы. +- **Grow (Расширить)**: Расширяет выделение, включая соседние пробы в плоскости XY. +- **Shrink (Сжать)**: Сжимает выделение, оставляя только внутренние соседние пробы в плоскости XY. +- **Fill (Заполнить)**: Находит внутренние пробы текущей выбранной группы проб и выбирает их. +- **Select Border (Выбрать границу)**: Находит и выбирает граничные пробы текущего выделения. +- **Select Inner Border (Выбрать внутреннюю границу)**: Находит и выбирает внутреннюю границу текущего выделения. +- **Select Outer Border (Выбрать внешнюю границу)**: Находит и выбирает внешнюю границу текущего выделения. +- **Lasso Tool (Инструмент "Лассо")**: Мы реализовали инструмент лассо в экранном пространстве для удобного выбора группы проб. Его можно запустить, нажав 'r', и завершить двойным щелчком или повторным нажатием 'r'. + + -Side Not : This system only renders the nearest 100 probes with respect to the camera. +### Инструменты видимости -### Useful Shortcuts +- **Show Active Probes (Показать активные пробы)**: Показывает все активные пробы. +- **Show Deactive Probes (Показать неактивные пробы)**: Показывает деактивированные пробы. +- **Show Visibility Probes (Показать пробы видимости)**: Показывает пробы видимости (те, у которых есть расчёт видимости для предотвращения утечек). +- **Level To Show (Отображаемый уровень)**: Выбирает Z-уровень для отображения. -1 означает все уровни. +- **Show Probe Radius (Показать радиус пробы)**: Определяет радиус пробы для визуализации отладки. +- **Box Tool (Инструмент "Бокс")**: Включает режим, в котором вы . -- **Left Ctrl + x**: Enable/Disable the selected probes -- **Left Ctrl + c**: Toggles the "Visibility Probe" status -- **Left Alt + Left Mouse Click**: Select the probes that influences a pixel -(very neat tool for fixing the leak issue, select the pixel and use the toggle visibility status shortcut to fix the issue) +Примечание: Эта система рендерит только 100 ближайших к камере проб. +### Полезные сочетания клавиш +- **Левый Ctrl + x**: Включить/выключить выбранные пробы +- **Левый Ctrl + c**: Переключить статус "Visibility Probe" (проба видимости) +- **Левый Alt + левая кнопка мыши**: Выбрать пробы, влияющие на пиксель +(очень удобный инструмент для исправления утечек — выберите пиксель и используйте сочетание клавиш переключения статуса видимости, чтобы устранить проблему) diff --git a/docs/content/russian/Editor/Scene Editor/terrain_creation.md b/docs/content/russian/Editor/Scene Editor/terrain_creation.md index 2454bfd9..e0c138e9 100644 --- a/docs/content/russian/Editor/Scene Editor/terrain_creation.md +++ b/docs/content/russian/Editor/Scene Editor/terrain_creation.md @@ -1,33 +1,33 @@ +++ -title = "Terrain Creation" +title = "Создание рельефа" description = "" weight = 1 +ai_translated = true +++ ------------------ -### Create a new terrain ### -Terrain creation, removal, and node modifications can be done in Terrain Inspector > Properties tab. -Terrain node count in both dimensions, their resolution and size can be specified in New Terrain Properties panel. -This parameters must be specified proir to the creation, although they can be canged per-node basis later. +### Создание нового рельефа ### +Создание, удаление рельефа и изменение узлов (node) можно выполнить на вкладке Terrain Inspector > Properties. +Количество узлов рельефа по обоим измерениям, их разрешение и размер можно задать на панели New Terrain Properties. +Эти параметры должны быть заданы до создания, хотя их можно изменить позже для каждого узла отдельно. | ---- | ----  |  -### Adjusting node properties ### -Node resolution can be adjusted by selection nodes (Hold CTRL for multiple selection)m and change the resolution parameter in Node Properties panel. -This feature can be used to further optimize terrain in places where resolution is not that important (eg. Outside of Settlemets where player is not allowed to go, or nodes that are completely under water). +### Настройка свойств узлов ### +Разрешение узла можно настроить, выбрав узлы (удерживайте CTRL для множественного выбора) и изменив параметр resolution (разрешение) на панели Node Properties. +Эту функцию можно использовать для дальнейшей оптимизации рельефа в местах, где разрешение не так важно (например, за пределами поселений, куда игроку не разрешено заходить, или в узлах, полностью находящихся под водой).  -### Import / Export Materialmaps or Heightmap ### -To support external terrain generation softwares, engine can Import / Export terrain layer materialmaps or heightmap. -You can easly create believable terrains by importing various layers (Debris, flowmap, vegetation, bedrock), and 16-bit heightmaps. -To import a materialmap, first you must create a new terrain layer, after selecting this layer, go to Properties tab, select some nodes (CTRL + A to select all) and hit Import Materialmap button. This will open file selection dialog, you can select any 8-bit (grayscale) texture to use as materialmap. -You can do the same to import Heightmap, heightmaps can be 8-bit or 16-bit (png or raw). +### Импорт / экспорт карт материалов или карты высот ### +Для поддержки внешнего программного обеспечения для генерации рельефа движок может импортировать / экспортировать карты материалов слоёв рельефа или карту высот. +Вы можете легко создавать достоверные рельефы, импортируя различные слои (мусор (debris), карту потоков (flowmap), растительность, коренную породу (bedrock)) и 16-битные карты высот. +Чтобы импортировать карту материалов, сначала нужно создать новый слой рельефа, затем, выбрав этот слой, перейти на вкладку Properties, выбрать несколько узлов (CTRL + A, чтобы выбрать все) и нажать кнопку Import Materialmap. Откроется диалог выбора файла, в котором можно выбрать любую 8-битную (в оттенках серого) текстуру для использования в качестве карты материалов. +Аналогичным образом можно импортировать карту высот (Heightmap); карты высот могут быть 8-битными или 16-битными (png или raw). | | | | ---- | ---- | ---- | ---- | ----  |  |  |  |  - diff --git a/docs/content/russian/Editor/Scene Editor/terrain_mesh_blend.md b/docs/content/russian/Editor/Scene Editor/terrain_mesh_blend.md index b5b97bb2..d8c87743 100644 --- a/docs/content/russian/Editor/Scene Editor/terrain_mesh_blend.md +++ b/docs/content/russian/Editor/Scene Editor/terrain_mesh_blend.md @@ -1,39 +1,39 @@ +++ -title = "Terrain Mesh Blend System" +title = "Система смешивания меша с ландшафтом" +ai_translated = true [menu.main] identifier = "terrain_mesh_blend_system" parent = "core_components" +++ -We introduce a new terrain mesh blending system. Certain terrain layers can blend into chosen meshes. Blend height, smoothness and random height offsets can be changed. These values can be saved to prefabs and can also be changed in scene per mesh. Heightmap blending can also be used to change the blending behaviour with respect to the mesh's heightmap. +Мы представляем новую систему смешивания меша с ландшафтом (Terrain Mesh Blend). Определённые слои ландшафта могут плавно сливаться с выбранными мешами. Высоту смешивания, плавность и случайные смещения высоты можно изменять. Эти значения можно сохранять в префабах, а также изменять на сцене для каждого меша отдельно. Смешивание по карте высот также можно использовать для изменения поведения смешивания относительно карты высот меша. -| With Blending | Without Blending | +| Со смешиванием | Без смешивания | | ------ | ------------ | |  |  | -### Terrain Layer Restrictions +### Ограничения слоёв ландшафта -Terrain layers should satisfy some restrictions before they are eligible to be a mesh blend layer. +Слои ландшафта должны удовлетворять некоторым ограничениям, прежде чем они смогут стать слоем смешивания с мешем. -- Diffuse texture should have (2048 , 2048) dimensions and have a DXT1 format(without alpha). -- Normal texture should have (2048 , 2048) dimensions and have a BC5 format. -- Specular texture should have (2048 , 2048) dimensions and have a DXT1 format. -- Layer should not have 'diffuse alpha' or 'ground slope' flags enabled. +- Диффузная текстура должна иметь размер (2048, 2048) и формат DXT1 (без альфа-канала). +- Текстура нормалей должна иметь размер (2048, 2048) и формат BC5. +- Текстура бликов (specular) должна иметь размер (2048, 2048) и формат DXT1. +- У слоя не должны быть включены флаги «diffuse alpha» или «ground slope». -### Material Properties +### Свойства материала -The mesh should have a material with shader "terrain_mesh_blend_shader". To enable heightmap blending, one should assign an heightmap texture and enable the shader flag "". +У меша должен быть материал с шейдером "terrain_mesh_blend_shader". Чтобы включить смешивание по карте высот, необходимо назначить текстуру карты высот и включить флаг шейдера "". -### Mesh Properties +### Свойства меша -One can change the mesh's properties from the Components/Mesh/Vector Arguments windows in Entity Inspector. +Свойства меша можно изменить в окнах Components/Mesh/Vector Arguments в инспекторе сущностей (Entity Inspector). -- Blend Height Threshold : Maximum distance for terrain blend -- Blend Smoothness : Higher means more smooth transitions -- Random Amount : Blend height threshold can be incresed or decreased with this value with respect to the position of pixel -- Random Tile : Adjusts the tile of the random heightmap adjustment -- Heightmap Factor : Controls the heightmap factor of the mesh. More means less blending in the higher parts of the heightmap. +- Blend Height Threshold (порог высоты смешивания): максимальное расстояние для смешивания с ландшафтом +- Blend Smoothness (плавность смешивания): чем выше значение, тем более плавные переходы +- Random Amount (величина случайности): с помощью этого значения порог высоты смешивания может увеличиваться или уменьшаться в зависимости от положения пикселя +- Random Tile (случайное замощение): регулирует замощение (tile) случайной корректировки карты высот +- Heightmap Factor (фактор карты высот): управляет фактором карты высот меша. Чем больше значение, тем меньше смешивание в более высоких частях карты высот.  - diff --git a/docs/content/russian/Editor/_index.md b/docs/content/russian/Editor/_index.md index f424376c..e8cf7140 100644 --- a/docs/content/russian/Editor/_index.md +++ b/docs/content/russian/Editor/_index.md @@ -1,6 +1,6 @@ +++ title = "Редактор" -description = "editor" +description = "Редактор" weight = 4 +++ diff --git a/docs/content/russian/Multiplayer/_index.md b/docs/content/russian/Multiplayer/_index.md index 9419cf52..d846e5d2 100644 --- a/docs/content/russian/Multiplayer/_index.md +++ b/docs/content/russian/Multiplayer/_index.md @@ -1,5 +1,5 @@ +++ -title = "Multiplayer" +title = "Мультиплеер" description = "" weight = 30 +++ diff --git a/docs/content/russian/Multiplayer/custom_game_mode.md b/docs/content/russian/Multiplayer/custom_game_mode.md index 7bba6a49..5a435e0a 100644 --- a/docs/content/russian/Multiplayer/custom_game_mode.md +++ b/docs/content/russian/Multiplayer/custom_game_mode.md @@ -1,27 +1,28 @@ +++ -title = "Creating a Custom Game Mode" +title = "Создание пользовательского игрового режима" description = "" weight = 10 +ai_translated = true +++ -#### Prerequisites -To make a custom MP game mode, you first need to create your module’s folder under the `Modules` folder of your games installation. Inside your module’s folder, you need to create a `bin` folder for your DLL files and a `SubModule.xml` file for your module’s definition and additional data. +#### Предварительные требования +Чтобы создать пользовательский MP игровой режим, вам сначала нужно создать папку вашего модуля в папке `Modules` вашей установленной игры. Внутри папки вашего модуля вам нужно создать папку `bin` для ваших DLL-файлов и файл `SubModule.xml` для определения вашего модуля и дополнительных данных. -For programming, you need to have .NET Framework development tools installed. To do that, download Visual Studio 2022 Community Edition and install .NET 6 support. After that’s done, create a new Class Library project.\ +Для программирования вам потребуются установленные инструменты разработки .NET Framework. Для этого скачайте Visual Studio 2022 Community Edition и установите поддержку .NET 6. После этого создайте новый проект Class Library.\ -For the client side, add references to DLLs located in the `Win64_Shipping_Client` folder of your Mount & Blade II: Bannerlord installation. \\ -For the server side, add references to DLLs located in the `Win64_Shipping_Server` folder of your Mount & Blade II: Dedicated Server installation. +Для клиентской стороны добавьте ссылки на DLL-файлы, находящиеся в папке `Win64_Shipping_Client` вашей установки Mount & Blade II: Bannerlord. \\ +Для серверной стороны добавьте ссылки на DLL-файлы, находящиеся в папке `Win64_Shipping_Server` вашей установки Mount & Blade II: Dedicated Server. -Make sure the output directory of your project is: +Убедитесь, что выходной каталог вашего проекта следующий: -* `Win64_Shipping_Client` of your module’s `bin` folder for the client code. -* `Win64_Shipping_Server` of your module’s `bin` folder for the server code. +* `Win64_Shipping_Client` в папке `bin` вашего модуля для клиентского кода. +* `Win64_Shipping_Server` в папке `bin` вашего модуля для серверного кода. -After everything is set up, you can start programming your game mode. -Please note that the game mode created in this document with its full source code and additional data files are provided to you in a ZIP file. +После того как всё настроено, вы можете начать программировать свой игровой режим. +Обратите внимание, что игровой режим, созданный в этом документе, вместе с полным исходным кодом и дополнительными файлами данных, предоставляется вам в ZIP-архиве. -#### Module Definition File -Before starting defining behaviors of your game mode, you first need to fill the `SubModule.xml` file so the mod is defined. This file is where you give your mod a name, an ID, version and define its dependencies and DLL files. +#### Файл определения модуля +Прежде чем начать определять поведения вашего игрового режима, вам сначала нужно заполнить файл `SubModule.xml`, чтобы определить мод. В этом файле вы даёте вашему моду имя, ID, версию и определяете его зависимости и DLL-файлы. @@ -40,22 +41,22 @@ Before starting defining behaviors of your game mode, you first need to fill the -From this sample definition file, we can see the basic needs of a mod. For the `ModuleCategory` node, the value can be either `Multiplayer` or `Server` for MP mods. If the mod is a Multiplayer mod, it means that it is loaded for both client and server. Server mods are only loaded on the server side and can be used for management or analytics needs. +Из этого примера файла определения мы можем увидеть базовые потребности мода. Для узла `ModuleCategory` значением может быть либо `Multiplayer`, либо `Server` для MP модов. Если мод является мультиплеерным модом, это означает, что он загружается как на клиенте, так и на сервере. Серверные моды загружаются только на стороне сервера и могут использоваться для нужд управления или аналитики. -`SubModules` node defines DLL files that this mod creates and uses. Make sure the name of your DLL file and the name of your class that inherits `MBSubModuleBase` matches with the ones in this file. +Узел `SubModules` определяет DLL-файлы, которые создаёт и использует этот мод. Убедитесь, что имя вашего DLL-файла и имя вашего класса, наследующего `MBSubModuleBase`, совпадают с указанными в этом файле. -#### SubModule Class -To define your game mode in code, you need to create a class that inherits the `MBSubModuleBase` class. In this class, override `OnSubModuleLoad` method and add this line: +#### Класс SubModule +Чтобы определить ваш игровой режим в коде, вам нужно создать класс, наследующий класс `MBSubModuleBase`. В этом классе переопределите метод `OnSubModuleLoad` и добавьте эту строку: Module.CurrentModule.AddMultiplayerGameMode(new MissionMultiplayerBountyMPMode("BountyMP")) -The string given to the constructor is the name of your game mode. For this sample, we’re creating a game mode named `BountyMP`. To load XML files with text information, override `InitializeGameStarter` method, call the base method and add this line: +Строка, передаваемая в конструктор, является именем вашего игрового режима. Для данного примера мы создаём игровой режим под названием `BountyMP`. Чтобы загрузить XML-файлы с текстовой информацией, переопределите метод `InitializeGameStarter`, вызовите базовый метод и добавьте эту строку: game.GameTextManager.LoadGameTexts(ModuleHelper.GetModuleFullPath("BountyMP") + "ModuleData/multiplayer_strings.xml") -Again, both the module name and XML file name depend on your mod’s file names. +Опять же, и имя модуля, и имя XML-файла зависят от имён файлов вашего мода. -In the XML file, you can define the following so your game mode’s name show up on the server list: +В XML-файле вы можете определить следующее, чтобы название вашего игрового режима отображалось в списке серверов: @@ -65,10 +66,10 @@ In the XML file, you can define the following so your game mode’s name show up -Make sure IDs match up with the ones you defined in your code and module definition files. +Убедитесь, что ID совпадают с теми, что вы определили в файлах кода и определения модуля. -#### GameMode Class -To make the server start the mission with your game mode, you need to create a new class that inherits `MissionBasedMultiplayerGameMode`. In this class, override `StartMultiplayerGame` method like this **for your client module**: +#### Класс GameMode +Чтобы заставить сервер запустить миссию с вашим игровым режимом, вам нужно создать новый класс, наследующий `MissionBasedMultiplayerGameMode`. В этом классе переопределите метод `StartMultiplayerGame` следующим образом **для вашего клиентского модуля**: public override void StartMultiplayerGame(string scene) { MissionState.OpenNew("BountyMP", new MissionInitializerRecord(scene), @@ -98,7 +99,7 @@ To make the server start the mission with your game mode, you need to create a n ); } -In this class, override StartMultiplayerGame method like this for your server module: +В этом классе переопределите метод StartMultiplayerGame следующим образом для вашего серверного модуля: public override void StartMultiplayerGame(string scene) { MissionState.OpenNew("BountyMP", new MissionInitializerRecord(scene), @@ -129,27 +130,26 @@ In this class, override StartMultiplayerGame method like this for your server mo } -This method shows how a mission runs at an overview. All mission behaviors are loaded one by one and they all handle different aspects of the game. Depending on your game mode, you might want all of these or only some of these at your mode. Also please note that there are dependencies between some of these behaviors, meaning that if one is not present, others might not work correctly. In this example, there are two mission behaviors that you are not going to get if you have created a clean project with the steps mentioned in the first section. These two behaviors are the ones the modder creates to add their own game logic. These are `MissionMultiplayerBountyMP` and `MissionMultiplayerBountyMPClient`. The former manages the game mode from the server while the latter manages the game mode from the client side. Make sure that all shared and important data is on your server and synchronized properly. +Этот метод показывает в общих чертах, как работает миссия. Все поведения миссии (mission behaviors) загружаются одно за другим, и каждое из них отвечает за разные аспекты игры. В зависимости от вашего игрового режима вам может понадобиться либо всё это, либо только часть этого в вашем режиме. Также обратите внимание, что между некоторыми из этих поведений существуют зависимости, то есть если одно из них отсутствует, другие могут работать некорректно. В этом примере есть два поведения миссии, которых вы не получите, если создали чистый проект, следуя шагам, упомянутым в первом разделе. Эти два поведения — те, что создаёт сам моддер для добавления собственной игровой логики. Это `MissionMultiplayerBountyMP` и `MissionMultiplayerBountyMPClient`. Первый управляет игровым режимом со стороны сервера, а второй — со стороны клиента. Убедитесь, что все общие и важные данные находятся на вашем сервере и правильно синхронизируются. -#### Mission Behaviors -For all native game modes, the server side game mode logic class, `MissionMultiplayerBountyMP` in this example, inherits `MissionMultiplayerGameModeBase`. This class defines basic spawning and synchronization systems. Also for all native game modes, the client side game mode message handling logic class, `MissionMultiplayerBountyMPClient` in this example, inherits `MissionMultiplayerGameModeBaseClient`. There are several overrides available for this class that makes sure the registering and deregistering from message handlers happen at the correct time. +#### Поведения миссии (Mission Behaviors) +Для всех нативных игровых режимов класс логики игрового режима на стороне сервера, в данном примере `MissionMultiplayerBountyMP`, наследует `MissionMultiplayerGameModeBase`. Этот класс определяет базовые системы спавна и синхронизации. Также для всех нативных игровых режимов класс логики обработки сообщений игрового режима на стороне клиента, в данном примере `MissionMultiplayerBountyMPClient`, наследует `MissionMultiplayerGameModeBaseClient`. Для этого класса доступно несколько переопределений, которые обеспечивают правильное время регистрации и отмены регистрации обработчиков сообщений. -#### Mission Representatives -In native game modes, Mission Representative classes are added to all clients to handle game mode specific data and logic. From this representative class, the client can query various things about the game mode depending on the situation. The server can also use a client’s mission representative to calculate various things, including gold gains, flag information and more. Contents of this class are dependent on the game mode itself, the base class of Mission Representative only has the gold and controlled agent of the client. In the example, it is `BountyMPMissionRepresentative`. Mission Representatives are added in the server game mode Mission Behavior class mentioned in the previous section. +#### Представители миссии (Mission Representatives) +В нативных игровых режимах классы Mission Representative добавляются всем клиентам для обработки данных и логики, специфичных для игрового режима. Из этого класса представителя клиент может запрашивать различную информацию об игровом режиме в зависимости от ситуации. Сервер также может использовать представителя миссии клиента для вычисления различных значений, включая прирост золота, информацию о флагах и прочее. Содержимое этого класса зависит от самого игрового режима, базовый класс Mission Representative содержит только золото и управляемого агента клиента. В данном примере это `BountyMPMissionRepresentative`. Представители миссии добавляются в классе поведения миссии игрового режима на стороне сервера, упомянутом в предыдущем разделе. -#### Hosting a Modded Custom Server -To host a custom server with mods, you can use the launch command like the following: +#### Хостинг моддированного пользовательского сервера +Чтобы разместить пользовательский сервер с модами, вы можете использовать команду запуска следующего вида: DedicatedCustomServer.Starter.exe _MODULES_*Native*Multiplayer*YOUR_MODULE_NAME_1*YOUR_MODULE_NAME_2*_MODULES_ -In between asterisk characters, you can put the name of any mod you want. +Между символами звёздочки вы можете указать имя любого нужного вам мода. -The file you've provided to `/dedicatedcustomserverconfigfile` parameter can also have the name of your custom game mode in it. +Файл, который вы передали в параметр `/dedicatedcustomserverconfigfile`, также может содержать имя вашего пользовательского игрового режима. -#### Sample Mod -You can find a sample mod that adds a new MP Game Mode [here](https://download.taleworlds.com/BountyMP.zip). Please note that there might be small bugs in the sample mod, since it's not a complete and polished official game mode. +#### Пример мода +Вы можете найти пример мода, который добавляет новый MP игровой режим, [здесь](https://download.taleworlds.com/BountyMP.zip). Обратите внимание, что в примере мода могут быть небольшие ошибки, поскольку это не завершённый и не отполированный официальный игровой режим. -To compile the client side of the sample, you need to have `Mount & Blade II: Bannerlord` installed. - -To compile the server side of the sample, you need to have `Mount & Blade II: Dedicated Server` installed. +Чтобы скомпилировать клиентскую часть примера, у вас должна быть установлена `Mount & Blade II: Bannerlord`. +Чтобы скомпилировать серверную часть примера, у вас должен быть установлен `Mount & Blade II: Dedicated Server`. diff --git a/docs/content/russian/Multiplayer/hosting_server.md b/docs/content/russian/Multiplayer/hosting_server.md index 9023fee8..221221f7 100644 --- a/docs/content/russian/Multiplayer/hosting_server.md +++ b/docs/content/russian/Multiplayer/hosting_server.md @@ -1,228 +1,229 @@ +++ -title = "Hosting a Custom Server" +title = "Размещение пользовательского сервера" description = "" weight = 5 +ai_translated = true +++ -## Installing -Enable Tools within your Steam Library. `Mount & Blade II: Dedicated Server` should appear on your list. Download and install it. +## Установка +Включите Tools в своей библиотеке Steam. В списке должен появиться `Mount & Blade II: Dedicated Server`. Загрузите и установите его. -## Hosting -By default, dedicated servers use UDP port 7210. You must have a visible (public) IP address on the internet as well as the aforementioned port being accessible. +## Размещение сервера +По умолчанию выделенные серверы используют UDP-порт 7210. У вас должен быть видимый (публичный) IP-адрес в интернете, а также должен быть доступен указанный порт. -Anonymous hosting is not supported. You will have to create a server token by going in-game first. +Анонимный хостинг не поддерживается. Вам нужно будет сначала создать токен сервера, зайдя в игру. -### Generating a Token -Launch `Mount & Blade II: Bannerlord` multiplayer and log into the game lobby: +### Генерация токена +Запустите мультиплеер `Mount & Blade II: Bannerlord` и войдите в игровое лобби: -Open the game console by pressing `ALT` + `tilde key (~)`: +Откройте игровую консоль, нажав `ALT` + `клавиша тильды (~)`: -Type `customserver.gettoken` in the textbox and press enter: +Введите `customserver.gettoken` в текстовое поле и нажмите Enter: -Your token has been generated and saved under your `Documents\Mount & Blade II Bannerlord\Tokens` folder: +Ваш токен был сгенерирован и сохранён в папке `Documents\Mount & Blade II Bannerlord\Tokens`: -If you are planning to host the dedicated server on the same computer where you installed Bannerlord, this is all you have to do. But if you are planning to host using a different computer, please copy this token file to the target computer’s `Documents\Mount & Blade II Bannerlord\Tokens` folder. There is also one other alternative method shown in the Launch Arguments section below. +Если вы планируете размещать выделенный сервер на том же компьютере, на котором установлен Bannerlord, это всё, что вам нужно сделать. Но если вы планируете использовать для хостинга другой компьютер, пожалуйста, скопируйте этот файл токена в папку `Documents\Mount & Blade II Bannerlord\Tokens` на целевом компьютере. Существует также альтернативный способ, описанный в разделе Launch Arguments ниже. -Beware that the generated token is tied to your Bannerlord account. Any abuse would be traced back to the user who originally generated the token. **We recommend keeping it private**, and not sharing it with other people. +Имейте в виду, что сгенерированный токен привязан к вашему аккаунту Bannerlord. Любое злоупотребление будет отслежено до пользователя, который изначально сгенерировал токен. **Мы рекомендуем хранить его в тайне** и не передавать другим людям. -Also remember that **your token expires after 3 months** due to security reasons at which point you can replace it by generating a new one. +Также помните, что **срок действия вашего токена истекает через 3 месяца** по соображениям безопасности, после чего вы можете заменить его, сгенерировав новый. -### Server Administration -You can administrate your server by typing commands in your server’s console (that opens up when launching the server). +### Администрирование сервера +Вы можете администрировать свой сервер, вводя команды в консоли сервера (которая открывается при запуске сервера). -By typing `list` and pressing `enter`, you will get all the available commands in the dedicated server: +Введя `list` и нажав `Enter`, вы получите список всех доступных команд выделенного сервера: -For example, to get a simple server running, you can type the following commands into your console: +Например, чтобы запустить простой сервер, вы можете ввести в консоль следующие команды: * `ServerName Custom Dedicated Beta Test` * `GameType TeamDeathmatch` * `start_game` * `start_mission` -By executing these commands, you will make your custom server visible and accessible to all players. +Выполнив эти команды, вы сделаете свой пользовательский сервер видимым и доступным для всех игроков. -With the `ServerName` and `GameType` commands, you are simply setting the name of your server and setting your game mode. +С помощью команд `ServerName` и `GameType` вы просто задаёте имя своего сервера и устанавливаете режим игры. -With the `start_game` command, you are starting to host your server. Your server becomes visible to all players. Any player who enters your server will wait in the intermission state. +С помощью команды `start_game` вы начинаете хостинг своего сервера. Ваш сервер становится видимым для всех игроков. Любой игрок, зашедший на ваш сервер, будет ожидать в состоянии перерыва (intermission). -With the `start_mission` command, your server will switch into mission mode and players will be able to play the game. +С помощью команды `start_mission` ваш сервер переключится в режим миссии, и игроки смогут играть. -You can also use the shorthand `start_game_and_mission` instead of the two commands. +Вы также можете использовать сокращение `start_game_and_mission` вместо двух команд. -#### Tips & Tricks +#### Советы и рекомендации -##### Configuration Files -Instead of executing commands one at a time with the server console, you can specify a configuration file to run on initialization, which will have its contents executed line by line. +##### Файлы конфигурации +Вместо того чтобы выполнять команды по одной в консоли сервера, вы можете указать файл конфигурации для запуска при инициализации, содержимое которого будет выполняться построчно. -You can find sample configuration files within the Native module directory (`Modules\Native\ds_config_*.txt`). Note that currently, your own configuration files must also reside within this same directory to be found by the server. See the launch arguments section below for how you can specify a configuration file to be run. +Вы можете найти примеры файлов конфигурации в директории модуля Native (`Modules\Native\ds_config_*.txt`). Обратите внимание, что в настоящее время ваши собственные файлы конфигурации также должны находиться в этой же директории, чтобы сервер мог их найти. См. раздел о параметрах запуска ниже, чтобы узнать, как указать файл конфигурации для запуска. -##### Launch Arguments -There are a few particularly useful launch arguments at the moment: +##### Параметры запуска +В настоящее время есть несколько особенно полезных параметров запуска: `/dedicatedcustomserverconfigfile [configuration_file_name]` -Specify a configuration file to be run as seen in the Configuration Files section above. +Указывает файл конфигурации для запуска, как описано в разделе «Файлы конфигурации» выше. `/dedicatedcustomserverauthtoken [authentication_token_contents]` -When the token is passed through the launch argument, a local file containing the token is not required. +Когда токен передаётся через параметр запуска, локальный файл, содержащий токен, не требуется. `/DisableErrorReporting` -Disables the Crash Uploader popup and automatic error reporting. +Отключает всплывающее окно Crash Uploader и автоматическую отправку отчётов об ошибках. `/LogOutputPath [output_path]` -Sets the log output directory of the server. Path should be in double quotes. +Задаёт директорию вывода логов сервера. Путь должен быть указан в двойных кавычках. -`/port [number]` Optionally specify a port number to run the server from, useful for using ports other than the default. +`/port [number]` Опционально позволяет указать номер порта для запуска сервера, полезно при использовании портов, отличных от стандартного. -##### Log Files -By default, log files for the custom server can be found in your ProgramData directory on Windows (`%programdata%\Mount and Blade II Bannerlord\logs`). +##### Файлы журналов +По умолчанию файлы журналов для пользовательского сервера можно найти в директории ProgramData на Windows (`%programdata%\Mount and Blade II Bannerlord\logs`). -##### Automated Battle Count -By using the command `set_automated_battle_count` before `enable_automated_battle_switching`, you can set the number of missions to be played before the server shuts down. +##### Автоматический подсчёт боёв +Используя команду `set_automated_battle_count` перед `enable_automated_battle_switching`, вы можете задать количество миссий, которые будут сыграны до завершения работы сервера. -For example, `set_automated_battle_count 10` will have the server play 10 missions and shut down. If you would like to have an unlimited number of missions, set it to `-1`. +Например, `set_automated_battle_count 10` заставит сервер сыграть 10 миссий и завершить работу. Если вы хотите, чтобы количество миссий было неограниченным, установите значение `-1`. -#### Additional Features -With patch v1.2.x the below striken through text is no longer relevant. The `DedicatedCustomServerHelper` module and its functionality has been merged into the base game. +#### Дополнительные функции +Начиная с патча v1.2.x, нижеуказанный перечёркнутый текст больше не актуален. Модуль `DedicatedCustomServerHelper` и его функциональность были объединены с базовой игрой. -~~We supply the optional `DedicatedCustomServerHelper` module to help server hosts. There are several submodules within for distinct purposes.~~ For the server side modules to be usable from the outside, you will need to make TCP port 7210 accessible as well. +~~Мы предоставляем опциональный модуль `DedicatedCustomServerHelper` для помощи хостам серверов. В нём есть несколько подмодулей для различных целей.~~ Чтобы серверные модули были доступны извне, вам нужно также сделать доступным TCP-порт 7210. -~~Note that although the module is optional for server hosts, if you as the host do load the module, the players will also need to have it loaded. Otherwise, a mismatch in modules will prevent players from joining.~~ +~~Обратите внимание, что хотя модуль является опциональным для хостов серверов, если вы, как хост, загружаете этот модуль, игрокам также потребуется загрузить его. В противном случае несовпадение модулей не позволит игрокам подключиться.~~ -##### Administration Web Panel -This module launches a web panel to interact with your custom server, through a general management page and a terminal page: +##### Веб-панель администрирования +Этот модуль запускает веб-панель для взаимодействия с вашим пользовательским сервером через общую страницу управления и страницу терминала: -You can access the web panel with your server's IP address and port once it has been initialized. +Вы можете получить доступ к веб-панели по IP-адресу и порту вашего сервера после его инициализации. -The web panel is password protected by the server’s configured `AdminPassword` option. **By default, this option is left blank, so be sure to change it to a secure password**. +Веб-панель защищена паролем, который настраивается в опции `AdminPassword` сервера. **По умолчанию эта опция оставлена пустой, поэтому обязательно замените её на надёжный пароль**. -If you do not want the web panel to be accessible from outside the local network or machine, and also do not need the map download feature below, you are free to block TCP port 7210 from external access. +Если вы не хотите, чтобы веб-панель была доступна извне локальной сети или машины, и вам также не нужна функция загрузки карт ниже, вы можете заблокировать TCP-порт 7210 для внешнего доступа. -##### In-Game Map Downloads [Map Downloader] -We also present a way to allow players to download your server's map files through an in-game panel. As the server host, there are some conditions you must ensure to get this functioning: +##### Загрузка карт внутри игры [Map Downloader] +Мы также предоставляем способ позволить игрокам загружать файлы карт вашего сервера через внутриигровую панель. Как хост сервера, вам нужно обеспечить выполнение нескольких условий, чтобы это работало: -* The maps to be served must be located within ONLY the Multiplayer module's `SceneObj` directory, in the same way a typical module contains scenes. You can create the directory by hand if it is missing. -* The maps to be served must be "registered" through either the `Map` configuration option, the `add_map_to_automated_battle_pool` or `add_map_to_usable_maps` commands. In other words, only maps playable on the server are served. +* Карты, которые должны раздаваться, должны находиться ТОЛЬКО в директории `SceneObj` модуля Multiplayer, так же, как в типичном модуле содержатся сцены. Вы можете создать эту директорию вручную, если она отсутствует. +* Карты, которые должны раздаваться, должны быть «зарегистрированы» через конфигурационную опцию `Map`, либо через команды `add_map_to_automated_battle_pool` или `add_map_to_usable_maps`. Другими словами, раздаются только карты, доступные для игры на сервере. -Note that having the scene loaded in multiple modules will cause issues such as the scene not being shown on the download panel. +Обратите внимание, что наличие загруженной сцены в нескольких модулях вызовет проблемы, например, сцена не будет отображаться на панели загрузки. -Players will then get prompted to download all of the missing maps as they try to join the server or they can right click on the custom server list entry, which will open a context menu with the option to open the download panel for the server. Once all missing maps are successfully downloaded, there is no need to restart the game, they should be able to join your server as is. +Затем игрокам будет предложено загрузить все отсутствующие карты при попытке зайти на сервер, либо они могут щёлкнуть правой кнопкой мыши на записи пользовательского сервера в списке, что откроет контекстное меню с опцией открытия панели загрузки для этого сервера. После успешной загрузки всех недостающих карт перезапуск игры не требуется — игроки смогут сразу же подключиться к вашему серверу. -Note that this feature is intended to support simple use cases. This is not a module manager feature, and will not be able to support maps that require other assets (ModuleData, Prefabs, etc.) spread throughout a given module. Only the `SceneObj` directory contents are transferred between the server and the client. +Обратите внимание, что эта функция предназначена для поддержки простых сценариев использования. Это не функция менеджера модулей, и она не сможет поддерживать карты, которые требуют других ресурсов (ModuleData, Prefabs и т. д.), разбросанных по модулю. Между сервером и клиентом передаётся только содержимое директории `SceneObj`. -If the lack of prefab support is a concern, you may be able to make the scene usable through the Map Downloader by breaking the prefabs. Open the scene in the editor, select all entity objects, right click and select *Break Prefab*. +Если отсутствие поддержки префабов является проблемой, вы можете сделать сцену пригодной для использования с Map Downloader, разбив префабы. Откройте сцену в редакторе, выберите все объекты-сущности, щёлкните правой кнопкой мыши и выберите *Break Prefab*. -##### In-game admin panel & admin features -The in-game admin panel provides an easy way to organize and moderate events. +##### Внутриигровая панель администратора и функции администратора +Внутриигровая панель администратора предоставляет удобный способ организации и модерации событий. -The admin features are only available to those that enter the server as an admin by providing the admin password (right-click on the server and then `Join as Admin`). You can then access the admin panel via the Escape menu. The `AdminPassword` can be set from the server config. +Функции администратора доступны только тем, кто заходит на сервер как администратор, введя пароль администратора (щёлкните правой кнопкой мыши на сервере и выберите `Join as Admin`). Затем вы можете получить доступ к панели администратора через меню Escape. `AdminPassword` можно задать в конфигурации сервера. | | | | ------ | ----------- | | | | -The in-game panel has two main operational buttons: +Внутриигровая панель имеет две основные операционные кнопки: -* `Apply and Start Mission` -> This will apply all of the changes made and start a new mission immediately. -* `Apply Changes` -> This will apply all of the changes made. The ones that are listed under Immediate Effects will go into effect right away. Those that are listed under Mission Options will be applied on the next mission. +* `Apply and Start Mission` -> Применяет все внесённые изменения и немедленно запускает новую миссию. +* `Apply Changes` -> Применяет все внесённые изменения. Те, что перечислены в разделе Immediate Effects, вступят в силу сразу же. Те, что перечислены в разделе Mission Options, будут применены к следующей миссии. -The in-game admin panel comes with the following options: +Внутриигровая панель администратора включает следующие опции: -###### Mission Options (require mission restart) +###### Опции миссии (требуют перезапуска миссии) -Please note that if you wish to change "Mission Options" that require a mission restart using the in-game Admin Panel - you must use the map intermission system. This means you must use the `start_game_and_mission` (or `start_game`) and `enable_automated_battle_switching` commands in your server config. Not using these will automatically disable all Mission Options on the Admin Panel. +Обратите внимание, что если вы хотите изменить «Опции миссии» (Mission Options), требующие перезапуска миссии, используя внутриигровую панель администратора, — вам нужно использовать систему перерыва между картами (map intermission). Это означает, что вам нужно использовать команды `start_game_and_mission` (или `start_game`) и `enable_automated_battle_switching` в конфигурации сервера. Если вы их не используете, все опции миссии на панели администратора будут автоматически отключены. -Additionally, options open up based on the selected Game Type. For example, the Warmup Time Limit option is not available when selecting TeamDeathMatch - as there's no warmup in TDM. +Кроме того, доступные опции зависят от выбранного типа игры. Например, опция Warmup Time Limit недоступна при выборе TeamDeathMatch, поскольку в TDM нет разминки. -* Game Type - * Lists all available game types (Siege, TeamDeathmatch, Captain, Skirmish, Duel, Battle) -* Map - * Lists all the maps that have been passed to the server inside the config with the `add_map_to_usable_maps [MapName] [GameType],[GameType]` command - * For example: `add_map_to_usable_maps mymap Siege,Skirmish` (please note that the GameType must be correctly capitalized) -* Attacker & Defender Cultures -* Minimum Score to Win Duel -* Number of Rounds -* Map Time Limit -* Round Time Limit -* Warmup Time Limit -* Maximum Number of Players +* Game Type (Тип игры) + * Список всех доступных типов игры (Siege, TeamDeathmatch, Captain, Skirmish, Duel, Battle) +* Map (Карта) + * Список всех карт, которые были переданы серверу в конфигурации с помощью команды `add_map_to_usable_maps [MapName] [GameType],[GameType]` + * Например: `add_map_to_usable_maps mymap Siege,Skirmish` (обратите внимание, что GameType должен быть написан с правильным регистром) +* Attacker & Defender Cultures (Культуры атакующей и защищающейся сторон) +* Minimum Score to Win Duel (Минимальный счёт для победы в дуэли) +* Number of Rounds (Количество раундов) +* Map Time Limit (Лимит времени на карту) +* Round Time Limit (Лимит времени на раунд) +* Warmup Time Limit (Лимит времени разминки) +* Maximum Number of Players (Максимальное количество игроков) -###### Immediate Effects -* Welcome Message -* Team Balance Threshold -* Friendly Damages -* Class Limits (Allow, Disallow) +###### Немедленные эффекты (Immediate Effects) +* Welcome Message (Приветственное сообщение) +* Team Balance Threshold (Порог баланса команд) +* Friendly Damages (Дружественный урон) +* Class Limits (Лимиты классов) (Allow, Disallow) -###### Others -* End Warmup - * Overrides the warmup timer and ends the warmup in 30 seconds. -* Mute/Unmute Player - * Mutes a player, preventing them from using chat. -* Kick Player - * Kicks a player from the server. Kicked players are able to immediately rejoin the server. -* Ban Player - * Bans a player from the server. Banned players are not able to rejoin the server until it restarts. +###### Прочее +* End Warmup (Завершить разминку) + * Отменяет таймер разминки и завершает её через 30 секунд. +* Mute/Unmute Player (Заглушить/снять заглушение игрока) + * Заглушает игрока, не позволяя ему пользоваться чатом. +* Kick Player (Выгнать игрока) + * Выгоняет игрока с сервера. Выгнанные игроки могут сразу же повторно присоединиться к серверу. +* Ban Player (Забанить игрока) + * Банит игрока на сервере. Забаненные игроки не могут снова присоединиться к серверу до его перезапуска. -Here are some behaviours you should expect while changing Game Types, Maps and Cultures: +Вот некоторые особенности поведения, которые следует ожидать при изменении типов игры, карт и культур: -* If you leave Game Type, Map and Cultures UNSELECTED -> The game will run the current Game Type being played and give the players the option to vote on the available maps (those passed with `add_map_to_automated_battle_pool`) and cultures. -* If you leave Game Type, Map and Cultures UNSELECTED AND the Game Type isn't the one that the server initially launched with -> The game will run the current Game Type being played and use a random map from the available maps (those passed with `add_map_to_usable_maps`) and give the players the option to vote on cultures. -* If you select a Game Type but leave Map and Cultures UNSELECTED AND the selected Game Type isn't the one that the server initially launched with -> The game will run the current Game Type being played and use a random map from the available maps (those passed with `add_map_to_usable_maps`) and give the players the option to vote on cultures. -* If you select a Game Type and Map but leave Cultures UNSELECTED -> The game will run the selected Game Type with the selected Map and give the players the option to vote on cultures. -* If you select a Game Type, Map and Cultures -> The game will run the selected Game Type, Map and Cultures with no voting screen. -* If you provide no maps for a specific Game Type using the `add_map_to_usable_maps` parameter, that specific Game Type will be disabled in the admin panel. -* Official maps will only work with the intended Game Types. Trying to use them with another Game Type with `add_map_to_usable_maps` will not display them in the admin panel. +* Если вы оставите Game Type, Map и Cultures НЕВЫБРАННЫМИ -> Игра продолжит текущий тип игры и предоставит игрокам возможность голосовать за доступные карты (те, что переданы через `add_map_to_automated_battle_pool`) и культуры. +* Если вы оставите Game Type, Map и Cultures НЕВЫБРАННЫМИ, И текущий тип игры не совпадает с тем, с которым сервер изначально был запущен -> Игра продолжит текущий тип игры и использует случайную карту из доступных карт (переданных через `add_map_to_usable_maps`) и предоставит игрокам возможность голосовать за культуры. +* Если вы выберете Game Type, но оставите Map и Cultures НЕВЫБРАННЫМИ, И выбранный тип игры не совпадает с тем, с которым сервер изначально был запущен -> Игра продолжит текущий тип игры и использует случайную карту из доступных карт (переданных через `add_map_to_usable_maps`) и предоставит игрокам возможность голосовать за культуры. +* Если вы выберете Game Type и Map, но оставите Cultures НЕВЫБРАННЫМИ -> Игра запустит выбранный тип игры с выбранной картой и предоставит игрокам возможность голосовать за культуры. +* Если вы выберете Game Type, Map и Cultures -> Игра запустит выбранный тип игры, карту и культуры без экрана голосования. +* Если вы не укажете ни одной карты для определённого типа игры с помощью параметра `add_map_to_usable_maps`, этот тип игры будет отключён на панели администратора. +* Официальные карты будут работать только с предназначенными для них типами игры. Попытка использовать их с другим типом игры через `add_map_to_usable_maps` не приведёт к их отображению на панели администратора. -###### Admin Announcements -You can also make use of the admin announcements system which pushes out text to everyone on the server by typing the following into chat: +###### Объявления администратора +Вы также можете использовать систему объявлений администратора, которая рассылает текст всем на сервере, введя следующее в чат: -* `/ab [text]` - Admin Broadcast - Displays the announcement in the middle of the screen as well as in chat alongside a sound notification. -* `/ac [text]` - Admin Chat - Displays the announcement in chat. +* `/ab [text]` - Admin Broadcast (Трансляция администратора) - Отображает объявление в центре экрана, а также в чате вместе со звуковым уведомлением. +* `/ac [text]` - Admin Chat (Чат администратора) - Отображает объявление в чате. -## FAQ -##### Does Steam need to stay open for hosting? -No. You only need Steam for keeping your server files up to date. You are free to copy your server files to some other computer to host it. But we strongly recommend you to use it with Steam in order to keep it up to date. Unlike Warband, currently, any older versions of the server files will be incompatible with our system. +## Часто задаваемые вопросы +##### Нужно ли держать Steam открытым для хостинга? +Нет. Steam нужен только для поддержания актуальности файлов вашего сервера. Вы можете свободно копировать файлы своего сервера на другой компьютер для хостинга. Но мы настоятельно рекомендуем использовать его вместе со Steam, чтобы поддерживать актуальность. В отличие от Warband, в настоящее время любые более старые версии файлов сервера будут несовместимы с нашей системой. -##### Are you planning to add support for other game platforms? -Yes. +##### Планируете ли вы добавить поддержку других игровых платформ? +Да. -##### What if I don’t want to use any game platform to retrieve the server files, will there be any other option? -Right now, Steam is the only way to download it. We are planning to add it to other game platforms and are also discussing using a Docker host for distributing the server files in the future. +##### Что, если я не хочу использовать какую-либо игровую платформу для получения файлов сервера, будет ли другой вариант? +Прямо сейчас Steam — единственный способ его загрузить. Мы планируем добавить поддержку других игровых платформ, а также обсуждаем использование Docker-хоста для распространения файлов сервера в будущем. -##### Will you provide Linux support? -Linux server files are already available! +##### Будет ли поддержка Linux? +Файлы сервера для Linux уже доступны! -##### Will my server be accessible by everyone? -Yes, your server will be accessible by everyone unless you make it password protected. +##### Будет ли мой сервер доступен всем? +Да, ваш сервер будет доступен всем, если вы не защитите его паролем. -##### How many servers can I host? -There is a limit to the number of servers you can host simultaneously. Currently, you can host up to 50 servers. +##### Сколько серверов я могу разместить? +Существует ограничение на количество серверов, которые вы можете размещать одновременно. В настоящее время вы можете разместить до 50 серверов. -##### What are the hardware requirements? -It depends on the game mode and the player count. With the default configurations, we are hosting our games: +##### Каковы требования к аппаратному обеспечению? +Это зависит от режима игры и количества игроков. С конфигурациями по умолчанию мы размещаем наши игры следующим образом: -* For smaller battles (Skirmish and Duel): 2 core CPUs (2GHz to 3GHz) with 4GB Memory -* For bigger battles (Siege, Team Deathmatch and Captain): 4 core CPUs (2GHz to 3GHz) with 8GB Memory +* Для небольших боёв (Skirmish и Duel): 2-ядерные CPU (2–3 ГГц) с 4 ГБ памяти +* Для крупных боёв (Siege, Team Deathmatch и Captain): 4-ядерные CPU (2–3 ГГц) с 8 ГБ памяти -But, for instance, you can always host a siege mode with less players on a 2 core machine as well. +Но, например, вы всегда можете разместить режим осады с меньшим количеством игроков на 2-ядерной машине. -You can also try to host a very small game with a single core machine as well but you might get some spikes during the game. +Вы также можете попробовать разместить очень маленькую игру на одноядерной машине, но при этом могут возникнуть всплески во время игры. -##### What are the bandwidth requirements? -It depends on the player count. By default, we are sending 60 packets to each player and each packet is less than 1.5 kilobytes. For most configurations, any dedicated server provider should be able to provide a sufficient network connection. +##### Каковы требования к пропускной способности сети? +Это зависит от количества игроков. По умолчанию мы отправляем 60 пакетов каждому игроку, и каждый пакет весит менее 1,5 килобайт. Для большинства конфигураций любой провайдер выделенных серверов должен быть способен предоставить достаточное сетевое соединение. -##### Is there any modification support? -Yes! Go to https://moddocs.bannerlord.com/multiplayer/custom_game_mode/ to learn more. +##### Поддерживается ли модификация? +Да! Перейдите по адресу https://moddocs.bannerlord.com/multiplayer/custom_game_mode/, чтобы узнать больше. diff --git a/docs/content/russian/Multiplayer/multiplayer_scenes.md b/docs/content/russian/Multiplayer/multiplayer_scenes.md index 3c7a67f6..c24420dd 100644 --- a/docs/content/russian/Multiplayer/multiplayer_scenes.md +++ b/docs/content/russian/Multiplayer/multiplayer_scenes.md @@ -1,190 +1,191 @@ +++ -title = "What Makes a Multiplayer Scene" +title = "Что делает сцену многопользовательской" description = "" weight = 15 +ai_translated = true +++ -### Introduction -This technical introduction should enable you to create a custom multiplayer scene, for a specific gamemode. It goes into details on what requirements your MP scene needs to meet so that it doesn't crash. This is not a design guideline or best practice document. +### Введение +Это техническое введение должно помочь вам создать пользовательскую многопользовательскую сцену для конкретного игрового режима. Оно подробно описывает требования, которым должна соответствовать ваша MP-сцена, чтобы она не вызывала краш игры. Это не руководство по дизайну и не документ с лучшими практиками. -### Gamemode Specifics -Each Gamemode in Bannerlord will require a few different setups of relevant prefabs. +### Особенности игровых режимов +Каждый игровой режим в Bannerlord требует нескольких разных наборов соответствующих префабов. {{% notice tip %}} -It is possible to make scenes compatible with multiple game modes by including all needed prefabs. Scenes cannot be compatible with modes that use a different spawning system, for example a TDM scene can't be compatible with a Captain scene, but a Captain scene can also be used for Skirmish if it has a proper respawn setup. +Можно сделать сцены совместимыми с несколькими игровыми режимами, включив все необходимые префабы. Сцены не могут быть совместимы с режимами, использующими другую систему спавна, например, сцена TDM не может быть совместима со сценой Captain, но сцена Captain также может использоваться для Skirmish, если в ней настроен правильный респавн. {{% /notice %}} -#### Game Objects -Gameobjects found as prefabs that are needed for the gamemode to work in your scene. You can find these in the “Prefabs” window. +#### Игровые объекты +Игровые объекты, найденные как префабы, необходимые для работы игрового режима на вашей сцене. Вы можете найти их в окне «Prefabs». -##### General +##### Общие ###### mp_camera_start_pos -Initial camera position, that is set for joining players. It basically defines the backdrop for choosing the faction upon joining a custom server. It will also be the first thing people see of your scene. Make sure you rotate it slightly (it is initially rotated downwards). Only place one! +Начальная позиция камеры, устанавливаемая для присоединяющихся игроков. По сути, она определяет фон для выбора фракции при присоединении к пользовательскому серверу. Это также будет первое, что люди увидят на вашей сцене. Обязательно немного поверните её (изначально она направлена вниз). Размещайте только одну! ###### border_soft -Define the soft border around your scene. If players cross they have a few seconds to return back. This border is needed to set the scene boundaries. Make sure the border does not cross into your playbale area. You define the border (best practice is to do a hexagon shape) by placing the border probes around your map. The probes will always try to connect to the 2 closest probes to them. +Определяет мягкую границу вокруг вашей сцены. Если игроки пересекают её, у них есть несколько секунд, чтобы вернуться обратно. Эта граница нужна для задания пределов сцены. Убедитесь, что граница не пересекает игровую зону. Вы задаёте границу (лучшая практика — делать это в форме шестиугольника), размещая пробники границы (border probes) вокруг вашей карты. Пробники всегда будут пытаться соединиться с 2 ближайшими к ним пробниками. {{% notice tip %}} -You can check your resulting border by enabling “Borders” in the Visibility window, sometimes it is good to reload the scene before doing that. +Вы можете проверить получившуюся границу, включив «Borders» в окне Visibility, иногда перед этим полезно перезагрузить сцену. {{% /notice %}} ###### flee_line -The lines that AI (in our gamemodes only AI horses) uses to leave the battlefield. They will try to find these using the navmesh. So these positions need to be placed where AI can reach them via the navmesh. Once they reach it they will fade out after a short period. You can place multiple instances of these. +Линии, которые ИИ (в наших игровых режимах — только ИИ-лошади) использует, чтобы покинуть поле боя. Они будут пытаться найти их с помощью навигационной сетки (navmesh). Поэтому эти позиции должны быть размещены там, куда ИИ может добраться через навмеш. Как только они достигают линии, они исчезают через короткий промежуток времени. Вы можете разместить несколько экземпляров этих объектов. {{% notice tip %}} -For siege, make sure there are flee lines inside the castle as well, so horses that got inside can get out without trying to pass the gate. Navmesh and AI can not dıstinguish between stairs and ramps, and horses can not traverse stairs. You might need to adjust or remove navigation meshes on stairs to avoid riderless horses blocking them. +Для осады убедитесь, что линии бегства (flee lines) также есть внутри замка, чтобы лошади, оказавшиеся внутри, могли выбраться, не пытаясь пройти через ворота. Навмеш и ИИ не различают лестницы и пандусы, а лошади не могут передвигаться по лестницам. Возможно, вам потребуется скорректировать или убрать навигационные сетки на лестницах, чтобы избежать блокировки прохода бесхозными лошадьми. {{% /notice %}} ###### envmap_prop -Should already be there when you create a new scene, if it’s not place it and set it to “IsGlobal” in the “Inspector” window. Also make sure it's in a valid position. You can of course have multiple probes, but use the local_envmap_probe for further probes. +Должен уже присутствовать при создании новой сцены; если его нет, разместите его и установите «IsGlobal» в окне «Inspector». Также убедитесь, что он находится в правильной позиции. Конечно, у вас может быть несколько пробников, но для дополнительных пробников используйте local_envmap_probe. ##### Flag Domination (Skirmish, Battle, Captain) -###### Flags -Each of these gamemodes use 3 flags. Don't be put off by their naming but all game modes use the same prefabs! +###### Флаги +Каждый из этих игровых режимов использует 3 флага. Не смущайтесь их названиями — все игровые режимы используют одни и те же префабы! -Their prefabs: flag_pole_big_sergeant_A, flag_pole_big_sergeant_B, flag_pole_big_sergeant_C +Их префабы: flag_pole_big_sergeant_A, flag_pole_big_sergeant_B, flag_pole_big_sergeant_C -Flag Domination modes need three individual flags, so don't duplicate the A flag 2 times. +Режимам Flag Domination нужны три отдельных флага, поэтому не дублируйте флаг A дважды. ##### Siege -###### Flags -Uses the same flags as Flag Domination, but more of them (obviously). Place all flags from A to F and the main flag which is G. +###### Флаги +Использует те же флаги, что и Flag Domination, но больше их (что очевидно). Разместите все флаги от A до F и главный флаг, который G. -Their prefabs: flag_pole_big_sergeant_A, flag_pole_big_sergeant_B, flag_pole_big_sergeant_C, flag_pole_big_sergeant_D, flag_pole_big_sergeant_E, flag_pole_big_sergeant_F, flag_pole_big_sergeant_main +Их префабы: flag_pole_big_sergeant_A, flag_pole_big_sergeant_B, flag_pole_big_sergeant_C, flag_pole_big_sergeant_D, flag_pole_big_sergeant_E, flag_pole_big_sergeant_F, flag_pole_big_sergeant_main -###### Siege Engines -Technically they work in the same way as for singleplayer sieges. Still there are some significant differences. First of all most of them use different prefabs for multiplayer, make sure you are using those! +###### Осадные орудия +Технически они работают так же, как и в одиночных осадах. Тем не менее, есть некоторые существенные отличия. Прежде всего, большинство из них используют другие префабы для многопользовательского режима, убедитесь, что вы используете именно их! -There is also no minimum (or maximum) amount of siege engines needed in your scene, and no need for deployment points, since the siege engines are set by your scene and not by the sandbox campaign. Also you don't need to do extensive navmesh work for your siege tower, rams and ladders. So you can ignore all the nav mesh inputs in the Inspector. +Также нет минимального (или максимального) количества осадных орудий, необходимого на вашей сцене, и не нужны точки развёртывания, поскольку осадные орудия задаются вашей сценой, а не песочницей кампании. Также вам не нужно проводить обширную работу с навмешем для осадной башни, таранов и лестниц. Так что вы можете игнорировать все поля для навигационной сетки в Inspector. -Rams and siege towers will still need a path to move along though. Simply create a path, remember its name and set it in the script in the inspector as “PathEntityName”. +Тем не менее, таранам и осадным башням всё равно понадобится путь для движения. Просто создайте путь, запомните его имя и укажите его в скрипте в Inspector как «PathEntityName». -Multiplayer specific prefabs: siege_tower_5m_spawnerMP, siege_tower_9m_spawnerMP, siege_tower_12m_spawnerMP, batteringram_a_spawnerMP, mangonel_a_spawnerMP, mangonel_a_spawnerFireMP, mangonel_b_spawnerMP, mangonel_b_spawnerFireMP, mangonel_a_spawnerMP, mangonel_a_spawnerFireMP, ballista_a_spawnerMP, ballista_a_spawnerFireMP, ballista_b_spawnerMP, ballista_b_spawnerFireMP +Префабы, специфичные для многопользовательского режима: siege_tower_5m_spawnerMP, siege_tower_9m_spawnerMP, siege_tower_12m_spawnerMP, batteringram_a_spawnerMP, mangonel_a_spawnerMP, mangonel_a_spawnerFireMP, mangonel_b_spawnerMP, mangonel_b_spawnerFireMP, mangonel_a_spawnerMP, mangonel_a_spawnerFireMP, ballista_a_spawnerMP, ballista_a_spawnerFireMP, ballista_b_spawnerMP, ballista_b_spawnerFireMP {{% notice tip %}} -Prefabs for gates and ladders are the same as for singleplayer. +Префабы для ворот и лестниц такие же, как и для одиночной игры. {{% /notice %}} ###### arrow_barrel -You can place this prefab anywhere in your scene. Players can use it to refill their ammunition. +Вы можете разместить этот префаб в любом месте вашей сцены. Игроки могут использовать его, чтобы пополнить боезапас. ###### rock_pile -Placing this prefab allows players to pick up rocks, they work the same way as the ones coming with siege engines by default. In the StonePile script you can set how many rocks this prefab comes with. There is also a firepot version of this prefab: “pot_pile” +Размещение этого префаба позволяет игрокам подбирать камни, они работают так же, как и те, что по умолчанию идут с осадными орудиями. В скрипте StonePile вы можете задать, сколько камней идёт в комплекте с этим префабом. Также есть версия этого префаба с горшками с огнём: «pot_pile». -The prefab comes with children “icon_man” that define the positions you can pick up the rocks from. You can delete those children if you don't want your pile to be accessible from any direction. +Префаб поставляется с дочерними объектами «icon_man», которые определяют позиции, с которых можно подбирать камни. Вы можете удалить эти дочерние объекты, если не хотите, чтобы к вашей куче можно было подойти с любой стороны. -Rock_pile and pot_pile prefabs can also be used with mangonels and trebuchets. If you want to give players the option to choose ammunation, you can simply place piles next to siege engines. +Префабы rock_pile и pot_pile также можно использовать с мангонелями и требушетами. Если вы хотите дать игрокам возможность выбирать боеприпасы, вы можете просто разместить кучи рядом с осадными орудиями. ##### Duel -For duel mode you will need to create landmarks by hand. There are two kinds of landmarks, three that define the troop types and 16 smaller ones that define the arenas and which type they belong to. +Для режима дуэли вам нужно будет создать ориентиры (landmarks) вручную. Есть два вида ориентиров, три из которых определяют типы отрядов, и 16 поменьше, которые определяют арены и то, к какому типу они относятся. -###### Big landmarks -You can use any prefab for this, it will need to have these two tags: “duel_zone_landmark” and “flag_x”. The x stands for the troop type so replace it with either: “infantry”, ”cavalry” or ”archery”. +###### Большие ориентиры +Для этого можно использовать любой префаб, но ему нужно будет иметь два тега: «duel_zone_landmark» и «flag_x». X обозначает тип отряда, поэтому замените его на: «infantry», «cavalry» или «archery». -You also need to define the zone's troop type (again) with a script. For that, add the “DuelZoneLandmark” to your prefab and set it to whatever troop type you intend to spawn here. +Вам также нужно будет (снова) задать тип отряда зоны с помощью скрипта. Для этого добавьте «DuelZoneLandmark» к вашему префабу и установите тот тип отряда, который вы хотите здесь заспавнить. -###### Arena landmarks -These landmarks define the arenas that are grouped by the big landmarks. Again you can use any prefab as a base for this. It will need two tags set, the first one “flag_x” is used to reference it to the big landmark. So if you want this arena to be used for Cavalry fights, you should use the tag “flag_cavalry”. +###### Ориентиры арены +Эти ориентиры определяют арены, сгруппированные большими ориентирами. Опять же, в качестве основы можно использовать любой префаб. Ему нужно установить два тега: первый, «flag_x», используется для привязки к большому ориентиру. Так что если вы хотите, чтобы эта арена использовалась для боёв кавалерии, используйте тег «flag_cavalry». -Your landmark will also need a tag that references the actual arena area (described below), basically serving as an ID. For that, use the tag “area_flag_x”, x being the ID of your arena. So if you have 16 arenas, each of them should have their own tag, ranging from “area_flag_1” to “area_flag_16”. +Вашему ориентиру также понадобится тег, ссылающийся на фактическую область арены (описана ниже), по сути служащий идентификатором. Для этого используйте тег «area_flag_x», где x — ID вашей арены. Так что если у вас 16 арен, каждая из них должна иметь свой собственный тег, от «area_flag_1» до «area_flag_16». ###### volume_box -This box defines the area where combatants duel in your arena. All dropped weapons and bodies will be cleared inside this box after each duel. Make sure that it is slightly bigger than the physical arena you have built in the scene editor. You can use the volume_box prefab and scale it to your liking. The box will need a tag referencing the ID of your arena: “area_box_x”, x being the ID of your arena. +Этот блок определяет область, в которой участники сражаются на вашей арене. Всё брошенное оружие и тела будут удаляться внутри этого блока после каждой дуэли. Убедитесь, что он немного больше физической арены, которую вы построили в редакторе сцен. Вы можете использовать префаб volume_box и масштабировать его по своему усмотрению. Блоку понадобится тег, ссылающийся на ID вашей арены: «area_box_x», где x — ID вашей арены. -So if the tag for your arena was “area_flag_5”, you should tag your volmue_box with “area_box_5”. +Так что если тег вашей арены был «area_flag_5», вам следует пометить ваш volume_box тегом «area_box_5». -The spawn points for both combatants need to be placed within this volume. Check below. +Точки спавна для обоих участников должны быть размещены внутри этого объёма. Смотрите ниже. -#### Spawn Points -Points where players start the round, or respawn during that round. Flag Domination modes (Captain, Skirmish, Battle) use nearly the same spawning system and scenes are compatible between each other with a little bit of work. Compatible in a technical sense that is. +#### Точки спавна +Точки, в которых игроки начинают раунд или возрождаются в течение раунда. Режимы Flag Domination (Captain, Skirmish, Battle) используют почти одинаковую систему спавна, и сцены совместимы друг с другом при небольшой доработке. Совместимы в техническом смысле. -Most spawn points require the right side tag to be set. The prefabs come with default tags that are either “attacker” or “defender”. You will obviously need to duplicate those and adjust all tags on the prefabs and its children for the opposite team. Sometimes if a tag is not yet present in your scene you need to manually add it to the list, it won’t show up in the drop down menu otherwise! +Для большинства точек спавна требуется установить правильный тег стороны. Префабы поставляются с тегами по умолчанию, которые либо «attacker», либо «defender». Вам, очевидно, нужно будет продублировать их и скорректировать все теги на префабах и их дочерних объектах для противоположной команды. Иногда, если тег ещё не присутствует в вашей сцене, его нужно добавить в список вручную, иначе он не появится в выпадающем меню! -##### General +##### Общие ###### spawn_visual -Position in which the class and perk selection happens. The prefab has 6 child objects, one for the player and 5 for their teammates. For most game modes (every gamemode except skirmish and captain), only the child with the tag “sp_visual_0” is used, since we don't have a set amount of team mates. +Позиция, в которой происходит выбор класса и перков. У префаба 6 дочерних объектов: один для игрока и 5 для его товарищей по команде. Для большинства игровых режимов (всех, кроме skirmish и captain) используется только дочерний объект с тегом «sp_visual_0», поскольку у нас нет фиксированного количества товарищей по команде. -During the class/perk selection a camera will be placed in front of the “sp_visual_0” child object. +Во время выбора класса/перков камера будет размещена перед дочерним объектом «sp_visual_0». {{% notice tip %}} -You can ignore the “attacker” tag on the child objects. Unlike many other spawn positions, this one does not need to be duplicated for the defender team. +Тег «attacker» на дочерних объектах можно игнорировать. В отличие от многих других позиций спавна, эту не нужно дублировать для команды защитников. {{% /notice %}} ##### Flag Domination (Skirmish, Battle, Captain) ###### skirmish_start_spawn -Prefab that defines the initial spawn. Don't be put off by the name of the prefab, it can be used for all 3 Flag Domination game modes. +Префаб, определяющий начальный спавн. Не смущайтесь названием префаба, он может использоваться для всех 3 режимов Flag Domination. -Comes with 9 child spawns, but you can duplicate those to have more possible spawn positions (e.g. if you don't want people to spawn on top of each other for a 50 vs 50 battle mode). All children need to have the “spawnpoint” and “attacker” or “defender” tag. The main zone’s tags “starting” and “spawn_zone” should not be touched. +Поставляется с 9 дочерними точками спавна, но вы можете продублировать их, чтобы получить больше возможных позиций спавна (например, если вы не хотите, чтобы игроки появлялись друг на друге в режиме битвы 50 на 50). У всех дочерних объектов должны быть теги «spawnpoint» и «attacker» или «defender». Теги главной зоны «starting» и «spawn_zone» трогать не следует. {{% notice tip %}} -Make sure that the points are not below the terrain and ground assets you are using. Also remember that horses that spawn will require more space around them. So don't place your spawns too close to each other and other prefabs. +Убедитесь, что точки не находятся ниже местности и используемых объектов земли. Также помните, что заспавнившимся лошадям потребуется больше места вокруг. Поэтому не размещайте точки спавна слишком близко друг к другу и к другим префабам. {{% /notice %}} ###### skirmish_respawn -Prefab that defines the respawn positions for skirmish mode. So players spawn here after they have died. If you don't place these positions, players will spawn at the start spawn when respawning. +Префаб, определяющий позиции возрождения для режима skirmish. То есть игроки появляются здесь после смерти. Если вы не разместите эти позиции, игроки будут появляться в начальной точке спавна при возрождении. -You can place up to 3 of these per side. Just like with the start spawn it is important you make duplicates for both sides “attacker” and “defender”. The main zone’s tag “spawn_zone” should not be touched. +Вы можете разместить до 3 таких объектов на каждую сторону. Как и в случае с начальной точкой спавна, важно сделать дубликаты для обеих сторон «attacker» и «defender». Тег главной зоны «spawn_zone» трогать не следует. -Spawn point selection system relies on the location of the parent entity while checking for nearby enemies, while players will spawn in the child entities. You can use this to your advantage to adjust spawn location biases. +Система выбора точки спавна полагается на расположение родительского объекта при проверке близлежащих врагов, в то время как игроки будут появляться в дочерних объектах. Вы можете использовать это в своих интересах для настройки смещения точек спавна. ##### Siege -The spawns in siege are fundamentally different to other modes. Spawnzones in siege are inactive or active depending on how many flags have been removed in the match. Each spawn zone is connected to this gamemode logic via the tag sp_zone_x (x is a number between 0 and 6) +Спавн в осаде принципиально отличается от других режимов. Зоны спавна в осаде активны или неактивны в зависимости от того, сколько флагов было снято в матче. Каждая зона спавна связана с этой логикой игрового режима через тег sp_zone_x (x — число от 0 до 6). -The tag in question is set in the main spawn point prefab, which has the single spawn points “mp_spawnpoint” as children. The “x” of the tag defines how many flags need to be captured (and removed) by the attackers, for this spawn area to be active. So at the start of the siege players will spawn in the zone with the tag sp_zone_0, once the first flag is removed they will spawn in the zone with the tag sp_zone_1, so and so on. If only G (the main flag) is left, players will spawn in the zone with the tag sp_zone_6. +Этот тег задаётся в главном префабе точки спавна, у которого есть дочерние одиночные точки спавна «mp_spawnpoint». «X» в теге определяет, сколько флагов нужно захватить (и снять) атакующим, чтобы эта зона спавна стала активной. Так, в начале осады игроки будут появляться в зоне с тегом sp_zone_0, как только первый флаг будет снят, они будут появляться в зоне с тегом sp_zone_1, и так далее. Если остался только G (главный флаг), игроки будут появляться в зоне с тегом sp_zone_6. -You can put multiple of these tags on the same spawn zone, so you can have a spawn zone for the first two flags, by simply giving it the sp_zone_0 and sp_zone_1 tags. +Вы можете разместить несколько таких тегов на одной и той же зоне спавна, так что можно сделать зону спавна для первых двух флагов, просто дав ей теги sp_zone_0 и sp_zone_1. -Make sure to tag the children of the spawn zones with the “spawnpoint” and “attacker” or “defender” tag. Just like in the other modes. +Обязательно пометьте дочерние объекты зон спавна тегами «spawnpoint» и «attacker» или «defender». Так же, как и в других режимах. -There is no prefab for this spawnpoint, so you'll need to set most tags by yourself. I suggest you use the “skirmish_start_spawn” prefab. For that you need to delete the “starting” tag from the zone and replace it with the “sp_zone_x” tag / tags. +Для этой точки спавна нет префаба, поэтому вам нужно будет настроить большинство тегов самостоятельно. Я предлагаю использовать префаб «skirmish_start_spawn». Для этого вам нужно удалить тег «starting» из зоны и заменить его на тег(и) «sp_zone_x». -Don't forget to place attacker and defender spawns! +Не забудьте разместить точки спавна для атакующих и защитников! {{% notice tip %}} -You can use special tags on the “mp_spawnpoint” children of the spawn zones to adjust which troops can spawn there. The self explanatory tags for this are: “exclude_mounted” and “exclude_footmen”. +Вы можете использовать специальные теги на дочерних объектах «mp_spawnpoint» зон спавна, чтобы настроить, какие отряды могут там появляться. Понятные из названия теги для этого: «exclude_mounted» и «exclude_footmen». {{% /notice %}} ##### TDM -TDM doesn't use spawn zones, spawn points are placed around the scene without side tags. Use the “mp_spawnpoint” prefab for that. Make sure they are not a child to another prefab and only have the tag “spawnpoint”. +TDM не использует зоны спавна, точки спавна размещаются по сцене без тегов стороны. Используйте для этого префаб «mp_spawnpoint». Убедитесь, что они не являются дочерними объектами другого префаба и имеют только тег «spawnpoint». ##### Duel -Duel doesn't use spawn zones, spawn points are placed around the scene (preferably a sort of lobby area) without side tags. Use the “mp_spawnpoint” prefab for that. Make sure they are not a child to another prefab and only have the tag “spawnpoint”. +Duel не использует зоны спавна, точки спавна размещаются по сцене (предпочтительно в своего рода лобби-зоне) без тегов стороны. Используйте для этого префаб «mp_spawnpoint». Убедитесь, что они не являются дочерними объектами другого префаба и имеют только тег «spawnpoint». -Remember to also place two mp_spawnpoints inside each arena. They need to be tagged linking to the arena landmark. So with “spawnpoint_area_x”, x being the ID of the arena they belong to. Also make sure they are placed inside the volume_box of that arena. +Не забудьте также разместить две точки mp_spawnpoint внутри каждой арены. Их нужно пометить тегами, связывающими их с ориентиром арены. Так, с помощью «spawnpoint_area_x», где x — ID арены, к которой они относятся. Также убедитесь, что они размещены внутри volume_box этой арены. -#### Navigation Mesh -In general Navmesh is much less important in multiplayer, as most Native gamemodes don’t use AI soldiers. Still the navmesh is used for espacing horses, to find their way to flee lines and also it is used for baking GI. +#### Навигационная сетка +В целом навмеш гораздо менее важен в многопользовательском режиме, поскольку большинство родных игровых режимов не используют солдат ИИ. Тем не менее, навмеш используется для бегущих лошадей, чтобы найти путь к линиям бегства, а также для запекания GI. -For how to create a proper navmesh refer to our [existing documentation]({{< ref "nav_mesh" >}}). +О том, как создать правильный навмеш, смотрите в нашей [существующей документации]({{< ref "nav_mesh" >}}). -You can ignore specific IDs for AI scripting. +Вы можете игнорировать конкретные ID для скриптинга ИИ. ##### Captain -Generally for captain mode the same thing applies as for singleplayer battle terrain navmesh work. You will have to cover a relatively huge scene, with very accurate navmesh. You dont need to worry about IDs. You can use navmesh cost just like in singleplayer, to deter agents from using certain navmesh faces. +В целом для режима captain применимо то же самое, что и для работы с навмешем местности битвы в одиночной игре. Вам нужно будет покрыть относительно огромную сцену очень точным навмешем. Об ID беспокоиться не нужно. Вы можете использовать стоимость навмеша (navmesh cost) так же, как в одиночной игре, чтобы удерживать агентов от использования определённых граней навмеша. {{% notice info %}} -Keep in mind: Much more important than in singleplayer, areas that are reachable for players but don't have navmesh on them, bear a huge exploit potential. Try to avoid having spots like that. +Имейте в виду: гораздо важнее, чем в одиночной игре, избегать областей, доступных для игроков, но не имеющих навмеша — такие места несут огромный потенциал для эксплойтов. Старайтесь избегать подобных мест. {{% /notice %}} ##### Siege -The castle gates will need proper navmesh to be set in the scripts. Just like in singleplayer (refer to the documentation linked above). If you don't create a proper navmesh for these, horses will be confused and get stuck in your gates. Additionally we ignore the navmesh castle gates for GI generation, this will prevent light leakage into the body of your gatehouse. +Воротам замка нужен правильный навмеш, настроенный в скриптах. Так же, как и в одиночной игре (см. документацию, указанную выше). Если вы не создадите правильный навмеш для них, лошади будут путаться и застревать в ваших воротах. Кроме того, мы игнорируем навмеш замковых ворот при генерации GI, это предотвратит утечку света внутрь надвратной башни. -Also make sure that horses have access to flee lines inside and outside of the castle. Keep in mind that horses will always choose the closest “flee_line” to flee too, if that “flee_line” happens to be outside of the castle they will try to find a way out, leading them to get stuck if you haven't set up your ladders and gates correctly. +Также убедитесь, что у лошадей есть доступ к линиям бегства внутри и снаружи замка. Имейте в виду, что лошади всегда будут выбирать ближайшую «flee_line» для бегства, и если эта «flee_line» окажется снаружи замка, они попытаются найти выход наружу, что приведёт к застреванию, если вы не настроили лестницы и ворота правильно. -### Other -###### Atmosphere -Unlike in singleplayer, multiplayer scenes only ever use one atmosphere. Don't forget to save it when making edits. +### Другое +###### Атмосфера +В отличие от одиночной игры, многопользовательские сцены всегда используют только одну атмосферу. Не забудьте сохранить её при внесении изменений. -###### Label -In the “SceneOptions” window, you can set a Label for your scene. This is helpful if you scan your scene for problems (2nd to last button in the top icon bar). If you set this label to “mp” it will filter out all singleplayer related problems. +###### Метка (Label) +В окне «SceneOptions» вы можете задать метку (Label) для вашей сцены. Это полезно, если вы сканируете свою сцену на наличие проблем (предпоследняя кнопка на верхней панели иконок). Если вы установите эту метку как «mp», это отфильтрует все проблемы, связанные с одиночной игрой. -###### Avoid animation point prefab -Using certain prefabs that are meant for singleplayer can cause your scene to crash. Watch out you are not placing any assets with animation points attached. This is important for chairs and the like, but also for any shop_prop prefabs that might have an animation attached. +###### Избегайте префабов с точками анимации +Использование некоторых префабов, предназначенных для одиночной игры, может привести к краху вашей сцены. Следите за тем, чтобы не размещать объекты с прикреплёнными точками анимации. Это важно для стульев и подобных объектов, а также для любых префабов shop_prop, которые могут иметь прикреплённую анимацию. -Usually all these prefabs have a non animation point version of themselves. Otherwise you can always use those assets by simply deleting the animation point child and removing all tags and script from the prefab. +Обычно у всех этих префабов есть версия без точки анимации. В противном случае вы всегда можете использовать эти объекты, просто удалив дочерний объект точки анимации и убрав все теги и скрипты с префаба. -###### Avoid destructible objects outside of siege -Destructible objects are only properly synced with our siege gamemode. Placing breakable objects like barricades, or siege engines in other modes will probably crash your game or cause other problems. +###### Избегайте разрушаемых объектов вне осады +Разрушаемые объекты правильно синхронизируются только в нашем игровом режиме осады. Размещение ломающихся объектов, таких как баррикады или осадные орудия, в других режимах, вероятно, приведёт к краху вашей игры или вызовет другие проблемы. -The same goes for merlons on walls or destructible roofs. +То же самое касается зубцов стен (merlons) или разрушаемых крыш. diff --git a/docs/content/russian/Steam Workshop/_index.md b/docs/content/russian/Steam Workshop/_index.md index 194173d3..8f9e1f74 100644 --- a/docs/content/russian/Steam Workshop/_index.md +++ b/docs/content/russian/Steam Workshop/_index.md @@ -1,5 +1,5 @@ +++ -title = "Steam Workshop" +title = "Мастерская Steam" description = "" weight = 35 +++ diff --git a/docs/content/russian/Steam Workshop/uploading_updating_mod.md b/docs/content/russian/Steam Workshop/uploading_updating_mod.md index 58b7616c..feb181e9 100644 --- a/docs/content/russian/Steam Workshop/uploading_updating_mod.md +++ b/docs/content/russian/Steam Workshop/uploading_updating_mod.md @@ -1,48 +1,49 @@ +++ -title = "Uploading/Updating a Mod" +title = "Загрузка/обновление мода" description = "" weight = 5 +ai_translated = true +++ -## Preparing Your Module For Publishing +## Подготовка вашего модуля к публикации -You need to Publish your module via the modding toolkit in order to allow/enable other players to use your module. You can deploy it for the end user, dedicated servers or other modders, all of which is explained below. +Вам нужно опубликовать свой модуль через набор инструментов моддинга, чтобы другие игроки могли использовать ваш модуль. Вы можете развернуть его для конечного пользователя, выделенных серверов или других моддеров — всё это объясняется ниже. -### Exporting the Module via the Modding Tools +### Экспорт модуля с помощью инструментов моддинга -* Open the Modding Kit via the Launcher after checking your mod in the Launcher’s module list -* Open the Editor from the Main Menu UI -* From the File menu on the top, select Publish Module +* Откройте Modding Kit через Launcher, предварительно отметив свой мод в списке модулей Launcher'а +* Откройте редактор (Editor) из главного меню UI +* В меню File вверху выберите Publish Module -In the Publishing pop-up window, the following options are available: +В всплывающем окне публикации доступны следующие параметры: | | | | ------ | ----------- | | | | -* `Client`: Your module will be packed for client use. Which means that players will need to have these packages in order to play the game. This is the least you need to do if you want your module to be played via Steam Workshop. -* `Dedicated Server`: Your module can be run on a server too. If you’d like your mod to be available on multiplayer too, you need to check it. -* `Editor`: Other players can open your module via the Editor and modify it. If you don’t pack for the editor, players will not be able to open your module via the Editor. +* `Client`: Ваш модуль будет упакован для клиентского использования. Это означает, что игрокам потребуются эти пакеты, чтобы играть в игру. Это минимум, который вам нужно сделать, если вы хотите, чтобы ваш модуль можно было загрузить через Steam Workshop. +* `Dedicated Server`: Ваш модуль также может быть запущен на сервере. Если вы хотите, чтобы ваш мод был доступен и в мультиплеере, отметьте этот пункт. +* `Editor`: Другие игроки смогут открыть ваш модуль в редакторе (Editor) и изменять его. Если вы не упакуете его для редактора, игроки не смогут открыть ваш модуль через редактор. {{% notice warning %}} -Do not forget to select your module in the “Module” dropdown list. Otherwise, you will most likely publish the Native module by accident which will take a significant amount of time. +Не забудьте выбрать свой модуль в выпадающем списке «Module». В противном случае вы, скорее всего, случайно опубликуете нативный модуль (Native), что займёт значительное количество времени. {{% /notice %}} -* After selecting these options and your module from the Modules dropdown list, proceed with the Publish button. -* After clicking the Publish button, a pop-up window for selecting a destination directory will appear. Select the destination directory, which is a writable location on your computer, and the module will be copied there as a ready-to-upload version. -* Then just upload the mod folder in the destination directory to the Steam Workshop, following the instructions mentioned in “**Creating a new Steam Workshop Item**” and “**Updating a Steam Workshop Item**” sections. +* После выбора этих опций и своего модуля в выпадающем списке Modules нажмите кнопку Publish. +* После нажатия кнопки Publish появится всплывающее окно для выбора целевой директории. Выберите целевую директорию — доступную для записи папку на вашем компьютере, — и модуль будет скопирован туда в виде готовой к загрузке версии. +* Затем просто загрузите папку мода из целевой директории в Steam Workshop, следуя инструкциям, указанным в разделах «**Создание нового элемента Steam Workshop**» и «**Обновление элемента Steam Workshop**». {{% notice warning %}} -If you, as a modder, are going to test your module after uploading to the Steam Workshop, please temporarily move your Module folder under “Steam\steamapps\common\Mount & Blade II Bannerlord\Modules” to somewhere else. If you don’t move it temporarily, then the game will try to fetch the module from Bannerlord/Modules instead of workshop/content/261550. +Если вы, как моддер, собираетесь тестировать свой модуль после загрузки в Steam Workshop, пожалуйста, временно переместите папку вашего модуля из «Steam\steamapps\common\Mount & Blade II Bannerlord\Modules» куда-нибудь ещё. Если вы не переместите её временно, игра попытается получить модуль из Bannerlord/Modules вместо workshop/content/261550. {{% /notice %}} -## Creating a new Steam Workshop Item +## Создание нового элемента Steam Workshop -### Preparing the WorkshopCreate.xml +### Подготовка WorkshopCreate.xml -Download [this file](https://download.taleworlds.com/WorkshopCreate.xml) and place it anywhere you want. You can also create one with the following code: +Скачайте [этот файл](https://download.taleworlds.com/WorkshopCreate.xml) и разместите его в любом удобном месте. Вы также можете создать его самостоятельно со следующим кодом: @@ -70,43 +71,43 @@ Download [this file](https://download.taleworlds.com/WorkshopCreate.xml) and pla -* Open the file using Notepad, Notepad++ or other tools -* Edit the `Items` to match your module - * `ModuleFolder`: A direct path of your module - * `ItemDescription`: A description that will be displayed on Steam Workshop, can be edited via the Steam UI - * `Tags`: Allows your mod to be found by filtering categories. Here are the tags you can assign to your item: +* Откройте файл с помощью Notepad, Notepad++ или других инструментов +* Отредактируйте `Items` в соответствии со своим модулем + * `ModuleFolder`: Прямой путь к вашему модулю + * `ItemDescription`: Описание, которое будет отображаться в Steam Workshop; его можно редактировать через интерфейс Steam + * `Tags`: Позволяет находить ваш мод с помощью фильтрации по категориям. Вот теги, которые можно присвоить вашему элементу: * `Type`: Graphical Enhancement, Map Pack, Partial Conversion, Sound, Total Conversion, Troops, UI, Utility, Weapons and Armour * `Setting`: Native, Antiquity, Dark Ages, Medieval, Musket Era, Modern, Sci-Fi, Fantasy, Oriental, Apocalypse, Other * `Game Mode`: Singleplayer, Multiplayer - * `Compatible Version`: v1.4.5, v1.4.6,... (the currently available versions can be found at the Steam Workshop "Browse by Tag" section) - * You’re encouraged to only use the above tags as they’re what players will be able to filter mods by. Any other tags won’t show up on the Filter list but will show up on your mod Steam Workshop page - * `Image`: Determines the featured image displayed on Steam Workshop, a direct path to it must be inserted here (the image should be smaller than 1 MB) - * `Visibility`: Determines visibility on Steam Workshop. Can be: Public, FriendsOnly, Private -* Save the changes made to `WorkshopCreate.xml` + * `Compatible Version`: v1.4.5, v1.4.6,... (текущие доступные версии можно найти в разделе Steam Workshop "Browse by Tag") + * Рекомендуется использовать только перечисленные выше теги, поскольку именно по ним игроки смогут фильтровать моды. Остальные теги не появятся в списке фильтров, но будут отображаться на странице вашего мода в Steam Workshop + * `Image`: Определяет главное изображение, отображаемое в Steam Workshop; здесь нужно указать прямой путь к нему (изображение должно быть меньше 1 МБ) + * `Visibility`: Определяет видимость в Steam Workshop. Может быть: Public, FriendsOnly, Private +* Сохраните изменения, внесённые в `WorkshopCreate.xml` {{% notice warning %}} -Steam Cloud must be enabled for the game in order to successfully upload your mod. You can verify that by right-clicking on Mount & Blade II: Bannerlord within your Steam Library, going to Properties and then General. Or by enabling Steam Cloud for all games via the Steam client Settings window, via the Cloud tab. +Для успешной загрузки вашего мода должна быть включена функция Steam Cloud для игры. Это можно проверить, щёлкнув правой кнопкой мыши на Mount & Blade II: Bannerlord в своей библиотеке Steam, перейдя в Properties, а затем во вкладку General. Либо включив Steam Cloud для всех игр через окно настроек клиента Steam, во вкладке Cloud. {{% /notice %}} {{% notice warning %}} -You may run into an error during the publishing process. An endless print of the following line: Status: k_EItemUpdateStatusInvalid 0/0 - If that occurs your upload may have completed successfully and you’re free to close the console. If the upload failed, try again. +Во время процесса публикации вы можете столкнуться с ошибкой. Бесконечный вывод следующей строки: Status: k_EItemUpdateStatusInvalid 0/0 — если это происходит, ваша загрузка, возможно, завершилась успешно, и вы можете свободно закрыть консоль. Если загрузка завершилась неудачно, попробуйте снова. {{% /notice %}} {{% notice tip %}} -The size of your uploaded module displayed on the Steam Workshop may differ from the actual size of the module. This is normal. +Размер загруженного вами модуля, отображаемый в Steam Workshop, может отличаться от фактического размера модуля. Это нормально. {{% /notice %}} -### Publishing the module -* Find the following folder `\Steam\steamapps\common\Mount & Blade II Bannerlord\bin\Win64_Shipping_Client` and confirm that the `TaleWorlds.MountAndBlade.SteamWorkshop.exe` is located inside of it -* Type `cmd` into the bar where the folder location is displayed and press `Enter` -* Type `TaleWorlds.MountAndBlade.SteamWorkshop.exe c:\path\WorkshopCreate.xml` into the console, with the path directing to your `WorkshopCreate.xml` file and press `Enter` -* If no errors appear, your mod has been successfully uploaded to Steam Workshop +### Публикация модуля +* Найдите папку `\Steam\steamapps\common\Mount & Blade II Bannerlord\bin\Win64_Shipping_Client` и убедитесь, что файл `TaleWorlds.MountAndBlade.SteamWorkshop.exe` находится внутри неё +* Введите `cmd` в адресной строке, где отображается путь к папке, и нажмите `Enter` +* Введите `TaleWorlds.MountAndBlade.SteamWorkshop.exe c:\path\WorkshopCreate.xml` в консоли, указав путь к вашему файлу `WorkshopCreate.xml`, и нажмите `Enter` +* Если ошибок не появилось, ваш мод был успешно загружен в Steam Workshop -## Updating a Steam Workshop Item +## Обновление элемента Steam Workshop -### Preparing the WorkshopUpdate.xml +### Подготовка WorkshopUpdate.xml -Download [this file](https://download.taleworlds.com/WorkshopUpdate.xml) and place it anywhere you want. You can also create one with the following code: +Скачайте [этот файл](https://download.taleworlds.com/WorkshopUpdate.xml) и разместите его в любом удобном месте. Вы также можете создать его самостоятельно со следующим кодом: @@ -133,16 +134,16 @@ Download [this file](https://download.taleworlds.com/WorkshopUpdate.xml) and pla -* Open the file using Notepad, Notepad++ or other tools -* Edit the `Items` to match your module - * `ItemId`: Insert the ID of your workshop module. You can find it by going to your workshop module page, right-clicking on a blank slot and selecting `Copy Page URL`. If you then paste the URL somewhere, you’ll see the ID. - * `ModuleFolder`: A direct path of your module - * `ChangeNotes`: Think of this as patch notes, they will be displayed on the “Change Notes” section of your Workshop module - * `Tags`: Allows your mod to be found by filtering categories. Updating tags can be done through the `WorkshopUpdate.xml` file -* Save the changes made to `WorkshopUpdate.xml` - -### Publishing the update -* Find the following folder `\Steam\steamapps\common\Mount & Blade II Bannerlord\bin\Win64_Shipping_Client` and confirm that the `TaleWorlds.MountAndBlade.SteamWorkshop.exe` is located inside of it -* Type `cmd` into the bar where the folder location is displayed and press `Enter` -* Type `TaleWorlds.MountAndBlade.SteamWorkshop.exe c:\path\WorkshopUpdate.xml` into the console, with the path directing to your `WorkshopUpdate.xml` file and press `Enter` -* If no errors appear, your mod has been successfully updated \ No newline at end of file +* Откройте файл с помощью Notepad, Notepad++ или других инструментов +* Отредактируйте `Items` в соответствии со своим модулем + * `ItemId`: Введите ID вашего модуля из мастерской. Его можно найти, перейдя на страницу своего модуля в мастерской, щёлкнув правой кнопкой мыши на пустом месте и выбрав `Copy Page URL`. Если затем вставить URL куда-нибудь, вы увидите ID. + * `ModuleFolder`: Прямой путь к вашему модулю + * `ChangeNotes`: Воспринимайте это как список изменений (патчноуты) — они будут отображаться в разделе «Change Notes» вашего модуля в мастерской + * `Tags`: Позволяет находить ваш мод с помощью фильтрации по категориям. Обновление тегов можно выполнить через файл `WorkshopUpdate.xml` +* Сохраните изменения, внесённые в `WorkshopUpdate.xml` + +### Публикация обновления +* Найдите папку `\Steam\steamapps\common\Mount & Blade II Bannerlord\bin\Win64_Shipping_Client` и убедитесь, что файл `TaleWorlds.MountAndBlade.SteamWorkshop.exe` находится внутри неё +* Введите `cmd` в адресной строке, где отображается путь к папке, и нажмите `Enter` +* Введите `TaleWorlds.MountAndBlade.SteamWorkshop.exe c:\path\WorkshopUpdate.xml` в консоли, указав путь к вашему файлу `WorkshopUpdate.xml`, и нажмите `Enter` +* Если ошибок не появилось, ваш мод был успешно обновлён diff --git a/docs/content/russian/War Sails/_index.md b/docs/content/russian/War Sails/_index.md index a08165c2..dc61fc52 100644 --- a/docs/content/russian/War Sails/_index.md +++ b/docs/content/russian/War Sails/_index.md @@ -1,5 +1,5 @@ +++ -title="War Sails" +title="War Sails (морские сражения)" weight = 100 +++ diff --git a/docs/content/russian/War Sails/ship_creation.md b/docs/content/russian/War Sails/ship_creation.md index e0d14796..8b088d3d 100644 --- a/docs/content/russian/War Sails/ship_creation.md +++ b/docs/content/russian/War Sails/ship_creation.md @@ -1,34 +1,35 @@ +++ -title = "Ship Creation" +title = "Создание корабля" description = "" weight = 1 +ai_translated = true +++ -## **1. Introduction** +## **1. Введение** -### **1.1. Purpose of the Documentation** +### **1.1. Цель документации** -This documentation is a comprehensive, end-to-end guide for creating and integrating custom ships into the game. It is written for mod authors who want to add fully functional ships to Bannerlord's naval system. You do not need to be a programmer to follow this guide, but you should be comfortable working inside the Bannerlord editor and understand the basic concepts of entities, prefabs, and scripts. +Эта документация представляет собой исчерпывающее, пошаговое руководство по созданию и интеграции пользовательских кораблей в игру. Оно написано для авторов модов, которые хотят добавить полностью функциональные корабли в морскую систему Bannerlord. Вам не обязательно быть программистом, чтобы следовать этому руководству, но вы должны уверенно работать в редакторе Bannerlord (Bannerlord editor) и понимать базовые концепции сущностей (entities), префабов (prefabs) и скриптов. -The goal is to walk you through the entire technical pipeline — from setting up the initial Nested Prefab hierarchy all the way to final in-game implementation. By following the workflows outlined here, you will produce a ship that is fully compatible with the game's physics, AI navigation, boarding, crew interaction, and upgrade systems. +Цель — провести вас через весь технический конвейер (pipeline) — от настройки исходной иерархии вложенных префабов (Nested Prefab) до финальной реализации в игре. Следуя описанным здесь рабочим процессам, вы создадите корабль, который будет полностью совместим с физикой игры, навигацией ИИ, абордажем, взаимодействием с экипажем и системами улучшений. -### **1.2. Overview of the Ship Creation Pipeline** +### **1.2. Обзор конвейера создания корабля** -The ship creation process follows a structured, layered workflow. Each layer depends on the one before it, so it is important not to skip steps. The pipeline begins with establishing the correct Nested Prefab hierarchy — this is the backbone that every other system relies on. +Процесс создания корабля следует структурированному многослойному рабочему процессу. Каждый слой зависит от предыдущего, поэтому важно не пропускать шаги. Конвейер начинается с установления правильной иерархии вложенных префабов (Nested Prefab) — это основа, на которую опираются все остальные системы. -The workflow is divided into three main stages: +Рабочий процесс разделён на три основных этапа: -> * **Core Setup (Essential):** Establishing the root entity, importing hull meshes, and configuring physics volumes (collision and buoyancy) to ensure the ship exists and floats correctly in the physics engine. Nothing else will work until this stage is complete. -> * **Gameplay Integration (Upgrades):** Implementing navigation systems (rudders, sails, oars), boarding mechanics, ballistas, and interaction points required for player control and combat. These components define how players and AI interact with the ship. -> * **Detailing & Polish (Cosmetic):** Finalizing the ship with visual upgrades, particle effects, water interactions, and decorative elements to enhance the atmosphere. These components are purely visual — removing them will not break the ship's functionality. +> * **Базовая настройка (обязательно):** Создание корневой сущности, импорт мешей корпуса и настройка физических объёмов (коллизии и плавучести), чтобы гарантировать, что корабль существует и корректно держится на плаву в физическом движке. Ничего не будет работать, пока этот этап не завершён. +> * **Игровая интеграция (улучшения):** Реализация навигационных систем (рули, паруса, вёсла), механики абордажа, баллист и точек взаимодействия, необходимых для управления игроком и боя. Эти компоненты определяют, как игроки и ИИ взаимодействуют с кораблём. +> * **Детализация и доработка (косметика):** Завершение оформления корабля визуальными улучшениями, эффектами частиц, взаимодействием с водой и декоративными элементами для усиления атмосферы. Эти компоненты чисто визуальны — их удаление не нарушит функциональность корабля. -## **2. Ship Hierarchy & Component Breakdown** +## **2. Иерархия корабля и разбор компонентов** -In this section, ship components are categorized into three main groups: Essential (Critical for gameplay), Upgrades (Gameplay features), and Cosmetics (Visual details). +В этом разделе компоненты корабля разделены на три основные группы: обязательные (критичные для геймплея), улучшения (игровые функции) и косметика (визуальные детали). -When building your ship, the full entity hierarchy should follow this general structure: +При создании корабля полная иерархия сущностей должна следовать этой общей структуре: -\[ShipName\]\_ship\_nested (Root Entity) +\[ShipName\]\_ship\_nested (корневая сущность) ├── mesh\_holder ├── floater\_volume\_holder ├── control\_point\_holder @@ -43,642 +44,642 @@ When building your ship, the full entity hierarchy should follow this general st ├── sail\_holder ├── ship\_ballista\_holder ├── wetness\_decals -├── ship\_water\_effects (visual only) +├── ship\_water\_effects (только визуально) ├── ship\_burning\_system -└── \[other cosmetic holders\] +└── \[другие косметические держатели\] -Each of these children is described in detail in the sections below. Keep this hierarchy in mind as you work — placing a component under the wrong parent is one of the most common sources of errors. +Каждый из этих дочерних элементов подробно описан в разделах ниже. Держите эту иерархию в уме во время работы — размещение компонента под неправильным родителем — одна из самых распространённых причин ошибок. -### **2.1. Essential Components (Critical)** +### **2.1. Обязательные компоненты (критичные)** -The objects in this group represent the **bare minimum** configuration required for the ship to exist in the game world, for physics to function correctly, and for basic operations to be performed. If any of these components are missing or misconfigured, the ship will either not load, not float, or behave incorrectly in-game. +Объекты этой группы представляют собой **минимально необходимую** конфигурацию, требуемую для того, чтобы корабль существовал в игровом мире, чтобы физика работала корректно и чтобы выполнялись базовые операции. Если какой-либо из этих компонентов отсутствует или настроен неверно, корабль либо не загрузится, либо не будет держаться на плаву, либо будет вести себя некорректно в игре. -#### **2.1.1. Root Entity Setup (dromon\_ship\_nested)** +#### **2.1.1. Настройка корневой сущности (dromon\_ship\_nested)** -This entity is the parent container for the entire ship prefab. Every other component in this guide is placed as a child or descendant of this entity. Throughout this documentation, we will use the "Dromon" ship as the reference example. +Эта сущность является родительским контейнером для всего префаба корабля. Каждый другой компонент в этом руководстве размещается как дочерний элемент или потомок этой сущности. На протяжении всей документации мы будем использовать корабль «Dromon» в качестве эталонного примера. -> * **Naming Convention:** We recommend using the format \[ShipName\]\_ship\_nested (e.g., dromon\_ship\_nested). While not strictly enforced by the engine, following this convention ensures your ship is easy to identify and consistent with the existing ship assets in the game. +> * **Соглашение об именовании:** Мы рекомендуем использовать формат \[ShipName\]\_ship\_nested (например, dromon\_ship\_nested). Хотя это строго не навязывается движком, следование этому соглашению гарантирует, что ваш корабль легко идентифицировать и что он соответствует существующим ассетам кораблей в игре. -**Required Setup & Attributes:** +**Необходимая настройка и атрибуты:** -**Prefab Settings:** +**Настройки префаба (Prefab Settings):** -> * **Enable Nested Prefab:** \[Checked\] - * *Reason:* This is critical for pipeline management. Enabling Nested Prefab allows the child prefabs within the hierarchy (sails, boarding machines, oars, etc.) to be opened and edited independently without having to open the entire ship. Without this, editing any sub-component will modify the whole ship file, making iterative work slow and error-prone. -> * **Enable Write Children to Separate XMLs:** \[Checked\] - * *Reason:* This ensures each child prefab saves its data into its own XML file rather than embedding everything into a single large file. This is important for version control and for keeping the ship modular — changes to one component do not risk corrupting the rest of the ship's data. +> * **Enable Nested Prefab:** \[Включено\] + * *Причина:* Это критически важно для управления конвейером. Включение Nested Prefab позволяет открывать и редактировать дочерние префабы внутри иерархии (паруса, абордажные машины, вёсла и т.д.) независимо, без необходимости открывать весь корабль целиком. Без этого редактирование любого подкомпонента будет изменять весь файл корабля, что делает итеративную работу медленной и подверженной ошибкам. +> * **Enable Write Children to Separate XMLs:** \[Включено\] + * *Причина:* Это гарантирует, что каждый дочерний префаб сохраняет свои данные в отдельный XML-файл, а не встраивает всё в один большой файл. Это важно для контроля версий и для сохранения модульности корабля — изменения в одном компоненте не рискуют повредить остальные данные корабля. -**Transform & Workspace:** +**Трансформация и рабочее пространство (Transform & Workspace):** -> * **Identity Transform:** Ensure the root entity is created at the generic identity coordinates (**Pos:** 0,0,0 | **Rot:** 0,0,0 | **Scale:** 1,1,1). - * *Reason:* The entire ship is positioned and rotated at runtime by the game's naval physics system. If the root entity has any offset or rotation baked into it, the ship will appear misaligned in-game and all child components will be offset as well. -> * **Local Space:** For all subsequent child components, perform all positioning and rotation operations using **Local Transform**. - * *Reason:* Child entities inherit the world transform of their parent. Working in local space ensures that when the root entity moves (as it will constantly during gameplay), all children move with it correctly. Working in world space will cause children to appear in the correct editor position but drift to incorrect positions in-game. +> * **Identity Transform:** Убедитесь, что корневая сущность создана с общими координатами идентичности (**Pos:** 0,0,0 | **Rot:** 0,0,0 | **Scale:** 1,1,1). + * *Причина:* Весь корабль позиционируется и вращается во время выполнения морской физической системой игры. Если у корневой сущности есть какое-либо смещение или вращение, "запечённое" в неё, корабль будет выглядеть смещённым в игре, и все дочерние компоненты также будут смещены. +> * **Local Space:** Для всех последующих дочерних компонентов выполняйте все операции позиционирования и вращения с использованием **локальной трансформации (Local Transform)**. + * *Причина:* Дочерние сущности наследуют мировую трансформацию своего родителя. Работа в локальном пространстве гарантирует, что когда корневая сущность движется (а это будет происходить постоянно во время игры), все дочерние элементы двигаются вместе с ней корректно. Работа в мировом пространстве приведёт к тому, что дочерние элементы будут отображаться в правильной позиции в редакторе, но смещаться в неправильные позиции в игре. -**Physics Configuration:** +**Настройка физики (Physics Configuration):** -> * **Physics Shape:** Assign a **Convex** physics shape that roughly encompasses the entire hull. - * *Reason:* This convex shape serves two critical purposes. First, it is the primary collision body of the ship — it determines what the ship physically bumps into in the world. Second, and more importantly for ships, it is the primary driver for the buoyancy system. The game engine calculates how much of this convex volume is submerged to determine the upward buoyancy force. If this shape is too large, the ship will float too high. If it is too small, the ship will sit too low or sink. Always use a mesh that closely follows the outer hull below the waterline. - * *Note:* If the provided mesh is not convex, the engine will attempt to approximate a convex hull automatically, but this approximation may not match the hull well. Providing a proper convex mesh is strongly recommended. -> * **Material:** Assign the wood\_ship physics material. - * *Reason:* The wood\_ship material defines how the ship's physics body responds to collisions — its friction, restitution (bounciness), and damage thresholds. Using the wrong material (or none at all) will cause the ship to behave incorrectly when colliding with terrain, other ships, or projectiles. -> * **Mass:** Input the correct physical weight of the ship. - * *Warning:* This value directly affects how the ship floats and reacts to water physics. A ship that is too light will bounce erratically on waves. A ship that is too heavy will sit too low in the water or sink entirely. Use the existing ships as reference points for appropriate mass values relative to their size. -> * **Body Flags:** Ensure the following flags are CHECKED: - * ✅ **Dynamic** — Allows the physics engine to move this body in response to forces. - * ✅ **Movable** — Required for the kinematic system that synchronizes ship movement with passengers and mounted objects. - * ✅ **Use Convex Hull** — Tells the physics engine to use the convex shape for collision. - * ✅ **Do Not Collide with Camera** — Prevents the camera from being blocked by the ship's physics body. - * ✅ **Do Not Collide with Ray Cast** — Prevents gameplay raycasts (such as targeting) from being blocked by the hull physics body. +> * **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** — предотвращает блокировку игровых рейкастов (таких как прицеливание) физическим телом корпуса. -**Important:** Any physics body added to child entities of this root must also be marked as **Movable** in its flags. This is required because the root uses a kinematic physics system — child physics bodies that are not marked Movable will not move with the ship and will detach into incorrect world positions. - -#### **2.1.2. Scripts** - -The following scripts must be added directly to the root entity. The order in which you add them does not matter, but all of them must be present for the ship to function correctly. - -> * **MissionShip:** The core script that registers this entity as a ship within the game's mission system. Without this script, the game will not recognize the entity as a ship and none of the naval gameplay systems will activate. - * **Important:** You must assign the NavMesh name to the NavMeshPrefabName field. The NavMesh is a separate asset that defines where AI agents can walk on your ship's deck. NavMesh baking is covered in detail in the attachment\_machine\_holder section (2.1.7). -> * **Volume\_generator:** Handles the generation of floating volume objects that the buoyancy system uses to keep the ship upright and stable on the water surface. - * *Best Practice:* Perform this step after adding the hull mesh in mesh\_holder, since the generator needs the mesh to estimate correct volume placement. - * Enable **Mock Generation** to preview where floaters will be placed before committing. - * *Goal:* Keep the number of floatable objects to a minimum by adjusting **Current Volume Count** or **Floater Volume Width**. More volumes give more stable floating but cost more performance. - * Ensure generated volumes match the ship's hull shape as closely as possible. - * Click **Generate Volumes** to create the volume children under floater\_volume\_holder. -> * **ShipFloatsamManager:** Handles the spawning and behavior of debris and flotsam when the ship is destroyed. Ensures that broken planks, barrels, and other objects appear on the water surface after the ship sinks. -> * **ShipClothFixer:** Manages the cloth simulation systems on the ship (primarily sails and banners). Without this script, cloth objects on the ship may behave erratically or not simulate at all when the ship moves. -> * **ShipColorAssigner:** Controls faction-based color tinting across the ship. - * Factor Color: Applied to Upgrade Pieces such as seats and oars, tinting them to match the owning faction's colors. - * Ram Debris Color: Applied to collision damage decals that appear when the ship rams another vessel. -> * **EditorShipPhysics:** A utility script used only inside the editor. It lets you simulate and preview the ship's floating physics without having to launch the game, saving significant iteration time. -> * **NavalPhysics:** Handles the core swimming and buoyancy logic at runtime. This script works in conjunction with the floater volumes to keep the ship correctly oriented and moving on the water surface. -> * **EditorShipUpgradeViewer:** An editor utility that lets you preview how different upgrade pieces (sails, shields, figureheads, etc.) will appear on the ship without launching the game. -> * **ShipAttachmentMachineConnectionLogic:** Handles the connection logic between ships during boarding. It manages the state of boarding bridges — detecting when two ships are close enough, triggering the bridge deployment animation, and linking the two ships' NavMeshes. +**Важно:** Любое физическое тело, добавленное к дочерним сущностям этого корня, также должно быть помечено как **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** -This entity contains the ship's main visual mesh and all static physics objects that are part of the ship's structure — platforms, stairs, interior decoration, and any other geometry that does not change based on upgrades. +Эта сущность содержит основной визуальный меш корабля и все статические физические объекты, являющиеся частью структуры корабля — платформы, лестницы, внутреннее убранство и любую другую геометрию, которая не изменяется в зависимости от улучшений. -> * **Transform:** Must be kept at Identity (0,0,0 | 0,0,0 | 1,1,1). The mesh\_holder should never have any offset from the root entity. All positioning of individual meshes should be done on the child entities within this holder. -> * **Physics:** Any physics body added to a child of mesh\_holder must have the **Movable** flag enabled. See the note in section 2.1.1 for the reason. +> * **Transform:** Должна оставаться в состоянии Identity (0,0,0 | 0,0,0 | 1,1,1). mesh\_holder никогда не должен иметь смещения относительно корневой сущности. Всё позиционирование отдельных мешей должно выполняться на дочерних сущностях внутри этого держателя. +> * **Physics:** Любое физическое тело, добавленное дочернему элементу mesh\_holder, должно иметь включённый флаг **Movable**. См. примечание в разделе 2.1.1 для причины. -**Required Tags on the Main Hull Mesh:** +**Необходимые теги на основном меше корпуса:** -> * rope\_physics\_body — Marks this entity as the physics anchor point for dynamic rope simulations on the ship (rigging, tying lines, etc.). Ropes attached to the ship use this tagged entity as their root attachment. -> * body\_mesh — Identifies this entity as the primary visual hull. Multiple engine systems (including ShipWaterEffects) use this tag to perform raycasts against the hull to automatically compute particle positions, waterline height, and other visual parameters. This tag must exist and the entity must have a valid MetaMesh with an accurate bounding box. -> * hull\_water\_mesh — Marks the mesh used specifically by the in-hull water simulation system. This mesh defines the visual interior surface on which the simulated deck water is rendered. +> * rope\_physics\_body — помечает эту сущность как физическую точку привязки для динамических симуляций верёвок на корабле (такелаж, завязывание линий и т.д.). Верёвки, прикреплённые к кораблю, используют эту помеченную сущность в качестве корневой точки крепления. +> * body\_mesh — идентифицирует эту сущность как основной визуальный корпус. Несколько систем движка (включая ShipWaterEffects) используют этот тег для выполнения рейкастов относительно корпуса для автоматического вычисления позиций частиц, высоты ватерлинии и других визуальных параметров. Этот тег должен существовать, а сущность должна иметь действительный MetaMesh с точным ограничивающим прямоугольником (bounding box). +> * hull\_water\_mesh — помечает меш, используемый специально системой симуляции воды внутри корпуса. Этот меш определяет визуальную внутреннюю поверхность, на которой отображается симулированная вода на палубе. -**Deckwater Setup:** Create a child object named deckwater inside mesh\_holder and assign it the tag render\_to\_depth. +**Настройка воды на палубе (Deckwater Setup):** Создайте дочерний объект с именем deckwater внутри mesh\_holder и назначьте ему тег render\_to\_depth. -> * *Reason:* The render\_to\_depth tag tells the ship water effects system to include this mesh in the top-down depth render used to define where simulated water can accumulate on the deck. Any mesh with this tag (including oar seats and other deck furniture) contributes to the depth texture. After adding or modifying render\_to\_depth meshes, press **Re-render Depth Texture** in the ShipWaterEffects script to update the simulation. +> * *Причина:* Тег render\_to\_depth указывает системе водных эффектов корабля включить этот меш в рендер глубины сверху вниз, используемый для определения того, где на палубе может скапливаться симулированная вода. Любой меш с этим тегом (включая сиденья гребцов и другую мебель палубы) вносит вклад в текстуру глубины. После добавления или изменения мешей с тегом render\_to\_depth нажмите **Re-render Depth Texture** в скрипте ShipWaterEffects, чтобы обновить симуляцию. #### **2.1.4. floater\_volume\_holder** -This entity is the container for the buoyancy volume objects automatically created by the Volume\_generator script on the root entity. You should not manually create or modify children here — always use the generator. +Эта сущность является контейнером для объектов объёма плавучести, автоматически создаваемых скриптом Volume\_generator на корневой сущности. Вы не должны вручную создавать или изменять дочерние элементы здесь — всегда используйте генератор. -> * **Verification:** After generating volumes, visually inspect them in the editor to confirm they cover the submerged portion of the hull correctly. Volumes that extend too far above the waterline will make the ship sit unnaturally high. Volumes that do not reach far enough into the hull will cause instability. +> * **Проверка:** После генерации объёмов визуально осмотрите их в редакторе, чтобы убедиться, что они правильно покрывают погружённую часть корпуса. Объёмы, выступающие слишком далеко над ватерлинией, заставят корабль сидеть неестественно высоко. Объёмы, не достигающие достаточно глубоко в корпус, вызовут нестабильность. -> * **Visibility:** Disable the visibility of this entity in the Entity Inspector once you have verified the volumes. The volume objects are purely functional and should not be visible during normal editing, as they clutter the viewport. +> * **Видимость:** Отключите видимость этой сущности в инспекторе сущностей (Entity Inspector), как только проверите объёмы. Объекты объёма чисто функциональны и не должны быть видны во время обычного редактирования, так как они загромождают вьюпорт. #### **2.1.5. control\_point\_holder** -This entity contains the ship's steering mechanism. The type of steering prefab you use here depends on the physical design of the ship. +Эта сущность содержит механизм управления рулём корабля. Тип используемого здесь префаба управления зависит от физического дизайна корабля. -> * **ShipControl\_nested:** Use this prefab for tall ships or any ship where the rudder does not physically reach the water surface, or where steering is not performed by a visible in-world rudder (e.g., the steering is abstracted). This prefab handles steering logic without requiring a physical rudder mesh interaction. -> * **ShipControlRudder\_nested:** Use this prefab for lower ships where the rudder physically extends into the water and is operated manually by an agent. This is the more physically immersive option. - * *Config:* Assign the rudder mesh and physics body to the controller's child entity as a metamesh. The physics shape of the rudder should match its visual mesh closely, as agents will physically interact with it. +> * **ShipControl\_nested:** Используйте этот префаб для высоких кораблей или любого корабля, где руль физически не достигает поверхности воды, или где управление не выполняется видимым рулём в мире (например, управление абстрагировано). Этот префаб обрабатывает логику управления без необходимости физического взаимодействия с мешем руля. +> * **ShipControlRudder\_nested:** Используйте этот префаб для более низких кораблей, где руль физически уходит в воду и управляется вручную агентом. Это более физически реалистичный вариант. + * *Настройка:* Назначьте меш руля и физическое тело дочерней сущности контроллера как metamesh. Форма физики руля должна точно соответствовать его визуальному мешу, так как агенты будут физически взаимодействовать с ним. #### **2.1.6. climbers\_holder** -This entity contains the prefabs that allow agents (both AI and players) to climb from the water surface onto the ship's deck. This is essential for boarding sequences where agents swim to the ship. +Эта сущность содержит префабы, которые позволяют агентам (как ИИ, так и игрокам) взбираться с поверхности воды на палубу корабля. Это необходимо для последовательностей абордажа, где агенты плывут к кораблю. -Use the prefabs: longboat\_rope\_climber\_small\_nested, longboat\_rope\_climber\_medium\_nested, or longboat\_rope\_climber\_large\_nested depending on the height of the ship's railing above the water. +Используйте префабы: longboat\_rope\_climber\_small\_nested, longboat\_rope\_climber\_medium\_nested или longboat\_rope\_climber\_large\_nested в зависимости от высоты поручней корабля над водой. -Each climber prefab contains three key child entities: +Каждый префаб верёвочной лестницы (climber) содержит три ключевые дочерние сущности: -> * climb\_point — The position on the deck where the agent lands after completing the climb animation. Place this on the deck surface, inboard of the railing. -> * end\_position — The top of the climbing animation. This should be at or just above the railing height. -> * standing\_point — The bottom of the climbing animation, at water level. This is where the agent begins the climb. You can adjust the precise starting position via the script on this entity. +> * climb\_point — позиция на палубе, где агент приземляется после завершения анимации взбирания. Разместите это на поверхности палубы, внутри от поручней. +> * end\_position — верхняя точка анимации взбирания. Это должно быть на уровне поручней или чуть выше. +> * standing\_point — нижняя точка анимации взбирания, на уровне воды. Отсюда агент начинает подъём. Вы можете скорректировать точную начальную позицию через скрипт на этой сущности. -*Reason:* Without correctly placed climbers, agents that end up in the water near the ship will have no way to reboard, breaking the boarding gameplay loop. +*Причина:* Без правильно размещённых climbers агенты, оказавшиеся в воде рядом с кораблём, не смогут снова забраться на борт, что нарушит игровой цикл абордажа. -#### **2.1.7. attachment\_machine\_holder (Boarding System)** +#### **2.1.7. attachment\_machine\_holder (система абордажа)** -This section contains the prefabs required for the boarding mechanics. This is one of the more complex parts of the ship setup. There are two main prefab types: +Этот раздел содержит префабы, необходимые для механики абордажа. Это одна из наиболее сложных частей настройки корабля. Есть два основных типа префабов: -> * **attachment\_machine\_nested:** Contains all entities required for both incoming and outgoing boarding — i.e., this handles our ship boarding an enemy and an enemy boarding our ship. -> * **attachment\_point\_machine\_nested:** Contains entities required only for an enemy ship to board our ship (the receiving side of a boarding action). +> * **attachment\_machine\_nested:** Содержит все сущности, необходимые как для входящего, так и для исходящего абордажа — то есть обрабатывает как абордаж нашим кораблём вражеского, так и абордаж врагом нашего корабля. +> * **attachment\_point\_machine\_nested:** Содержит сущности, необходимые только для того, чтобы вражеский корабль мог взять на абордаж наш корабль (принимающая сторона абордажа). -**a) attachment\_machine\_nested Structure:** +**a) Структура attachment\_machine\_nested:** -> * distance\_helper: A visual entity in the editor that shows the minimum required distance between two ships before a boarding bridge can be deployed. This prevents bridges from overlapping each other or clipping through geometry. -> * **attachment\_machine (Parent):** - * hook: The visual representation of the grappling hook thrown by agents when initiating boarding. This should be a small mesh placed at the hook's resting position. - * pilot: A non-physics entity placed on the deck directly above where the boarding bridge's NavMesh connection should begin. The game uses the position of this entity to stitch the bridge's NavMesh to the ship's deck NavMesh. See the NavMesh configuration section below. - * focus\_object: The physics object that agents must hit with their hook throw for a successful boarding attempt. Place this at the ship's railing where the hook would realistically catch. - * pile\_holder: A parent entity containing the visual ropes and hanging elements of the boarding setup. These are purely visual — they have no physics or interaction. +> * distance\_helper: визуальная сущность в редакторе, показывающая минимальное необходимое расстояние между двумя кораблями, прежде чем абордажный мостик может быть развёрнут. Это предотвращает наложение мостиков друг на друга или прохождение сквозь геометрию. +> * **attachment\_machine (родитель):** + * hook: визуальное представление абордажного крюка, бросаемого агентами при инициировании абордажа. Это должен быть небольшой меш, размещённый в позиции покоя крюка. + * pilot: сущность без физики, размещённая на палубе прямо над тем местом, где должно начинаться соединение NavMesh абордажного мостика. Игра использует позицию этой сущности для сшивания NavMesh мостика с NavMesh палубы корабля. См. раздел настройки NavMesh ниже. + * focus\_object: физический объект, который агенты должны поразить броском крюка для успешной попытки абордажа. Разместите это на поручнях корабля, где крюк реалистично мог бы зацепиться. + * pile\_holder: родительская сущность, содержащая визуальные верёвки и свисающие элементы абордажной установки. Они чисто визуальны — у них нет физики или взаимодействия. -**b) attachment\_point\_machine\_nested Structure:** +**b) Структура attachment\_point\_machine\_nested:** -> * hook\_attach\_point: A non-physics entity indicating where an enemy's grappling hook lands on our railing after a successful hook throw. Place this on the railing surface. -> * pilot: A non-physics entity requiring a NavMesh face underneath it for bridge NavMesh connection. Functions identically to the pilot in attachment\_machine\_nested. -> * **visual (Parent):** - * bridge\_target\_point: Parent for the non-physics visual objects that appear on the railing and deck after the enemy sets up a bridge. Default visibility should be Off — the game activates these when a bridge is established. - * bridge\_connection\_point: Defines the start or end point of the boarding bridge. Must be placed precisely on the railing, ensuring it is not buried inside the railing's physics mesh. If this point is inside geometry, the bridge will clip incorrectly. - * bridge\_source\_point: Parent for non-physics visual objects that appear after the hook successfully catches and the bridge begins deploying. Default visibility should be Off. - * focus\_object: The physics object that must be hit for a successful hook shot from an enemy ship. - * capsule\_physics\_a: A physics capsule that allows agents to climb from the deck up to the railing height when a bridge is active. This object is inactive when no bridge is present — activating it when no bridge exists would let agents walk off the ship into the air. - * *Snap Requirement:* The top of this capsule must snap exactly to the bridge\_connection\_point. - * *Auto-Snap:* You can place it manually by enabling physics visuals, or use the **Auto Arrange Bridge Ramp Physics** button in the root entity's Volume\_generator script to automatically snap all capsule physics objects at once. +> * 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: An AI barrier that prevents agents from walking off the ship at the boarding connection point when no bridge is present. This barrier deactivates automatically when a bridge is established, allowing agents to cross. +* \_barrier\_ai\_04x04m\_nested: барьер ИИ, предотвращающий схождение агентов с корабля в точке соединения абордажа, когда мостик отсутствует. Этот барьер автоматически деактивируется, когда мостик установлен, позволяя агентам переходить. -**c) NavMesh Configuration & Baking:** -The NavMesh defines where AI agents can walk on your ship's deck. It must be baked correctly for boarding bridges to function. The bridge system connects two ships' NavMeshes dynamically at runtime, and the IDs below are how it knows which face to connect to. +**c) Настройка и запекание NavMesh:** +NavMesh определяет, где агенты ИИ могут ходить по палубе вашего корабля. Он должен быть корректно запечён, чтобы абордажные мостики функционировали. Система мостиков динамически соединяет NavMesh двух кораблей во время выполнения, и приведённые ниже ID — это то, как она узнаёт, с какой гранью соединяться. -> * **Unique IDs:** In the ShipAttachmentPointMachine script (found in both machine prefabs), locate the RelatedShipNavmeshOffset field. Enter a unique integer ID here for each machine. No two machines on the same ship should share an ID. -> * **Face IDs:** In the ship's NavMesh, the face located directly beneath the pilot entity of each machine must have the same ID as entered in RelatedShipNavmeshOffset. The game uses this matching ID to know which NavMesh face is the connection point for each bridge. -> * **General Deck:** All other NavMesh faces on the ship's deck that are not bridge connection points should be assigned ID 0\. +> * **Уникальные ID:** В скрипте ShipAttachmentPointMachine (находится в обоих префабах машин) найдите поле RelatedShipNavmeshOffset. Введите здесь уникальный целочисленный ID для каждой машины. Никакие две машины на одном корабле не должны иметь одинаковый ID. +> * **ID граней:** В NavMesh корабля грань, расположенная непосредственно под сущностью pilot каждой машины, должна иметь тот же ID, что введён в RelatedShipNavmeshOffset. Игра использует этот соответствующий ID, чтобы знать, какая грань NavMesh является точкой соединения для каждого мостика. +> * **Общая палуба:** Всем остальным граням NavMesh на палубе корабля, не являющимся точками соединения мостиков, должен быть назначен ID 0. -**Baking and Saving:** +**Запекание и сохранение:** -> 1. Select all NavMesh faces. -> 2. Go to the MissionShip script on the root entity. -> 3. Click **SaveNavMeshFromLocal**. -> 4. Enter a filename and save it to your mod's module folder. -> 5. Enter this filename into the NavMeshPrefabName field in the MissionShip script. +> 1. Выберите все грани NavMesh. +> 2. Перейдите к скрипту MissionShip на корневой сущности. +> 3. Нажмите **SaveNavMeshFromLocal**. +> 4. Введите имя файла и сохраните его в папке модуля вашего мода. +> 5. Введите это имя файла в поле NavMeshPrefabName в скрипте MissionShip. #### **2.1.8. barrier\_holder** -This entity contains barrier physics objects that prevent AI agents from walking off the ship's edges or into areas they should not reach (below-deck openings, the end of a bowsprit, etc.). +Эта сущность содержит объекты физических барьеров, которые предотвращают сход агентов ИИ с краёв корабля или попадание в области, куда они не должны попадать (отверстия в трюм, конец бушприта и т.д.). -Use prefabs: \_barrier\_ai\_04x04m\_nested or \_barrier\_ai\_04x08m\_nested. These are functionally identical — the only difference is their default size. Scale them as needed to cover the area. +Используйте префабы: \_barrier\_ai\_04x04m\_nested или \_barrier\_ai\_04x08m\_nested. Они функционально идентичны — единственное различие заключается в их размере по умолчанию. Масштабируйте их по мере необходимости для покрытия нужной области. -*Reason:* Without barriers, the AI NavMesh system may generate valid paths that lead agents off the edge of the ship. The barriers create invisible walls that the NavMesh system respects, keeping agents on the deck. +*Причина:* Без барьеров система NavMesh ИИ может генерировать корректные пути, которые ведут агентов за край корабля. Барьеры создают невидимые стены, которые система NavMesh учитывает, удерживая агентов на палубе. #### **2.1.9. ship\_target\_point** -This entity holds the ShipTargetMissionObject script and must be present on every ship. It registers the ship as a **targetable object** within the game's combat system — without it, ranged weapons such as ballistas cannot lock onto the ship. +Эта сущность содержит скрипт ShipTargetMissionObject и должна присутствовать на каждом корабле. Она регистрирует корабль как **целевой объект (targetable object)** в боевой системе игры — без неё дальнобойное оружие, такое как баллисты, не может захватить корабль в прицел. -**What it does:** +**Что она делает:** -> * Marks the ship as a valid target for ranged weapons (TargetFlags.IsShip | TargetFlags.IsMoving). -> * Reports the ship's current velocity so projectiles can lead their aim correctly against a moving ship. -> * Provides a target priority value that scales with the ship's remaining crew count and hull health. A heavily damaged or nearly crewless ship becomes a lower-priority target automatically. -> * When the ship is sinking, it adds the NotAThreat flag so AI ranged units stop targeting it and redirect fire elsewhere. +> * Помечает корабль как допустимую цель для дальнобойного оружия (TargetFlags.IsShip | TargetFlags.IsMoving). +> * Сообщает текущую скорость корабля, чтобы снаряды могли правильно вести прицеливание по движущемуся кораблю. +> * Предоставляет значение приоритета цели, которое масштабируется в зависимости от оставшегося количества экипажа и здоровья корпуса корабля. Сильно повреждённый или почти лишённый экипажа корабль автоматически становится целью с более низким приоритетом. +> * Когда корабль тонет, добавляется флаг NotAThreat, чтобы дальнобойные подразделения ИИ прекратили целиться в него и перенаправили огонь в другое место. -**Setup:** Add the ship\_target\_point nested prefab as a direct child of the ship root. No additional configuration is required — the script reads the ship's state automatically at runtime via the MissionShip script on the root entity. +**Настройка:** Добавьте вложенный префаб ship\_target\_point как прямой дочерний элемент корня корабля. Дополнительная настройка не требуется — скрипт автоматически считывает состояние корабля во время выполнения через скрипт MissionShip на корневой сущности. #### **2.1.10. kinematic\_batch\_entity** -The kinematic\_batch\_entity system handles physics optimization for the ship. Without it, every child entity on the ship with a physics body would be simulated individually, which becomes expensive quickly. This system merges all those physics shapes into a single batched body that moves with the ship root — at a fraction of the cost. +Система kinematic\_batch\_entity обрабатывает оптимизацию физики для корабля. Без неё каждая дочерняя сущность на корабле с физическим телом симулировалась бы по отдельности, что быстро становится затратным. Эта система объединяет все эти физические формы в единое пакетное тело, которое движется вместе с корнем корабля — за долю стоимости. -**How it works:** The ship root owns the main physics body (the convex hull). All the detailed collision shapes on child entities — hull planks, deck surfaces, structural parts — need to move with the ship but do not need their own simulation. The kinematic\_batch\_entity collects all of these into two batching containers: +**Как это работает:** Корень корабля владеет основным физическим телом (выпуклым корпусом). Все детальные формы коллизии на дочерних сущностях — доски корпуса, поверхности палубы, структурные части — должны двигаться вместе с кораблём, но не нуждаются в собственной симуляции. kinematic\_batch\_entity собирает всё это в два контейнера пакетирования: -> * simulated — Batches shapes used for full physics interaction (collision response, agents walking on deck, etc.) -> * ray\_cast — Batches shapes used only for raycasts (targeting, line-of-sight, etc.) +> * simulated — пакетирует формы, используемые для полного физического взаимодействия (реакция на столкновения, ходьба агентов по палубе и т.д.) +> * ray\_cast — пакетирует формы, используемые только для рейкастов (прицеливание, прямая видимость и т.д.) -**Required Setup:** -Add the kinematic\_batch\_entity as a nested prefab directly under the ship root. The prefab is located at: NavalDLC/NestedPrefabs/kinematic\_batch\_entity.xml +**Необходимая настройка:** +Добавьте kinematic\_batch\_entity как вложенный префаб непосредственно под корнем корабля. Префаб расположен по пути: NavalDLC/NestedPrefabs/kinematic\_batch\_entity.xml -After placing it, verify the following in the entity inspector: +После размещения проверьте следующее в инспекторе сущностей: -> * Its transform is identity (position 0,0,0 — no rotation, no scale offset). -> * Its body flag includes Moveable. -> * It carries the tag batched\_physics\_entity. -> * Both the simulated and ray\_cast children must be present. The engine will warn if either is missing. +> * Его трансформация является identity (позиция 0,0,0 — без вращения, без смещения масштаба). +> * Его флаг тела включает Moveable. +> * Он несёт тег batched\_physics\_entity. +> * Должны присутствовать оба дочерних элемента, simulated и ray\_cast. Движок выдаст предупреждение, если какой-либо из них отсутствует. -**Marking entities for batching:** For each child entity whose physics shape should be merged into the batch, enable the **Move To Batched Kinematic** option in its physics properties. +**Пометка сущностей для пакетирования:** Для каждой дочерней сущности, чья физическая форма должна быть объединена в пакет, включите опцию **Move To Batched Kinematic** в её свойствах физики. -In the entity's **Physics** panel: +В панели **Physics** сущности: -> 1. Assign a physics shape (a bo\_ body). -> 2. Enable the Moveable body flag. -> 3. Enable **Move To Batched Kinematic**. +> 1. Назначьте физическую форму (тело bo\_). +> 2. Включите флаг тела Moveable. +> 3. Включите **Move To Batched Kinematic**. -**What to batch:** Hull mesh, deck structures, mast holders, hull plating variants, fixed structural geometry. -**What NOT to batch:** The ship root itself, the kinematic\_batch\_entity and its children, AI barrier entities, rope/cloth physics, and any entities that animate or detach independently at runtime. -**Upgrade variants:** If your ship has multiple hull variants under an upgrade slot, each variant can have **Move To Batched Kinematic** enabled. The engine only includes shapes that are active when the ship is initialized — ensure exactly one variant per slot is active at startup. +**Что пакетировать:** меш корпуса, структуры палубы, держатели мачт, варианты обшивки корпуса, фиксированную структурную геометрию. +**Что НЕ пакетировать:** сам корень корабля, kinematic\_batch\_entity и его дочерние элементы, сущности барьеров ИИ, физику верёвок/ткани, а также любые сущности, которые анимируются или отсоединяются независимо во время выполнения. +**Варианты улучшений:** Если у вашего корабля несколько вариантов корпуса под слотом улучшения, для каждого варианта можно включить **Move To Batched Kinematic**. Движок включает только формы, которые активны при инициализации корабля — убедитесь, что при запуске активен ровно один вариант на слот. -**Common validation errors:** +**Распространённые ошибки проверки:** -> * No entity tagged batched\_physics\_entity found → *"Ship Prefab must contain a root batched physics entity\!"* -> * kinematic\_batch\_entity does not have identity transform → *"Batched physics entity should have identity matrix frame\!"* -> * Missing simulated or ray\_cast child → *"Ships should have a 'kinematics'/'raycast' batch entity\!"* +> * Не найдена сущность с тегом 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\!"* -If any of these warnings appear, physics batching is not working and the ship may have performance issues or missing collision. +Если появляется любое из этих предупреждений, пакетирование физики не работает, и у корабля могут быть проблемы с производительностью или отсутствующая коллизия. #### **2.1.11. spawn\_point\_holder** -This entity defines all spawn locations for players and AI troops on the ship. The game's mission system reads these points to determine where to place agents at the start of a naval battle. +Эта сущность определяет все места появления (spawn) для игроков и отрядов ИИ на корабле. Система миссии игры считывает эти точки, чтобы определить, где разместить агентов в начале морского сражения. -> * sp\_troop\_inner\_deck\_nested: Spawn points for inner deck troops — agents positioned away from the ship's edges, typically in the center or below decks. -> * sp\_troop\_outer\_deck\_nested: Spawn points for outer deck troops — agents positioned near the railings and edges, such as archers and sailors. -> * sp\_troop\_captain\_nested: The spawn point for the ship's captain. -> * sp\_troop\_crew\_spawn\_nested: Spawn points used for reinforcement troops arriving during battle. +> * sp\_troop\_inner\_deck\_nested: точки появления для отрядов внутренней палубы — агентов, размещённых вдали от краёв корабля, обычно в центре или под палубой. +> * sp\_troop\_outer\_deck\_nested: точки появления для отрядов внешней палубы — агентов, размещённых возле поручней и краёв, таких как лучники и моряки. +> * sp\_troop\_captain\_nested: точка появления капитана корабля. +> * sp\_troop\_crew\_spawn\_nested: точки появления, используемые для подкреплений, прибывающих во время боя. -**rally\_point:** Create an empty entity and place it at the front of the ship, on the NavMesh surface. +**rally\_point:** Создайте пустую сущность и разместите её в передней части корабля, на поверхности NavMesh. -> * Assign the tag rally\_point to this entity. -> * Rename the entity to rally\_point for clarity. -> * *Reason:* This is the gathering point AI agents move toward when given a rally order. Without a rally point, AI agents will have no defined gathering location and may behave erratically when ordered to regroup. +> * Назначьте тег rally\_point этой сущности. +> * Переименуйте сущность в rally\_point для ясности. +> * *Причина:* это точка сбора, к которой агенты ИИ движутся при получении приказа о сборе. Без точки сбора агенты ИИ не будут иметь определённого места сбора и могут вести себя неадекватно при приказе перестроиться. #### **2.1.12. rudders\_holder** -This entity defines the rudder's position for the swimming and buoyancy physics calculations — specifically, it tells the physics system where the ship's steering resistance is applied in the water. +Эта сущность определяет позицию руля для расчётов физики плавания и плавучести — конкретно, она сообщает физической системе, где в воде прикладывается сопротивление руления корабля. -> * **Placement:** Place this entity at the very rear of the ship, as close to the water surface as possible. -> * **Setup:** Add an empty entity as a child, name it rudder\_stock, and assign the tag rudder\_stock to it. -> * *Reason:* The physics system uses the rudder\_stock tag to locate the steering point of the ship. Placing this incorrectly (too far forward or too high) will cause the ship to handle unrealistically — it may turn too quickly, too slowly, or pivot around the wrong point. +> * **Размещение:** Разместите эту сущность в самой задней части корабля, как можно ближе к поверхности воды. +> * **Настройка:** Добавьте пустую сущность в качестве дочернего элемента, назовите её rudder\_stock и назначьте ей тег rudder\_stock. +> * *Причина:* физическая система использует тег rudder\_stock, чтобы определить точку руления корабля. Неправильное размещение (слишком далеко вперёд или слишком высоко) приведёт к нереалистичному поведению корабля при управлении — он может поворачивать слишком быстро, слишком медленно или вращаться вокруг неправильной точки. #### **2.1.13.oars\_holder** -*This holder contains the ship's oar systems. Oars are a gameplay upgrade — they determine the ship's speed when sailing without wind. The oar\_deck prefab handles both the visual oar meshes and the agent seating system for rowers.* +*Этот держатель содержит системы вёсел корабля. Вёсла являются игровым улучшением — они определяют скорость корабля при плавании без ветра. Префаб oar\_deck обрабатывает как визуальные меши вёсел, так и систему посадки агентов для гребцов.* -> * *Root Setup: Create an empty entity at Identity and name it oars\_holder.* -> * *Add the oar\_deck prefab as a child. Rename it based on its type:* - * *oar\_deck\_upper: Rowers are seated on the open deck, visible to the player.* - * *oar\_deck\_lower: Rowers are seated inside the hull, not directly visible.* +> * *Настройка корня: создайте пустую сущность в Identity и назовите её oars\_holder.* +> * *Добавьте префаб oar\_deck как дочерний элемент. Переименуйте его в зависимости от типа:* + * *oar\_deck\_upper: гребцы сидят на открытой палубе, видимой игроку.* + * *oar\_deck\_lower: гребцы сидят внутри корпуса, не видны напрямую.* -**a) oar\_deck\_upper (Visible Oarsmen):** +**a) oar\_deck\_upper (видимые гребцы):** -> * *Configuration:* Select the oar\_deck\_upper entity and click **ManageOarMachines** in the ShipOarDeck script. -> * *Initial Setup:* Do not check **Override Prefabs** when creating for the first time. -> * *Prefab Set:* Select the set that matches your ship's size (UpperDeck 4m, 6m, or 8m — the number refers to the spacing between oar positions). -> * *Positioning:* Use the **Count**, **Span**, and **Offset** values to align the oar positions with your hull. This requires iteration — adjust the values, click apply, and visually verify the positions. The oar tips should enter the water cleanly and the handles should sit naturally in the agents' hands. -> * *Seat Heights (Critical):* Use the **Adjust Seat Heights** feature after positioning. This is mandatory. The rowing animation is fixed, and the seats must be at the correct height for the animation to align with the benches. If seat heights are wrong, rowers will visually clip through or float above their seats. +> * *Настройка:* выберите сущность oar\_deck\_upper и нажмите **ManageOarMachines** в скрипте ShipOarDeck. +> * *Начальная настройка:* не отмечайте **Override Prefabs** при создании в первый раз. +> * *Набор префабов:* выберите набор, соответствующий размеру вашего корабля (UpperDeck 4m, 6m или 8m — число означает расстояние между позициями вёсел). +> * *Позиционирование:* используйте значения **Count**, **Span** и **Offset**, чтобы выровнять позиции вёсел с корпусом. Это требует итерации — настройте значения, нажмите apply и визуально проверьте позиции. Кончики вёсел должны чисто входить в воду, а рукоятки должны естественно располагаться в руках агентов. +> * *Высоты сидений (критично):* используйте функцию **Adjust Seat Heights** после позиционирования. Это обязательно. Анимация гребли фиксирована, и сиденья должны быть на правильной высоте, чтобы анимация совпадала со скамьями. Если высоты сидений неправильные, гребцы будут визуально проваливаться сквозь или парить над своими местами. -> * *Angles:* Adjust the active (in-water) and retracted (raised) angle of the oars to match your hull geometry. -> * *Mirroring:* Once one side is correctly configured, use the **Mirror** feature to copy all settings to the opposite side. +> * *Углы:* отрегулируйте активный (в воде) и убранный (поднятый) угол вёсел в соответствии с геометрией вашего корпуса. +> * *Зеркалирование:* как только одна сторона правильно настроена, используйте функцию **Mirror**, чтобы скопировать все настройки на противоположную сторону. -**b) oar\_deck\_lower (Internal Rowers):** +**b) oar\_deck\_lower (внутренние гребцы):** -> * *Setup:* Follows the same process as oar\_deck\_upper, but select the **Lower Deck** prefab set. -> * *No seat height adjustment is required for lower deck rowers.* -> * *Ensure the oars align with and exit cleanly through the oar ports in the hull mesh. Misaligned oars will visually clip through the hull.* -> * *Retracted State:* Ensure the retracted oar angle places the oars completely inside the hull. Oars that stick out when retracted will clip through the hull and look incorrect. +> * *Настройка:* следует тому же процессу, что и oar\_deck\_upper, но выберите набор префабов **Lower Deck**. +> * *Регулировка высоты сиденья не требуется для гребцов нижней палубы.* +> * *Убедитесь, что вёсла выровнены и чисто выходят через весельные порты в меше корпуса. Смещённые вёсла будут визуально проходить сквозь корпус.* +> * *Убранное состояние:* убедитесь, что угол убранного весла размещает вёсла полностью внутри корпуса. Вёсла, торчащие наружу в убранном состоянии, будут проходить сквозь корпус и выглядеть некорректно.* -**c) Upgrade System Integration:** +**c) Интеграция с системой улучшений:** -> * *Oars are treated as upgrade pieces by the game's upgrade system.* -> * *Different oar sets (bronze-tipped, fire-hardened, etc.) can be created by editing the ship\_upgrade\_pieces.xml and ship\_slots.xml files, using existing oar entries as a reference.* -> * *When adding new oar types, verify the prefab hierarchy structure matches existing types, or the upgrade system will not recognize the new piece.* +> * *Вёсла рассматриваются игровой системой улучшений как элементы улучшений.* +> * *Различные наборы вёсел (с бронзовыми наконечниками, закалённые огнём и т.д.) можно создавать, редактируя файлы ship\_upgrade\_pieces.xml и ship\_slots.xml, используя существующие записи вёсел в качестве образца.* +> * *При добавлении новых типов вёсел убедитесь, что структура иерархии префаба соответствует существующим типам, иначе система улучшений не распознает новый элемент.* -#### **2.1.14. sail\_holder (War Sails System)** +#### **2.1.14. sail\_holder (система War Sails)** -Sails are one of the most technically complex components of the ship. They use a combination of skeletal animation, blend shape morphs, and real-time cloth simulation to achieve realistic behavior in wind. Read this section carefully before beginning sail setup. +Паруса являются одним из наиболее технически сложных компонентов корабля. Они используют комбинацию скелетной анимации, морфинга форм смешивания (blend shape morphs) и симуляции ткани в реальном времени для достижения реалистичного поведения на ветру. Внимательно прочитайте этот раздел перед началом настройки парусов. -There are two sail types: **Square** (rectangular sails hung from a yard) and **Lateen** (triangular sails on an angled boom). Each type comes in three size variants (small, medium, large), giving six total sail prefabs. +Существует два типа парусов: **прямой (Square)** (прямоугольные паруса, подвешенные на рее) и **латинский (Lateen)** (треугольные паруса на наклонной гике). Каждый тип имеет три варианта размера (малый, средний, большой), что в сумме даёт шесть префабов парусов. -**a) Asset Preparation:** +**a) Подготовка ассетов:** -> * **Cloth Simulation Mesh:** The sail mesh used for cloth simulation must fit within **15m × 15m × 15m** dimensions in its default (fully open) state. The prefab entity can be scaled in-game, but the source mesh must stay within this limit. -> * **Topology:** The mesh's polygon density and edge flow control how the cloth deforms. Denser topology in areas that should billow will produce more detailed cloth movement. +> * **Меш симуляции ткани:** меш паруса, используемый для симуляции ткани, должен помещаться в границы **15м × 15м × 15м** в своём состоянии по умолчанию (полностью открытом). Сущность префаба может быть масштабирована в игре, но исходный меш должен оставаться в пределах этого ограничения. +> * **Топология:** плотность полигонов и поток рёбер меша управляют тем, как деформируется ткань. Более плотная топология в областях, которые должны вздыматься, даст более детализированное движение ткани. -**Vertex Constraints (Critical — using Vertex Color channels):** +**Ограничения вершин (критично — с использованием каналов цвета вершин, Vertex Color):** -> * **Alpha channel \= 0:** Vertices that must not move (attached to the mast or boom). Without this, the sail will detach from its mount during simulation. -> * **Red channel \= 0:** Vertices connected to the left control bone. -> * **Green channel \= 0:** Vertices connected to the right control bone. -> * **Blue channel \= 0:** Vertices in stitched areas (seams). These areas simulate tension between panels. -> * *In-Game:* Enable **Create Stitching Constraints** in the cloth settings for stitching to take effect. +> * **Альфа-канал \= 0:** вершины, которые не должны двигаться (прикреплённые к мачте или гику). Без этого парус отсоединится от своего крепления во время симуляции. +> * **Красный канал \= 0:** вершины, соединённые с левой контрольной костью. +> * **Зелёный канал \= 0:** вершины, соединённые с правой контрольной костью. +> * **Синий канал \= 0:** вершины в сшитых областях (швах). Эти области симулируют натяжение между панелями. +> * *В игре:* включите **Create Stitching Constraints** в настройках ткани, чтобы сшивание вступило в силу. -**b) Rigging & Skeleton:** +**b) Такелаж и скелет:** -> * A skeleton drives the control bones that adjust sail tension and yard angle. -> * **Square Sail:** Uses 2 control bones (one for each end of the yard). -> * **Lateen Sail:** Uses 1 control bone (the tip of the boom). -> * Bone names must match the names shown in the reference hierarchy images exactly, even if the skeleton object itself has a different name. +> * Скелет управляет контрольными костями, которые регулируют натяжение паруса и угол реи. +> * **Прямой парус (Square Sail):** использует 2 контрольные кости (по одной для каждого конца реи). +> * **Латинский парус (Lateen Sail):** использует 1 контрольную кость (конец гика). +> * Имена костей должны точно совпадать с именами, показанными на эталонных изображениях иерархии, даже если сам объект скелета имеет другое имя. -**c) Animation & States:** +**c) Анимация и состояния:** -> * **Morph Animation:** A 200-frame morph animation is required, representing the sail transitioning from fully open to fully closed. The same morph is played in reverse for the unfurling animation. This animation drives the furling and unfurling sequence players see when the sail order is given. -> * **Closed State:** When fully furled, the cloth mesh is swapped with a static mesh representing the bundled sail. The cloth simulation is inactive in this state. -> * **Burning State:** If the sail catches fire, it transitions to a free-hanging mesh that simulates a torn, burning sail. This mesh does not require a skeleton or morph keys — it is purely visual cloth with no control. +> * **Анимация морфинга:** требуется 200-кадровая анимация морфинга, представляющая переход паруса из полностью открытого в полностью закрытое состояние. Тот же морфинг воспроизводится в обратном порядке для анимации разворачивания. Эта анимация управляет последовательностью сворачивания и разворачивания, которую игроки видят при отдаче приказа о парусах. +> * **Закрытое состояние:** когда парус полностью убран, меш ткани заменяется статическим мешем, представляющим собранный парус. Симуляция ткани неактивна в этом состоянии. +> * **Состояние горения:** если парус загорается, он переходит в свободно висящий меш, симулирующий рваный, горящий парус. Этот меш не требует скелета или ключей морфинга — это чисто визуальная ткань без управления. -**d) Prefab Setup (using sail\_square\_medium\_nested as example):** +**d) Настройка префаба (на примере sail\_square\_medium\_nested):** -Add the sail\_visual script to the topmost parent of the sail prefab and select the correct sail\_type enum value matching your sail variant. +Добавьте скрипт sail\_visual к самому верхнему родителю префаба паруса и выберите правильное значение перечисления sail\_type, соответствующее вашему варианту паруса. -Main children: +Основные дочерние элементы: -> * pulley\_systems\_holder: Contains all rope visual systems. - * stability\_ropes: Ropes connecting the control bones to the deck (stays and shrouds). Each rope entity's tag must match the name of the bone it connects to. - * static\_ropes\_parent: Static decorative ropes. Tag attached\_to\_yard for ropes that connect to the yard; tag big\_rope for ropes that connect from the yard down to the hull. - * sail\_fold\_pulley\_parent: Ropes that gather the sail when furling. Tag each rope's entity with the name of the bone it is controlled by. - * sail\_rotate\_pulley\_parent: Ropes responsible for rotating the yard to catch the wind angle. -> * force\_center\_entity: Must have the tag force\_center\_entity. Defines the point at which wind force is applied to the sail for physics calculations. Position this at the center of the sail's surface area. -> * sail\_mast: Place all mast visual mesh entities under this child. -> * yaw\_rotation\_entity: Must have the tag yaw\_rotation\_entity. Place your prepared sail and yard assets under this entity. This entity rotates to simulate the yard turning to face the wind. -> * sail\_upgrade\_slot: The upgrade slot entity for sail-level upgrades. +> * 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. Upgrade & Gameplay Components** +### **2.2. Компоненты улучшений и геймплея** -These components extend the ship's capabilities, define its combat capacity, or change appearance and stats based on the ship's upgrade level. They are optional in the sense that the ship will exist and float without them, but no naval gameplay (sailing, combat, upgrades) will function correctly without them. +Эти компоненты расширяют возможности корабля, определяют его боевую мощь или изменяют внешний вид и характеристики в зависимости от уровня улучшения корабля. Они необязательны в том смысле, что корабль будет существовать и держаться на плаву без них, но никакой морской геймплей (плавание, бой, улучшения) не будет функционировать корректно без них. -The upgrade system is driven by several XML files that you must edit to register your ship and its upgrade pieces with the game: +Система улучшений управляется несколькими XML-файлами, которые вы должны отредактировать, чтобы зарегистрировать свой корабль и его элементы улучшений в игре: -> * ship\_slots.xml: Defines all upgrade slot types available for ships. Every upgrade piece type your ship uses must have a corresponding entry here. The IDs defined in this file are referenced by the other XMLs below. -> * ship\_upgrade\_pieces.xml: Defines the individual upgrade pieces — their stats, visual effects, descriptions, and which slot ID they belong to. -> * mission\_ships.xml: Registers your ship as a usable ship in missions. Contains the ship's ID, prefab name, mass, and other mission-level properties. -> * ship\_hulls.xml: Defines the ship's mission statistics (health, speed, maneuverability, etc.) and specifies which upgrade slots are available on this hull type. +> * ship\_slots.xml: определяет все типы слотов улучшений, доступные для кораблей. Каждый тип элемента улучшения, используемый вашим кораблём, должен иметь соответствующую запись здесь. ID, определённые в этом файле, используются другими XML-файлами ниже. +> * ship\_upgrade\_pieces.xml: определяет отдельные элементы улучшений — их характеристики, визуальные эффекты, описания и к какому ID слота они принадлежат. +> * mission\_ships.xml: регистрирует ваш корабль как используемый корабль в миссиях. Содержит ID корабля, имя префаба, массу и другие свойства уровня миссии. +> * ship\_hulls.xml: определяет статистику миссии корабля (здоровье, скорость, манёвренность и т.д.) и указывает, какие слоты улучшений доступны для этого типа корпуса. #### **2.2.1. hull\_group** -This nested prefab controls the visual appearance of the ship's hull at different upgrade levels. +Этот вложенный префаб управляет визуальным внешним видом корпуса корабля на разных уровнях улучшения. -> * **Placement:** Add the hull\_group nested prefab to the ship's root entity at Identity (0,0,0). -> * **Structure:** The prefab contains 5 child entities, each corresponding to a different hull material or upgrade level. -> * **Setup:** Add your prepared hull mesh as a MetaMesh to the child entity that corresponds to the correct material name. -> * **Tags:** The necessary tags for the upgrade system to recognize hull states are predefined on the prefab's children. If you are creating a new hull type, you can duplicate existing hull upgrade tags from the XMLs or remove ones that are not relevant to your ship. +> * **Размещение:** добавьте вложенный префаб hull\_group к корневой сущности корабля в Identity (0,0,0). +> * **Структура:** префаб содержит 5 дочерних сущностей, каждая из которых соответствует разному материалу корпуса или уровню улучшения. +> * **Настройка:** добавьте подготовленный меш корпуса как MetaMesh к дочерней сущности, соответствующей правильному имени материала. +> * **Теги:** необходимые теги для распознавания системой улучшений состояний корпуса предопределены на дочерних элементах префаба. Если вы создаёте новый тип корпуса, вы можете скопировать существующие теги улучшения корпуса из XML-файлов или удалить те, что не актуальны для вашего корабля. #### **2.2.2. shields\_group** -This nested prefab adds shield decorations along the ship's railings, which also serve to protect troops on deck from incoming ranged attacks. +Этот вложенный префаб добавляет декоративные щиты вдоль поручней корабля, которые также служат для защиты отрядов на палубе от входящих дальнобойных атак. -> * **Placement:** Add the shields\_holder nested prefab at the ship's root Identity (0,0,0). -> * **Customization:** The number of shields displayed can be increased or decreased by editing the relevant ship XML, or by changing the MetaMeshes on the child entities. -> * **Faction Colors (Crucial):** Every shield child entity has the banner\_with\_faction\_color tag. This tag is what causes the game to apply the owning faction's sigil and colors to the shields at runtime. - * **Important:** You must also assign the banner\_with\_faction\_color tag to the MetaMesh asset itself and to all of its LOD variants in the Resource Browser. If the tag is on the entity but not the mesh asset, the faction colors will not appear. +> * **Размещение:** добавьте вложенный префаб 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** -This prefab ensures that ship upgrade pieces are displayed correctly in the City Port UI, where players purchase and preview upgrades. +Этот префаб гарантирует, что элементы улучшений корабля корректно отображаются в интерфейсе City Port, где игроки покупают и просматривают улучшения. -> * **Placement:** Add the cam\_holder\_nested prefab at the ship's Identity. Best practice is to add this after all upgrade pieces have been placed, so the camera can be positioned to see the complete ship. -> * **Setup:** The holder contains one child entity for every upgrade piece type, associated via tags that the UI system reads. Move each child entity to position it over its corresponding upgrade piece on the ship. -> * **Camera Instance:** Move the Camera\_Instance child to a position that gives a wide, clear view of the entire ship from a flattering angle. - * *Tip:* Set your editor viewport to the desired camera angle, then right-click Camera\_Instance and select **Assign Frame From Camera**. Fine adjustments (field of view, near/far clip) can be made via the script on the camera instance child. +> * **Размещение:** добавьте префаб cam\_holder\_nested в Identity корабля. Лучшая практика — добавлять его после того, как все элементы улучшений размещены, чтобы камеру можно было расположить так, чтобы видеть весь корабль. +> * **Настройка:** держатель содержит одну дочернюю сущность для каждого типа элемента улучшения, связанную с помощью тегов, которые считывает система интерфейса. Переместите каждую дочернюю сущность, чтобы расположить её над соответствующим элементом улучшения на корабле. +> * **Экземпляр камеры:** переместите дочерний элемент Camera\_Instance в позицию, которая даёт широкий, чёткий обзор всего корабля с выгодного ракурса. + * *Совет:* установите вьюпорт редактора на желаемый угол камеры, затем щёлкните правой кнопкой мыши по Camera\_Instance и выберите **Assign Frame From Camera**. Точные настройки (поле зрения, ближняя/дальняя отсечка) можно выполнить через скрипт на дочернем элементе экземпляра камеры. #### **2.2.4. roof\_group** -This prefab adds a roof structure over the aftercastle — the raised rear portion of the ship — and any forward castle if the ship design requires it. +Этот префаб добавляет структуру крыши над ахтеркастлем (aftercastle) — приподнятой задней частью корабля — и над любым полубаком (forward castle), если это требуется дизайном корабля. -> * **Placement:** Add the roof\_group prefab at the ship's root Identity (0,0,0). -> * **Structure:** The prefab contains 15 different roof variants and platform options. Add the platform mesh appropriate for your ship as a MetaMesh to the platform child entity, then position the roof variants to fit your geometry. +> * **Размещение:** добавьте префаб roof\_group к корневому Identity (0,0,0) корабля. +> * **Структура:** префаб содержит 15 различных вариантов крыши и опций платформы. Добавьте подходящий для вашего корабля меш платформы как MetaMesh к дочерней сущности платформы, затем расположите варианты крыши в соответствии с вашей геометрией. -**Coloring & Tags:** +**Окрашивание и теги:** -> * Cloth elements (canvas roofing, awnings): Assign the sail\_mesh\_entity tag. This causes the cloth to be tinted to match the faction's sail color. -> * Wooden structural elements: Assign the auto\_factor\_color tag to the relevant wood material in the Resource Browser. This causes the wood to match the hull color defined in ShipColorAssigner on the root entity. -> * Other cloth elements: Assign the faction\_color tag in the Resource Browser (apply to all LODs). This applies a general faction color tint. +> * Тканевые элементы (навесы, тентовые крыши): назначьте тег sail\_mesh\_entity. Это приводит к тому, что ткань окрашивается в соответствии с цветом паруса фракции. +> * Деревянные структурные элементы: назначьте тег auto\_factor\_color соответствующему деревянному материалу в браузере ресурсов (Resource Browser). Это приводит к тому, что дерево соответствует цвету корпуса, определённому в ShipColorAssigner на корневой сущности. +> * Другие тканевые элементы: назначьте тег faction\_color в браузере ресурсов (применить ко всем LOD). Это применяет общий оттенок цвета фракции. #### **2.2.5. figurehead\_group** -The figurehead is the decorative carved element at the bow of the ship. In gameplay terms it also provides stat bonuses (increased ram damage, morale bonuses, etc.), making it both a cosmetic and an upgrade piece. +Носовая фигура (figurehead) — это декоративный резной элемент на носу корабля. С точки зрения геймплея она также даёт бонусы к характеристикам (увеличенный урон от тарана, бонусы к морали и т.д.), что делает её как косметическим элементом, так и элементом улучшения. -> * **Placement:** Add the figurehead\_group prefab at the ship's Identity coordinates. -> * **Structure:** The prefab contains 17 default figurehead variants, plus a base and a platform child for the ship's default (no upgrade) state. Assign the appropriate mesh as a MetaMesh to the base and platform children if you want a default figurehead visible before any upgrades are applied. -> * **Adding New Types:** New figurehead variants must be added as children to the main prefab, and their stats and descriptions must be registered in ship\_upgrade\_pieces.xml and ship\_slots.xml. -> * **Visibility:** Unlike most other upgrade pieces, figureheads are discovered through exploration in the game world rather than purchased at port. However, they still appear in the editor's upgrade preview when using EditorShipUpgradeViewer. +> * **Размещение:** добавьте префаб figurehead\_group в координаты Identity корабля. +> * **Структура:** префаб содержит 17 стандартных вариантов носовых фигур, а также дочерние элементы base и platform для состояния корабля по умолчанию (без улучшения). Назначьте подходящий меш как MetaMesh дочерним элементам base и platform, если вы хотите, чтобы носовая фигура по умолчанию была видна до применения любых улучшений. +> * **Добавление новых типов:** новые варианты носовых фигур должны добавляться как дочерние элементы основного префаба, а их характеристики и описания должны регистрироваться в ship\_upgrade\_pieces.xml и ship\_slots.xml. +> * **Видимость:** в отличие от большинства других элементов улучшений, носовые фигуры обнаруживаются посредством исследования игрового мира, а не покупаются в порту. Тем не менее, они по-прежнему отображаются в предпросмотре улучшений редактора при использовании EditorShipUpgradeViewer. #### **2.2.6. battlements\_holder\_aft** -Defensive battle shields mounted on the aftercastle to protect troops on the rear of the ship. Typically used on heavier warships. +Оборонительные боевые щиты, установленные на ахтеркастле для защиты отрядов в задней части корабля. Обычно используются на более тяжёлых военных кораблях. -> * **Setup:** Create an empty entity named battlements\_holder\_aft at Identity under the ship root. -> * Add the battlement\_shield\_group\_aft nested prefab as a child. -> * **Configuration:** Multiple instances can be added. Each instance of the battlement prefab contains different visual states for different upgrade levels and destruction states. Destruction particles can be added as additional children within each instance, following the same structure used in the main ship burning system. +> * **Настройка:** создайте пустую сущность с именем battlements\_holder\_aft в Identity под корнем корабля. +> * Добавьте вложенный префаб battlement\_shield\_group\_aft как дочерний элемент. +> * **Настройка:** можно добавить несколько экземпляров. Каждый экземпляр префаба battlement содержит разные визуальные состояния для разных уровней улучшения и состояний разрушения. Частицы разрушения можно добавить как дополнительные дочерние элементы внутри каждого экземпляра, следуя той же структуре, что используется в основной системе горения корабля. #### **2.2.7. deck\_upgrade\_holder** -This entity contains the deck\_upgrade\_assets\_nested prefab, which handles interactive and passive assets that appear on the deck at higher upgrade levels. +Эта сущность содержит вложенный префаб deck\_upgrade\_assets\_nested, который обрабатывает интерактивные и пассивные ассеты, появляющиеся на палубе на более высоких уровнях улучшения. -> * **Placement:** Add the deck\_upgrade\_assets\_nested prefab as a child under this holder. Multiple instances can be placed at different locations on the deck. -> * **NavMesh Constraint:** Because these assets have physics bodies, there must not be a NavMesh baked beneath them. Baking NavMesh under physics objects causes AI path-finding errors. +> * **Размещение:** добавьте вложенный префаб deck\_upgrade\_assets\_nested как дочерний элемент под этим держателем. Можно разместить несколько экземпляров в разных местах на палубе. +> * **Ограничение NavMesh:** поскольку эти ассеты имеют физические тела, под ними не должен быть запечён NavMesh. Запекание NavMesh под физическими объектами вызывает ошибки поиска пути ИИ. -**Component Breakdown:** +**Разбор компонентов:** -> * **Interactable Assets:** The children named deck\_ammo\_1, deck\_ammo\_2, deck\_ammo\_3, deck\_javelin\_2, and deck\_javelin\_3 are interactive objects. Players and AI agents can interact with these to replenish arrows and throwable weapons during combat. -> * **Passive Assets:** All other children within the prefab are purely visual upgrade decorations with no interaction. +> * **Интерактивные ассеты:** дочерние элементы с именами deck\_ammo\_1, deck\_ammo\_2, deck\_ammo\_3, deck\_javelin\_2 и deck\_javelin\_3 являются интерактивными объектами. Игроки и агенты ИИ могут взаимодействовать с ними, чтобы пополнить запасы стрел и метательного оружия во время боя. +> * **Пассивные ассеты:** все остальные дочерние элементы внутри префаба являются чисто визуальными декорациями улучшения без взаимодействия. #### **2.2.8. ship\_ballista\_holder** -A nested prefab that contains the complete ballista upgrade — the weapon itself, all ammo type variants, interaction points for agents, and the deck platform it sits on. +Вложенный префаб, содержащий полный комплект улучшения баллисты — само оружие, все варианты типов боеприпасов, точки взаимодействия для агентов и палубную платформу, на которой она установлена. -> * **Placement:** Add this prefab directly under the root entity. -> * **Tags:** Assign both the upgrade\_slot tag and the fore tag to the main holder entity. The upgrade\_slot tag registers it with the upgrade system; the fore tag identifies it as a forward-facing weapon and makes it mutually exclusive with battlements\_holder\_fore (a ship cannot have both a ballista and fore battlements at the same time). +> * **Размещение:** добавьте этот префаб непосредственно под корневой сущностью. +> * **Теги:** назначьте основной сущности держателя как тег upgrade\_slot, так и тег fore. Тег upgrade\_slot регистрирует её в системе улучшений; тег fore идентифицирует её как оружие, направленное вперёд, и делает её взаимоисключающей с battlements\_holder\_fore (корабль не может одновременно иметь баллисту и передние боевые щиты). -**Child Breakdown:** +**Разбор дочерних элементов:** -> * **ballista\_platform:** A raised deck platform that gives the ballista operator a better field of fire. This platform is only active when the ballista upgrade is equipped. - * **Tag:** Assign the platform tag to this child. - * **NavMesh Constraint:** This platform must not be higher than 1.5 metres above the baked deck NavMesh. The game does not generate a separate elevated NavMesh for this platform, so agents must be able to step onto it from the existing deck NavMesh. If it is too high, agents cannot reach the ballista. -> * **Ammo Type Children:** Each remaining child represents a different ammo type (standard bolts, fire bolts, etc.). All ammo children must be placed at the exact same coordinates — the game swaps between them by toggling visibility based on which ammo type is loaded. Each child must have a unique tag identifying its ammo type. +> * **ballista\_platform:** приподнятая палубная платформа, дающая оператору баллисты лучший обзор для стрельбы. Эта платформа активна только тогда, когда установлено улучшение баллисты. + * **Тег:** назначьте этой дочерней сущности тег platform. + * **Ограничение NavMesh:** эта платформа не должна быть выше 1,5 метра над запечённым NavMesh палубы. Игра не генерирует отдельный приподнятый NavMesh для этой платформы, поэтому агенты должны иметь возможность заступить на неё с существующего NavMesh палубы. Если она слишком высокая, агенты не смогут добраться до баллисты. +> * **Дочерние элементы типа боеприпасов:** каждый из оставшихся дочерних элементов представляет разный тип боеприпасов (стандартные болты, огненные болты и т.д.). Все дочерние элементы боеприпасов должны быть размещены в совершенно одинаковых координатах — игра переключается между ними, переключая видимость в зависимости от того, какой тип боеприпасов загружен. Каждый дочерний элемент должен иметь уникальный тег, идентифицирующий его тип боеприпасов. #### **2.2.9. battlements\_holder\_fore** -Defensive shields on the forecastle — the raised front section of the ship. +Оборонительные щиты на полубаке (forecastle) — приподнятой передней части корабля. -> * **Setup:** Create an empty entity named battlements\_holder\_fore at Identity. -> * Add the battlement\_shield\_group\_fore nested prefab as a child. -> * **Mutual Exclusivity:** This component is mutually exclusive with ship\_ballista\_holder. A ship cannot have both fore battlements and a ballista. Ensure the tags on this holder use the fore designation so the upgrade system enforces this exclusivity correctly. +> * **Настройка:** создайте пустую сущность с именем battlements\_holder\_fore в Identity. +> * Добавьте вложенный префаб battlement\_shield\_group\_fore как дочерний элемент. +> * **Взаимное исключение:** этот компонент взаимоисключающий с ship\_ballista\_holder. Корабль не может одновременно иметь передние боевые щиты и баллисту. Убедитесь, что теги на этом держателе используют обозначение fore, чтобы система улучшений корректно обеспечивала это исключение. #### **2.2.10. ram\_group** -The ram is the reinforced prow extension used for ramming enemy ships, dealing hull damage on collision. +Таран — это усиленное удлинение носа, используемое для тарана вражеских кораблей, нанося урон корпусу при столкновении. -> * **Placement:** Add the ram\_group nested prefab at the ship's Identity. -> * **Structure:** The prefab contains 8 predefined ram variants and 1 adapter mesh. Place and orient the 8 ram variants to fit your ship's bow shape, then add the appropriate deck extension or prow platform mesh as a MetaMesh to the adapter entity. -> * **Tags:** All required tags for the upgrade and damage systems are predefined on the ram prefab's children. New ram variants can be added to the prefab and registered in the relevant XML files following the existing patterns. +> * **Размещение:** добавьте вложенный префаб ram\_group в Identity корабля. +> * **Структура:** префаб содержит 8 предопределённых вариантов тарана и 1 меш-адаптер. Разместите и сориентируйте 8 вариантов тарана в соответствии с формой носа вашего корабля, затем добавьте подходящий меш расширения палубы или платформы носа как MetaMesh к сущности адаптера. +> * **Теги:** все необходимые теги для систем улучшения и урона предопределены на дочерних элементах префаба тарана. Новые варианты тарана можно добавить к префабу и зарегистрировать в соответствующих XML-файлах, следуя существующим шаблонам. -### **2.3. Cosmetic & VFX Components** +### **2.3. Косметические компоненты и компоненты VFX** -This group contains purely visual elements. Their absence does not break the ship's functionality or gameplay, but they are essential for the ship to look and feel correct in-game. +Эта группа содержит чисто визуальные элементы. Их отсутствие не нарушает функциональность или геймплей корабля, но они необходимы для того, чтобы корабль выглядел и воспринимался правильно в игре. #### **2.3.1. wetness\_decals** -*These decals simulate water splash marks on the outer hull, showing wet patches where waves hit the ship's sides.* +*Эти декали симулируют следы брызг воды на внешнем корпусе, показывая мокрые пятна там, где волны бьют по бортам корабля.* -> * *Setup: Create an empty entity as a direct child of the ship root (not inside mesh\_holder or ship\_water\_effects). Name it wetness\_decals and assign the tag wetness\_decals to it.* -> * *Add child entities under it. Each child must have a Decal component with the desired wetness material assigned.* -> * *Position and orient each decal against the hull surface. The decal's local up axis is used as its surface normal — ensure it points outward away from the hull surface, otherwise the system cannot correctly determine whether a splash particle is near enough to activate the decal.* -> * *Behavior: Decals fade in when active splash particles are nearby on the same side of the hull, then gradually fade out over approximately 6 seconds of inactivity.* +> * *Настройка: создайте пустую сущность как прямой дочерний элемент корня корабля (не внутри mesh\_holder или ship\_water\_effects). Назовите её wetness\_decals и назначьте ей тег wetness\_decals.* +> * *Добавьте дочерние сущности под ней. Каждый дочерний элемент должен иметь компонент Decal с назначенным нужным материалом влажности.* +> * *Расположите и сориентируйте каждую декаль относительно поверхности корпуса. Локальная ось "вверх" декали используется как её нормаль поверхности — убедитесь, что она направлена наружу, в сторону от поверхности корпуса, иначе система не сможет корректно определить, находится ли частица брызг достаточно близко, чтобы активировать декаль.* +> * *Поведение: декали проявляются, когда активные частицы брызг находятся рядом с той же стороны корпуса, а затем постепенно исчезают примерно через 6 секунд бездействия.* #### **2.3.2. rudder\_objects** -Used when you want a visible physical rudder on the ship that rotates in response to the ship's steering, even when the steering is not controlled by a ShipControlRudder (i.e., the rudder is visual only, not interactive). +Используется, когда вы хотите иметь видимый физический руль на корабле, который вращается в ответ на управление кораблём, даже если управление не контролируется ShipControlRudder (т.е. руль чисто визуальный, неинтерактивный). -> * **Setup:** Add the appropriate rudder mesh as a MetaMesh to a child entity of this holder. -> * **Tag:** Assign the tag rudder\_rotation\_entity to the entity containing the mesh. The game reads this tag to find the visual rudder and synchronize its rotation angle with the ship's current steering input. +> * **Настройка:** добавьте подходящий меш руля как MetaMesh дочерней сущности этого держателя. +> * **Тег:** назначьте тег rudder\_rotation\_entity сущности, содержащей меш. Игра считывает этот тег, чтобы найти визуальный руль и синхронизировать угол его вращения с текущим вводом управления кораблём. #### **2.3.3. ship\_water\_effects** -ShipWaterEffects (ship\_water\_effects) is a script component that adds all water-related visual effects to the ship. It is purely visual and has no effect on physics or gameplay logic. +ShipWaterEffects (ship\_water\_effects) — это компонент-скрипт, который добавляет все визуальные эффекты, связанные с водой, на корабль. Он чисто визуальный и не влияет на физику или игровую логику. -**Prerequisite:** The ship's buoyancy (floater volumes) must be fully set up before adding this script. ShipWaterEffects reads the floater configuration to determine the waterline position used for particle placement. +**Предварительное условие:** плавучесть корабля (объёмы поплавков) должна быть полностью настроена перед добавлением этого скрипта. ShipWaterEffects считывает конфигурацию поплавков, чтобы определить позицию ватерлинии, используемую для размещения частиц. -The script is attached to a **child entity** of the ship root — not the root itself. Create a child entity named ship\_visual\_only and add the ship\_water\_effects script to it. The ship\_visual\_only tag scopes this script to visual-only entities, keeping it separate from physics and gameplay logic. +Скрипт прикрепляется к **дочерней сущности** корня корабля — не к самому корню. Создайте дочернюю сущность с именем ship\_visual\_only и добавьте к ней скрипт ship\_water\_effects. Тег ship\_visual\_only ограничивает этот скрипт чисто визуальными сущностями, отделяя его от физики и игровой логики. \[ship\_root\] - └─ \[ship\_visual\_only\] ← ShipWaterEffects script lives here + └─ \[ship\_visual\_only\] ← здесь находится скрипт ShipWaterEffects -**Overview of Features:** +**Обзор функций:** -| Feature | Description | +| Функция | Описание | | :---- | :---- | -| **Wake** | A trail on the water surface behind the moving ship. Shape and size are derived automatically from the hull mesh. | -| **Movement Particles** | Continuous water spray along both sides of the hull while the ship is underway. | -| **Splash Particles** | Velocity-triggered burst particles at the waterline. Thresholds: small at ≥2 m/s, medium at ≥5 m/s, large at ≥8 m/s. | -| **In-Hull Water Simulation** | A simulated water surface rendered inside the hull interior. Reacts to wave entry events and rain automatically. | -| **Foam Trail Decals** | Foam patches spawned at the bow as the ship moves, which drift and fade over time. Requires a decal renderer in the scene. | -| **Wetness Decals** | Hull decals that become visibly wet near active splash particles and dry out over time. See section 2.3.1 for setup. | -| **Rain Interaction** | The in-hull water surface reacts to scene rain density automatically. | +| **Wake (кильватерный след)** | след на поверхности воды за движущимся кораблём. Форма и размер автоматически выводятся из меша корпуса. | +| **Movement Particles (частицы движения)** | непрерывные брызги воды вдоль обеих сторон корпуса во время хода корабля. | +| **Splash Particles (частицы брызг)** | частицы-всплески, запускаемые скоростью, на ватерлинии. Пороги: малые при ≥2 м/с, средние при ≥5 м/с, большие при ≥8 м/с. | +| **In-Hull Water Simulation (симуляция воды внутри корпуса)** | симулированная поверхность воды, отображаемая внутри корпуса. Автоматически реагирует на события попадания волн и дождь. | +| **Foam Trail Decals (декали пенного следа)** | пятна пены, появляющиеся у носа при движении корабля, которые дрейфуют и исчезают со временем. Требует рендерер декалей в сцене. | +| **Wetness Decals (декали влажности)** | декали корпуса, становящиеся заметно мокрыми рядом с активными частицами брызг и высыхающие со временем. См. раздел 2.3.1 для настройки. | +| **Rain Interaction (взаимодействие с дождём)** | поверхность воды внутри корпуса автоматически реагирует на плотность дождя в сцене. | -**Note:** You do not need to manually place any particle entities. All particle positions are computed automatically at startup using raycasts against the body\_mesh entity. Ensure body\_mesh exists and has a valid MetaMesh with an accurate bounding box. If the ship has a ram, the bow particle strip extends automatically to cover the ram tip — no extra setup is needed. +**Примечание:** вам не нужно вручную размещать какие-либо сущности частиц. Все позиции частиц вычисляются автоматически при запуске с помощью рейкастов относительно сущности body\_mesh. Убедитесь, что body\_mesh существует и имеет действительный MetaMesh с точным ограничивающим прямоугольником. Если у корабля есть таран, полоса частиц носа автоматически расширяется, чтобы покрыть кончик тарана — дополнительная настройка не требуется. -**Configurable Parameters:** +**Настраиваемые параметры:** -*In-Hull Water Simulation:* +*Симуляция воды внутри корпуса:* -> * Water Simulation Bounding Box (default: 1,1,1) — XYZ extents of the bounding volume. Use **Reset Water Simulation Bounding Box** to auto-compute from render\_to\_depth meshes. -> * Hull Water Simulation Resolution Scale (default: half) — Options: one, half, quarter, one\_eight, one\_sixteenth. Lower values improve performance. -> * Hull Water Splash Water Multiplier (default: 1.75) — Scales wave displacement intensity inside the hull on splash events. -> * Ship Hull Height Type (default: Small) — Use Large for tall-sided vessels. Options: Small, Medium, Large. +> * 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 Particles:* +*Частицы движения:* -> * Movement Particle Type (default: Small) — Use Small for small boats, Medium or Large for bigger ships. -> * Movement Particle Height Offset (default: 0.34) — Vertical offset in metres from the computed waterline. -> * Movement Particle Surface Distance Offset (default: 0.7) — Distance from the hull surface for particle origins. +> * Movement Particle Type (по умолчанию: Small) — используйте Small для маленьких лодок, Medium или Large для более крупных кораблей. +> * Movement Particle Height Offset (по умолчанию: 0.34) — вертикальное смещение в метрах от вычисленной ватерлинии. +> * Movement Particle Surface Distance Offset (по умолчанию: 0.7) — расстояние от поверхности корпуса для источников частиц. -*Splash Particles:* +*Частицы брызг:* -> * Splash Particle Height Offset (default: 0.4) — Vertical offset from waterline for splash particle placement. -> * Splash Particle Surface Distance Offset (default: 0.7) — Distance from hull surface for splash particle origins. +> * Splash Particle Height Offset (по умолчанию: 0.4) — вертикальное смещение от ватерлинии для размещения частиц брызг. +> * Splash Particle Surface Distance Offset (по умолчанию: 0.7) — расстояние от поверхности корпуса для источников частиц брызг. -**Editor Debug Tools** *(editor only, no effect in shipped builds):* +**Инструменты отладки редактора** *(только в редакторе, не влияют на финальные сборки игры)*: -> * **Reset Water Simulation Bounding Box** — Auto-computes bounding box from render\_to\_depth meshes. -> * **Re-render Depth Texture** — Forces the depth texture to re-render after modifying render\_to\_depth meshes. -> * **Reset In-Hull Water** — Resets the hull water simulation to its initial state. -> * **Show Water Simulation Bounding Box** — Draws the bounding box in the viewport. -> * **Show Movement Particles / Show Splash Particles** — Draws debug markers at each particle origin. -> * **Show Water Balance Plane** — Visualizes the computed waterline as a red plane. -> * **Show Wetness Decal Values / Force Wetness Decal To Full** — Tools for inspecting wetness decal placement and opacity. +> * **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** — инструменты для проверки размещения и непрозрачности декалей влажности. -**Campaign Map Behavior:** On the campaign map (Main\_map scene), this script automatically disables all particle and simulation logic. No visual overhead is incurred on the campaign map — the entity structure simply needs to be present. +**Поведение на карте кампании:** на карте кампании (сцена Main\_map) этот скрипт автоматически отключает всю логику частиц и симуляции. На карте кампании не возникает визуальных накладных расходов — структура сущностей просто должна присутствовать. #### **2.3.4. ship\_burning\_system** -This entity contains all visual and audio content related to the ship's burning mechanics — fire particles, light sources, and sound nodes. The system is designed to spread fire progressively across the ship in a controlled sequence. +Эта сущность содержит весь визуальный и звуковой контент, связанный с механикой горения корабля — частицы огня, источники света и звуковые узлы. Система разработана так, чтобы огонь постепенно распространялся по кораблю в контролируемой последовательности. -**a) Particle Placement Hierarchy:** +**a) Иерархия размещения частиц:** -The ship\_burning\_node prefabs are sorted into specific parent entities to define where fire can appear. These parents must exist inside the ship\_burning\_system entity: +Префабы ship\_burning\_node отсортированы по определённым родительским сущностям, определяющим, где может появиться огонь. Эти родители должны существовать внутри сущности ship\_burning\_system: -> * railing\_parent: Place burning nodes along the railings. -> * ship\_deck\_parent: Place burning nodes at random positions across the open deck. -> * deck\_upgrade\_parent: Place burning nodes on and around deck upgrade assets. -> * mast\_parent: Place burning nodes on the deck in the area beneath each mast. +> * railing\_parent: размещайте узлы горения вдоль поручней. +> * ship\_deck\_parent: размещайте узлы горения в случайных позициях по открытой палубе. +> * deck\_upgrade\_parent: размещайте узлы горения на и вокруг ассетов улучшений палубы. +> * mast\_parent: размещайте узлы горения на палубе в области под каждой мачтой. -**b) BurningNode Configuration:** +**b) Настройка BurningNode:** -Each ship\_burning\_node prefab contains the BurningNode script and a particle system child. +Каждый префаб ship\_burning\_node содержит скрипт BurningNode и дочерний элемент системы частиц. -> * **Node Index (Critical):** The Node Index value in the BurningNode script controls the order in which fire spreads. Assign sequential, unique integers (0, 1, 2, 3...) to adjacent nodes along a logical spread path — for example, numbering railing nodes from stern to bow causes fire to visibly travel along the railing in sequence. -> * **Audio Restriction (Important):** Remove all sound file paths from the particle systems used inside burning nodes. The burning system has its own dedicated sound management through sound\_parent. Leaving sounds on individual particles causes multiple overlapping audio sources and a loud, incorrect soundscape. +> * **Node Index (критично):** значение Node Index в скрипте BurningNode управляет порядком, в котором распространяется огонь. Назначьте последовательные уникальные целые числа (0, 1, 2, 3...) соседним узлам вдоль логического пути распространения — например, нумерация узлов поручней от кормы к носу заставит огонь визуально перемещаться вдоль поручней по порядку. +> * **Ограничение звука (важно):** удалите все пути звуковых файлов из систем частиц, используемых внутри узлов горения. Система горения имеет собственное выделенное управление звуком через sound\_parent. Оставление звуков на отдельных частицах вызывает множественные перекрывающиеся источники звука и громкий, некорректный звуковой ландшафт. -**c) Lighting & Sound:** +**c) Освещение и звук:** -> * light\_parent: Contains point light entities. Position these near clusters of burning nodes to create convincing firelight illumination. Lights fade in and out automatically based on fire progress values in the ShipBurningSystem script. -> * sound\_parent: Contains burning\_sound\_node prefabs. Place 2 to 6 of these around the ship depending on its size. These nodes trigger fire sounds only when fire particles in their immediate vicinity are active. +> * light\_parent: содержит сущности точечного света. Разместите их рядом с скоплениями узлов горения, чтобы создать убедительное освещение от огня. Свет автоматически проявляется и затухает в зависимости от значений прогресса огня в скрипте ShipBurningSystem. +> * sound\_parent: содержит префабы burning\_sound\_node. Разместите от 2 до 6 таких узлов вокруг корабля в зависимости от его размера. Эти узлы запускают звуки огня только тогда, когда активны частицы огня в их непосредственной близости. -**d) ShipBurningSystem Script (Root Settings):** +**d) Скрипт ShipBurningSystem (корневые настройки):** -> * **Start Fire / Stop Fire:** Editor buttons to preview the full burning sequence without launching the game. -> * **Spread Rate:** Controls how quickly fire spreads across the ship. Higher values cause faster, more aggressive burning. -> * **All Fire Mode:** Activates all fire particles simultaneously, useful for visually checking node placement. -> * **Small Hit Debug:** With this enabled, aim at the ship and press middle-click to simulate a small localized fire hit. -> * **Min/Max Fire Progress For Light:** Controls the timeline for light activation. - * *Min:* The fire progress value (0–1) at which the point lights begin to fade in. - * *Max:* The fire progress value at which lights reach their peak intensity. -> * **Max Light Intensity:** The maximum brightness value the lights under light\_parent will reach at peak fire intensity. +> * **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** -This holder contains decorative ropes that are tied between points on the ship — rigging lines, mooring ropes, and other atmospheric rope details. +Этот держатель содержит декоративные верёвки, которые завязаны между точками на корабле — такелажные линии, швартовочные канаты и другие атмосферные детали верёвок. -> * **Prefab:** Use simple\_rope\_nested for each rope. Place the start and end child entities of each rope at the desired anchor points on the ship. -> * **Configuration:** Adjust the following via the script on the start child entity: - * fixed size: Whether the rope has a fixed length or sags based on the distance between endpoints. - * loose amount: How much the rope sags between its endpoints (catenary curve depth). - * default length: The rope's natural unstretched length. -> * **Visual Properties:** Rope thickness, length-based texture tiling, and other visual parameters are controlled via the material's **custom mesh parameters** on the rope entity. +> * **Префаб:** используйте simple\_rope\_nested для каждой верёвки. Разместите начальную и конечную дочерние сущности каждой верёвки в желаемых точках крепления на корабле. +> * **Настройка:** отрегулируйте следующее через скрипт на начальной дочерней сущности: + * fixed size: имеет ли верёвка фиксированную длину или провисает в зависимости от расстояния между конечными точками. + * loose amount: насколько сильно верёвка провисает между своими конечными точками (глубина цепной кривой). + * default length: естественная нерастянутая длина верёвки. +> * **Визуальные свойства:** толщина верёвки, тайлинг текстуры в зависимости от длины и другие визуальные параметры управляются через **пользовательские параметры меша (custom mesh parameters)** материала на сущности верёвки. #### **2.3.6. brazier\_holder** -Braziers provide the lit coal pots from which archers can ignite fire arrows. This component works interchangeably — or mutually exclusively, depending on ship design — with some shield upgrade configurations. +Жаровни (braziers) предоставляют горящие угольные горшки, от которых лучники могут поджигать огненные стрелы. Этот компонент работает взаимозаменяемо — или взаимоисключающе, в зависимости от дизайна корабля — с некоторыми конфигурациями улучшений щитов. -> * **Placement:** Place brazier\_b or brazier\_d prefabs as children under this holder at suitable positions along the ship's edges or deck. Tags are predefined on the prefab — no additional tag setup is required. -> * Multiple braziers can be placed, and their positions should be accessible to standing agents without requiring them to move far from their combat positions. +> * **Размещение:** разместите префабы brazier\_b или brazier\_d как дочерние элементы под этим держателем в подходящих позициях вдоль краёв или палубы корабля. Теги предопределены на префабе — дополнительная настройка тегов не требуется. +> * Можно разместить несколько жаровен, и их позиции должны быть доступны стоящим агентам без необходимости отходить далеко от своих боевых позиций. -#### **2.3.7. ship\_water\_clip (SDF System)** +#### **2.3.7. ship\_water\_clip (система SDF)** -The SDF (Signed Distance Field) system prevents ocean water from visually appearing inside the ship's hull — without it, the sea surface would clip through the hull geometry, which looks incorrect. +Система SDF (Signed Distance Field, поле знаковых расстояний) предотвращает визуальное появление океанской воды внутри корпуса корабля — без неё поверхность моря проходила бы сквозь геометрию корпуса, что выглядело бы некорректно. -> * **Model Preparation:** Create a custom 3D mesh that closely follows the outer shape of the ship's hull below the deck line, extending slightly above deck level to create a sealed volume. This mesh defines the "dry" interior zone. -> * **Naming Convention:** The mesh name must begin with the prefix sdf\_ (e.g., sdf\_dromon). The engine automatically processes any mesh with this prefix as SDF data when it is imported. +> * **Подготовка модели:** создайте пользовательский 3D-меш, который точно следует внешней форме корпуса корабля ниже линии палубы, слегка выступая над уровнем палубы, чтобы создать герметичный объём. Этот меш определяет "сухую" внутреннюю зону. +> * **Соглашение об именовании:** имя меша должно начинаться с префикса sdf\_ (например, sdf\_dromon). Движок автоматически обрабатывает любой меш с этим префиксом как данные SDF при импорте. -**Setup:** +**Настройка:** -> 1. Add the ship\_water\_clip prefab to the ship hierarchy. -> 2. Find the signed\_distance\_field script inside this prefab. -> 3. Assign your prepared SDF mesh asset to the script. +> 1. Добавьте префаб ship\_water\_clip в иерархию корабля. +> 2. Найдите скрипт signed\_distance\_field внутри этого префаба. +> 3. Назначьте подготовленный ассет меша SDF этому скрипту. -**Verification:** Enable the **Visualize SDF** checkbox in the script to see the field rendered in the editor viewport as a colored volume. Verify that the volume completely encloses the hull interior below deck. +**Проверка:** включите флажок **Visualize SDF** в скрипте, чтобы увидеть поле, отображённое во вьюпорте редактора как цветной объём. Проверьте, что объём полностью охватывает внутреннюю часть корпуса ниже палубы. -#### **2.3.8. deckwater (Heightmap Simulation)** +#### **2.3.8. deckwater (симуляция на основе карты высот)** -This system simulates water pooling and sloshing on the ship's deck — the visible water that accumulates from waves washing over the sides. +Эта система симулирует скопление и плескание воды на палубе корабля — видимую воду, накапливающуюся от волн, перехлёстывающих через борта. -> * **Asset:** A simplified "fake deck" mesh is required. This mesh is used to generate the top-down depth texture (heightmap) that the simulation reads. -> * **Setup:** - 1. Add this fake deck mesh as a child entity under mesh\_holder. - 2. Assign the render\_to\_depth tag to this entity. The water effects system will include it (along with all other render\_to\_depth tagged objects such as oar\_seats and deck furniture) in the depth render. - 3. After setup, navigate to the ship\_water\_effects child entity and click **Re-render Depth Texture** in the ShipWaterEffects script to bake the depth texture. -> * **Debug:** Increase the **Water Strength** value in the Scene Options window and enable **Enable Physics** in the Visibility window to observe the deck water simulation behavior in the editor. +> * **Ассет:** требуется упрощённый меш "фальшивой палубы". Этот меш используется для генерации текстуры глубины сверху вниз (карты высот), которую считывает симуляция. +> * **Настройка:** + 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** -This holder contains lanterns and torches that provide ambient lighting on the ship at night and in dark scenes. +Этот держатель содержит фонари и факелы, обеспечивающие окружающее освещение на корабле ночью и в тёмных сценах. -> * **Prefab:** Add nord\_lantern\_nested as a child for each light source position. -> * Each lantern prefab contains: - * collision\_sphere: A small physics sphere used for collision interactions (e.g., agents brushing past the lantern). - * swinging\_object: The part of the lantern that physically swings in response to ship movement. Assign the tag swinging\_entity to this child. This child contains both the light source entity and the lantern mesh that visually sways. - * nord\_lantern\_part\_02: The static mounting bracket or chain that does not swing. This part stays fixed relative to the ship. +> * **Префаб:** добавьте nord\_lantern\_nested как дочерний элемент для каждой позиции источника света. +> * Каждый префаб фонаря содержит: + * collision\_sphere: небольшую физическую сферу, используемую для взаимодействий коллизии (например, когда агенты задевают фонарь). + * swinging\_object: часть фонаря, которая физически качается в ответ на движение корабля. Назначьте тег swinging\_entity этому дочернему элементу. Этот дочерний элемент содержит как сущность источника света, так и визуально покачивающийся меш фонаря. + * nord\_lantern\_part\_02: статичный монтажный кронштейн или цепь, которая не качается. Эта часть остаётся фиксированной относительно корабля. #### **2.3.10. knobs\_holder** -This holder contains the deck-level anchor points where ropes from the sails tie off. They are the cleats, bollards, and belaying pin racks that sailors use to secure running rigging. +Этот держатель содержит точки крепления на уровне палубы, где завязываются верёвки от парусов. Это кнехты, утки и колышки-банкеты, которые моряки используют для закрепления бегучего такелажа. -> * **Parent Tag:** Assign the tag knob\_points\_parent to the knobs\_holder entity itself. The sail system uses this tag to locate all available rope anchor points on the ship. +> * **Тег родителя:** назначьте тег knob\_points\_parent самой сущности knobs\_holder. Система парусов использует этот тег для определения всех доступных точек крепления верёвок на корабле. -**Available prefabs:** +**Доступные префабы:** > * bollard\_a > * cleat\_a > * belaying\_pins\_a > * belaying\_pins\_b -> * **Setup:** Inside each prefab are child entities that serve as the precise rope endpoint anchors. Assign the tag knot\_point to each of these child entities. You can duplicate and place as many anchor prefabs as your rigging design requires. The sail system will automatically use the nearest knot\_point to route rope visuals from each sail's control bone. \ No newline at end of file +> * **Настройка:** внутри каждого префаба есть дочерние сущности, служащие точными точками крепления концов верёвки. Назначьте тег knot\_point каждой из этих дочерних сущностей. Вы можете дублировать и размещать столько префабов точек крепления, сколько требует ваш дизайн такелажа. Система парусов автоматически будет использовать ближайший knot\_point для прокладки визуальных верёвок от контрольной кости каждого паруса. diff --git a/docs/content/russian/War Sails/what_makes_seaborne_village_raid_scene.md b/docs/content/russian/War Sails/what_makes_seaborne_village_raid_scene.md index 36f11adf..281ced8d 100644 --- a/docs/content/russian/War Sails/what_makes_seaborne_village_raid_scene.md +++ b/docs/content/russian/War Sails/what_makes_seaborne_village_raid_scene.md @@ -1,41 +1,42 @@ +++ -title = "What Makes a Seaborne Raid Scene" +title = "Из чего состоит сцена морского набега" description = "" weight = 20 +ai_translated = true +++ -### **Navigation Mesh** +### **Навигационная сетка (Navigation Mesh)** -* Works similarly to village scenes. -* In scenes created using two separate levels, for the `land_raid` **Level** (check ["What Makes a Village Scene"](https://moddocs.bannerlord.com/authoring-mission-scenes/villages/) documentation), all **NavMesh** on land must have **ID 0** in the `naval_raid` **Level**. -* **Agents** can walk in water up to a height of 1.40 meters. Therefore, **NavMesh** with **ID 0** should be baked up to a depth of 1.40m; if the water is deeper, **Agents** will swim. +* Работает аналогично сценам деревень. +* В сценах, созданных с использованием двух отдельных уровней, для уровня (**Level**) `land_raid` (см. документацию ["What Makes a Village Scene"](https://moddocs.bannerlord.com/authoring-mission-scenes/villages/)) вся **NavMesh** на суше должна иметь **ID 0** на уровне (**Level**) `naval_raid`. +* **Агенты (Agents)** могут передвигаться по воде на глубину до 1,40 метра. Поэтому **NavMesh** с **ID 0** должна быть запечена (baked) на глубину до 1,40 м; если вода глубже, **Агенты** будут плыть. --- -### **Spawn Points** - -* All **Spawn Points** must be positioned inside the **Soft Borders**. -* All **Spawn Points** must be placed on top of the **NavMesh**. -* **Battle Spawn Points**: - * All defender **Spawn Points** must be located within the **Defender Boundaries**. - * **Prefab**: `naval_battle_set` - * Place the defender parts of the set on land and the attacker parts in the sea/river. - * Attacker **Spawn Points** should not be too close to the shore. - * Ensure all defender **Spawn Points** have empty space around them for troops to spawn properly. - * Move defender reinforcement **Spawn Points** out of sight as much as possible without being too far from the front lines. - * Since a raid can be performed with 3 ships, you can position attacker infantry, archer, and cavalry **Spawn Points** facing the direction they will travel in the water. - * The distance between attacker **Spawn Points** should be adjusted according to ship dimensions. - * If a river scene is being prepared, it must be wide enough for large ships to move freely. +### **Точки появления (Spawn Points)** + +* Все **точки появления (Spawn Points)** должны располагаться внутри **мягких границ (Soft Borders)**. +* Все **точки появления (Spawn Points)** должны быть размещены поверх **NavMesh**. +* **Боевые точки появления (Battle Spawn Points)**: + * Все точки появления защитников должны находиться в пределах **границ защитников (Defender Boundaries)**. + * **Префаб (Prefab)**: `naval_battle_set` + * Размещайте части набора для защитников на суше, а части для атакующих — в море/реке. + * Точки появления атакующих не должны находиться слишком близко к берегу. + * Убедитесь, что вокруг всех точек появления защитников есть свободное пространство для правильного появления войск. + * Перемещайте точки появления подкрепления защитников как можно дальше от поля зрения, не слишком удаляя их от передовой. + * Поскольку набег может выполняться с использованием 3 кораблей, вы можете расположить точки появления пехоты, лучников и кавалерии атакующих лицом в направлении их движения по воде. + * Расстояние между точками появления атакующих следует регулировать в зависимости от размеров кораблей. + * Если готовится речная сцена, река должна быть достаточно широкой, чтобы большие корабли могли свободно перемещаться. --- -### **Tactical Positions** +### **Тактические позиции (Tactical Positions)** -* **Prefab**: `tactical_position` -* Use the `chokepoint` **Tactical Position** type within the **Script**, adjusting its size for where you want infantry to position and defend. -* Use the `cliff` **Tactical Position** for the general placement of archers. This position determines the general location of archers, from which they distribute to `strategic_archer_point` entities and return to when retreating. -* The `cliff` **Tactical Position** **Prefab** should be used as a child of the `chokepoint` **Tactical Position** **Prefab**. -* **AI** will position themselves according to the rotation of the **Prefab** and the width defined in the **Script**. +* **Префаб (Prefab)**: `tactical_position` +* Используйте тип тактической позиции (**Tactical Position**) `chokepoint` в **скрипте (Script)**, регулируя его размер в соответствии с местом, где вы хотите, чтобы пехота занимала позицию и обороняла её. +* Используйте тактическую позицию **Tactical Position** `cliff` для общего размещения лучников. Эта позиция определяет общее расположение лучников, откуда они распределяются по сущностям `strategic_archer_point` и возвращаются при отступлении. +* Префаб (**Prefab**) тактической позиции `cliff` следует использовать как дочерний элемент префаба тактической позиции `chokepoint`. +* **ИИ (AI)** будет позиционировать себя в соответствии с поворотом префаба (**Prefab**) и шириной, заданной в **скрипте (Script)**. @@ -43,89 +44,89 @@ weight = 20 --- -### **Tactical & Strategic Archer Positions** +### **Тактические и стратегические позиции лучников** -* **Prefab**: `strategic_archer_position` -* Defines the location where a single archer will go. Many can be added to the scene; all defender archers in battle will distribute among these positions. -* To reposition archers who are placed far from the main battlefield to harass incoming ships early on, you have two tactical options to bring them back into the main fight: -* **Option A (`unsafe_archer_point`):** If you give these entities the `unsafe_archer_point` **Tag**, once the ships complete their landing, these archers will automatically fall back toward the main battlefield (`cliff` **Tactical Position**) to rejoin the active defense. -* **Option B (`volume_box_archer_point`):** If you want more precise control, you can use the `volume_box_archer_point` **Tag** (applied to both the archer positions and a corresponding `volume_box`). This ensures that the archers will hold their positions and only fall back to the `cliff` **Tactical Position** when the enemy actually penetrates your designated **Volume Box** area. +* **Префаб (Prefab)**: `strategic_archer_position` +* Определяет местоположение, куда отправится один лучник. В сцену можно добавить множество таких позиций; все лучники-защитники в бою будут распределяться по этим позициям. +* Чтобы переместить лучников, расположенных далеко от основного поля боя, которые должны досаждать приближающимся кораблям на раннем этапе, у вас есть два тактических варианта вернуть их в основной бой: +* **Вариант A (`unsafe_archer_point`):** Если вы присвоите этим сущностям **тег (Tag)** `unsafe_archer_point`, то после завершения высадки кораблей эти лучники автоматически отступят к основному полю боя (тактическая позиция **Tactical Position** `cliff`), чтобы присоединиться к активной обороне. +* **Вариант B (`volume_box_archer_point`):** Если вам нужен более точный контроль, вы можете использовать **тег (Tag)** `volume_box_archer_point` (применяемый как к позициям лучников, так и к соответствующему `volume_box`). Это гарантирует, что лучники будут удерживать свои позиции и отступят к тактической позиции `cliff` только тогда, когда враг действительно проникнет в вашу заданную область **Volume Box**. -**Volume Box Trigger Point**: +**Точка триггера Volume Box**: -* **Prefab**: `volume_box` -* **Tag**: `volume_box_archer_point` -* This setup acts as a spatial trigger for archer maneuvers. Unlike the `unsafe_archer_point` which triggers upon landing, this allows for precise control based on attacker progression. -* **Setup Rule**: The `volume_box_archer_point` Tag must be assigned to both the `volume_box` entity itself and all `strategic_archer_point` entities that you want to be triggered by this specific box. -* **Behavior**: When any attacker enters the tagged `volume_box`, all archers stationed at the matching tagged `strategic_archer_point` entities will immediately begin their retreat toward the `cliff` **Tactical Position**. +* **Префаб (Prefab)**: `volume_box` +* **Тег (Tag)**: `volume_box_archer_point` +* Эта настройка действует как пространственный триггер для манёвров лучников. В отличие от `unsafe_archer_point`, который срабатывает при высадке, этот вариант позволяет точно контролировать ситуацию на основе продвижения атакующих. +* **Правило настройки**: Тег `volume_box_archer_point` должен быть присвоен как самой сущности `volume_box`, так и всем сущностям `strategic_archer_point`, которые должны срабатывать от этого конкретного бокса. +* **Поведение**: Когда любой атакующий входит в помеченный тегом `volume_box`, все лучники, размещённые в соответствующих помеченных тегом сущностях `strategic_archer_point`, немедленно начинают отступление к тактической позиции (**Tactical Position**) `cliff`. --- -### **Player View Point (for Defender)** +### **Точка обзора игрока (для защитника)** -* Use the `arrow_new_icon` **Prefab** and assign the `player_spawn_frame` **Tag** to it. -* The player will **Spawn** facing the direction of the arrow. -* **Note**: The rotation and direction of the arrow are critical, as they directly determine the player's initial field of view upon spawning. +* Используйте префаб (**Prefab**) `arrow_new_icon` и присвойте ему **тег (Tag)** `player_spawn_frame`. +* Игрок появится (**Spawn**) лицом в направлении стрелки. +* **Примечание**: Поворот и направление стрелки имеют решающее значение, поскольку они напрямую определяют начальное поле зрения игрока при появлении. --- -### **Landing Points** +### **Точки высадки (Landing Points)** -* 3 empty entities must be placed on the shore using the correct **Tags** for 3 ships to land: - * Attacker infantry ship landing **Tag**: `landing_001_0` - * Attacker archer ship landing **Tag**: `landing_002_0` - * Attacker cavalry ship landing **Tag**: `landing_003_0` -* Ensure there is enough distance between the landing points of the ships on the shore. -* For the route you want ships to follow in the water, you can give similar **Tags** to empty entities placed in the water. - * Example: For the infantry ship, from near to far: `landing_001_1`, `landing_001_2`, `landing_001_3`. In this case, the attacker infantry **Spawn Point** inside the `naval_battle_set` will target `landing_001_3` first, then the others in sequence to reach `landing_001_0`. -* The rotation of all entities must face the next target landing entity. -* The rotation of the final destination `landing_00x_0` must be positioned to ensure the ship docks correctly at the shore. +* На берегу необходимо разместить 3 пустые сущности с правильными **тегами (Tags)** для высадки 3 кораблей: + * Тег высадки пехотного корабля атакующих: `landing_001_0` + * Тег высадки корабля лучников атакующих: `landing_002_0` + * Тег высадки кавалерийского корабля атакующих: `landing_003_0` +* Убедитесь, что между точками высадки кораблей на берегу достаточно расстояния. +* Для маршрута, по которому должны следовать корабли в воде, вы можете присвоить аналогичные **теги (Tags)** пустым сущностям, размещённым в воде. + * Пример: Для пехотного корабля, от ближней точки к дальней: `landing_001_1`, `landing_001_2`, `landing_001_3`. В этом случае точка появления (**Spawn Point**) пехоты атакующих внутри `naval_battle_set` сначала нацелится на `landing_001_3`, а затем последовательно на остальные, чтобы достичь `landing_001_0`. +* Поворот всех сущностей должен быть направлен на следующую целевую точку высадки. +* Поворот конечной точки назначения `landing_00x_0` должен быть выставлен так, чтобы корабль правильно причаливал к берегу. --- -### **Jumping Points** +### **Точки прыжка (Jumping Points)** -* Used to indicate which direction **Agents** jumping from the ship to the shore should move. -* Use empty entities with **Tags** `jumping_001`, `jumping_002`, `jumping_003` for each ship, and they must be a child of their associated final landing point. - * Example: The entity with the `jumping_001` **Tag** must always be a child of the `landing_001_0` entity. -* The rotation should be adjusted to ensure **Agents** use the most logical **Mechanics** to leave the ship. +* Используются для указания направления, в котором должны двигаться **агенты (Agents)**, прыгающие с корабля на берег. +* Используйте пустые сущности с **тегами (Tags)** `jumping_001`, `jumping_002`, `jumping_003` для каждого корабля, и они должны быть дочерними элементами соответствующей конечной точки высадки. + * Пример: Сущность с **тегом (Tag)** `jumping_001` всегда должна быть дочерней для сущности `landing_001_0`. +* Поворот следует отрегулировать так, чтобы **агенты (Agents)** использовали наиболее логичную **механику (Mechanics)** для схода с корабля. --- -### **Flee Positions** +### **Позиции бегства (Flee Positions)** -* Positions to which fleeing troops and horses will run. -* Ensure they are inside the **Soft Border** and have **NavMesh** below them. +* Позиции, к которым будут бежать отступающие войска и лошади. +* Убедитесь, что они находятся внутри **мягкой границы (Soft Border)** и под ними есть **NavMesh**. --- -### **Soft Border** +### **Мягкая граница (Soft Border)** -* **Prefab**: `border_soft` -* These entities define the red boundaries of the scene. -* When placed, they form a polygon by connecting the two closest border entities. -* To visualize the current boundaries, navigate to `Visibility Window` \-\> `Visibility Masks` and enable `Borders`. -* **Design Note**: Ensure the layout of these borders prevents players from abusing the map limits or finding unintended escape routes. +* **Префаб (Prefab)**: `border_soft` +* Эти сущности определяют красные границы сцены. +* При размещении они образуют многоугольник, соединяя две ближайшие пограничные сущности. +* Чтобы визуализировать текущие границы, перейдите в `Visibility Window` \-\> `Visibility Masks` и включите `Borders`. +* **Замечание по дизайну**: Убедитесь, что расположение этих границ не позволяет игрокам злоупотреблять пределами карты или находить непредусмотренные пути отступления. --- -### **Sounds & Atmosphere** +### **Звуки и атмосфера** -* Works similarly to village scenes. -* Ensure environmental sounds reflect the naval nature of the raid. -* **Atmosphere** must look consistent across all seasons and times of day. +* Работает аналогично сценам деревень. +* Убедитесь, что звуки окружения отражают морской характер набега. +* **Атмосфера** должна выглядеть согласованно во всех сезонах и в любое время суток. --- -### **Gameplay Design Hints** +### **Рекомендации по игровому дизайну** -* Having ships under fire before docking increases the epic battle feel. You can place archers further out to shoot at ships early on. To ensure these archers rejoin the frontline defense rather than getting left behind, you can use the `unsafe_archer_point` **Tag** to trigger their fallback to the `cliff` **Tactical Position** upon ship landing, or utilize the `volume_box_archer_point` setup to trigger their relocation exactly when the enemy reaches a specific zone in your scene. -* Using physical **Chokepoints** in the scene will increase the difficulty for the attacker. -* Make sure the scene works well at night. -* To maintain the "village raid" atmosphere, ensure the battle does not start or end too far from the village area. \ No newline at end of file +* Обстрел кораблей до их причаливания усиливает ощущение эпичности боя. Вы можете разместить лучников дальше, чтобы они стреляли по кораблям на раннем этапе. Чтобы эти лучники присоединялись к обороне передовой, а не оставались позади, вы можете использовать **тег (Tag)** `unsafe_archer_point`, чтобы запустить их отступление к тактической позиции (**Tactical Position**) `cliff` после высадки кораблей, либо использовать настройку `volume_box_archer_point`, чтобы запускать их перемещение именно тогда, когда враг достигает определённой зоны в вашей сцене. +* Использование физических **узких проходов (Chokepoints)** в сцене повысит сложность для атакующего. +* Убедитесь, что сцена хорошо работает ночью. +* Чтобы сохранить атмосферу "набега на деревню", убедитесь, что бой не начинается и не заканчивается слишком далеко от территории деревни. diff --git a/docs/content/russian/War Sails/wsworldmap.md b/docs/content/russian/War Sails/wsworldmap.md index 6b006bae..f4aeabc8 100644 --- a/docs/content/russian/War Sails/wsworldmap.md +++ b/docs/content/russian/War Sails/wsworldmap.md @@ -1,14 +1,15 @@ +++ -title = "War Sails World Map" +title = "Карта мира War Sails" description = "" weight = 10 +ai_translated = true +++ -Creating or modifying the War Sails world map involves a few additional requirements compared to Bannerlord. They are listed below. +Создание или изменение карты мира War Sails связано с несколькими дополнительными требованиями по сравнению с Bannerlord. Они перечислены ниже. -## Navmesh +## Навигационная сетка (Navmesh) -With the War Sails DLC, many bodies of water become navigable, introducing several new navmesh types beyond those used in the base game. When creating or modifying a War Sails world map, you may need to use the following navmesh types: +С DLC War Sails многие водоёмы становятся судоходными, что вводит несколько новых типов навигационной сетки помимо тех, что используются в базовой игре. При создании или изменении карты мира War Sails вам может понадобиться использовать следующие типы навигационной сетки: * `CoastalSea` * `OpenSea` @@ -17,59 +18,59 @@ With the War Sails DLC, many bodies of water become navigable, introducing sever * `UnderBridge` * `Lake` -The corresponding navmesh ID values are shown in the image below. +Соответствующие значения ID навигационной сетки показаны на изображении ниже. -`CoastalSea` and `OpenSea` are both navigable water types, but they serve different gameplay purposes. They use different movement speed modifiers and are treated differently by the sea attrition system, so choose the appropriate type based on the intended gameplay. +`CoastalSea` и `OpenSea` — оба типа судоходной воды, но они служат разным игровым целям. Они используют разные модификаторы скорости движения и по-разному обрабатываются системой морского истощения (sea attrition), поэтому выбирайте подходящий тип в зависимости от предполагаемого геймплея. -Use the `UnderBridge` navmesh type for the faces directly beneath bridges, as well as the adjacent faces leading into and out of the bridge. This navmesh type does not affect movement speed or sea attrition. Instead, it controls bridge-specific behavior: +Используйте тип навигационной сетки `UnderBridge` для граней непосредственно под мостами, а также для соседних граней, ведущих к мосту и от него. Этот тип навигационной сетки не влияет на скорость движения или морское истощение. Вместо этого он управляет поведением, специфичным для мостов: -* Ships will automatically fold and unfold their sails when passing underneath the bridge. -* When the player sails under a bridge, the bridge becomes transparent to improve visibility. +* Корабли будут автоматически складывать и раскладывать паруса при прохождении под мостом. +* Когда игрок проплывает под мостом, мост становится прозрачным для улучшения видимости. -Lakes are not navigable in War Sails. The `Lake` navmesh type functions as impassable terrain and cannot be traversed by ships. +Озёра не судоходны в War Sails. Тип навигационной сетки `Lake` функционирует как непроходимая местность и не может быть пересечён кораблями. -## Flowmap +## Карта потоков (Flowmap) -In War Sails, wind and water currents affect movement across navigable water. Strength and direction are defined by the Flowmap, which can be edited directly in the World Map Editor. +В War Sails ветер и водные течения влияют на движение по судоходной воде. Сила и направление определяются картой потоков (Flowmap), которую можно редактировать прямо в редакторе карты мира (World Map Editor). -To edit the Flowmap: +Чтобы отредактировать Flowmap: -1. Click Paint Flowmap, located between the Paint Flora and Navigation Mesh buttons. -2. Also, open the Inspector and select the Flowmap tab in order to correctly edit it. +1. Нажмите кнопку Paint Flowmap, расположенную между кнопками Paint Flora и Navigation Mesh. +2. Также откройте Inspector и выберите вкладку Flowmap, чтобы корректно её редактировать. -The Flowmap is painted much like terrain textures or the heightmap, but each brush stroke also defines a direction. The editor displays colored arrows to visualize the Flowmap: +Flowmap рисуется примерно так же, как текстуры местности или карта высот, но каждый мазок кисти также определяет направление. Редактор отображает цветные стрелки для визуализации Flowmap: -* The arrow direction indicates the wind and water current direction. -* The arrow color indicates the wind and water current strength. - * Blue represents the weakest wind and water current. - * Red represents the strongest wind and water current. +* Направление стрелки указывает направление ветра и водного течения. +* Цвет стрелки указывает силу ветра и водного течения. + * Синий цвет обозначает самый слабый ветер и течение. + * Красный цвет обозначает самый сильный ветер и течение. -The Flowmap directly influences the water shader. Because of this, painting neighboring areas with sharply opposing flow directions can cause visible stretching or unrealistic water deformation. If you need adjacent areas with opposite current directions, create a smooth transition between them instead of painting an abrupt change. This produces more natural-looking water while still allowing distinct current patterns. +Flowmap напрямую влияет на шейдер воды. Из-за этого окраска соседних областей с резко противоположными направлениями потока может вызвать заметное растяжение или нереалистичную деформацию воды. Если вам нужны соседние области с противоположными направлениями течения, создайте плавный переход между ними вместо того, чтобы рисовать резкое изменение. Это обеспечивает более естественный вид воды, сохраняя при этом возможность задавать отдельные узоры течений. -## Settlement Setup +## Настройка поселений -War Sails introduces several additional entities for coastal settlements. These entities enable features such as embarking and disembarking, naval blockades, and village landing points. +War Sails вводит несколько дополнительных сущностей для прибрежных поселений. Эти сущности обеспечивают такие функции, как посадка и высадка, морские блокады и точки высадки у деревень. -### Port Points +### Точки порта -To allow naval parties to embark and disembark at a coastal town, add a child entity named `town_port` to the settlement. +Чтобы разрешить морским партиям садиться на корабли и высаживаться в прибрежном городе, добавьте дочернюю сущность с именем `town_port` в поселение. -The entity must: +Эта сущность должна: -* Be tagged with `main_map_city_port`. -* Be placed on a navigable naval navmesh, such as `CoastalSea` or `River`. Not placing it correctly will lead to errors. +* Быть помечена тегом `main_map_city_port`. +* Быть размещена на судоходной морской навигационной сетке, такой как `CoastalSea` или `River`. Неправильное размещение приведёт к ошибкам. -**Settlement XML Configuration** +**Настройка XML поселения** -After adding a `town_port` entity to a coastal town, you must also update the `settlements.xml` file. +После добавления сущности `town_port` в прибрежный город необходимо также обновить файл `settlements.xml`. -In the settlement's Buildings section, add the Shipyard building: +В разделе зданий (Buildings) поселения добавьте здание верфи (Shipyard): ```xml ``` -And for the shipyard scene, you should add the shipyard location in the settlement's Locations section, like this: +А для сцены верфи вам следует добавить локацию верфи в разделе локаций (Locations) поселения следующим образом: ```xml ``` -### Blockade Points +### Точки блокады -When a coastal town is under siege, War Sails displays a naval blockade around the settlement. To define the blockade area and ship positions, add the following: +Когда прибрежный город осаждён, War Sails отображает морскую блокаду вокруг поселения. Чтобы определить область блокады и позиции кораблей, добавьте следующее: -* `town_blockade_start` entity with the `Blockade_Arc_Start` tag as a child entity -* `town_blockade_end` entity with the `Blockade_Arc_End` tag as a child entity -* `BlockadePositionScript` to the town entity +* Сущность `town_blockade_start` с тегом `Blockade_Arc_Start` в качестве дочерней сущности +* Сущность `town_blockade_end` с тегом `Blockade_Arc_End` в качестве дочерней сущности +* `BlockadePositionScript` к сущности города -Once these have been added, the editor will display: +После добавления этого редактор будет отображать: -* Red markers representing the individual blockade ship positions. -* A sphere indicating the center of the blockade arc. +* Красные маркеры, представляющие отдельные позиции кораблей блокады. +* Сферу, обозначающую центр дуги блокады. -Moving the start and end points changes the extent of the blockade arc, allowing you to adjust the visual placement of the blockade fleet. +Перемещение начальной и конечной точек изменяет протяжённость дуги блокады, позволяя регулировать визуальное расположение блокадного флота. -The `BlockadePositionScript` also exposes several parameters that control the appearance of the blockade, including: +`BlockadePositionScript` также предоставляет несколько параметров, которые управляют внешним видом блокады, включая: -* The number of ships. -* The number of blockade arcs. -* The spacing between ships. -* Other blockade layout settings. +* Количество кораблей. +* Количество дуг блокады. +* Расстояние между кораблями. +* Другие настройки расположения блокады. -Adjust these values to achieve the desired visual result. +Настройте эти значения, чтобы добиться желаемого визуального результата. -### Drop Off Points +### Точки высадки (Drop Off Points) -Coastal villages use drop-off points instead of ports to support embarking and disembarking. +Прибрежные деревни используют точки высадки вместо портов для поддержки посадки и высадки. -To add a drop-off point, create a child entity named `drop_point` and assign it the `main_map_village_dropoff` tag. +Чтобы добавить точку высадки, создайте дочернюю сущность с именем `drop_point` и присвойте ей тег `main_map_village_dropoff`. -As with town ports, the drop-off point must be placed on a navigable naval navmesh (such as `CoastalSea` or `River`) for it to function correctly. +Как и в случае с портами городов, точка высадки должна быть размещена на судоходной морской навигационной сетке (такой как `CoastalSea` или `River`), чтобы она функционировала корректно. -## Transition +## Переход -In addition to transitions between naval travel and coastal settlements, War Sails also supports direct transitions between navigable water and land. +Помимо переходов между морским плаванием и прибрежными поселениями, War Sails также поддерживает прямые переходы между судоходной водой и сушей. -The only requirement is that both the source and destination navmesh types must be navigable. +Единственное требование заключается в том, что как исходный, так и целевой тип навигационной сетки должны быть судоходными/проходимыми. -For example: +Например: -* A party can transition from `CoastalSea` to `Plain` or `Forest`. -* A party cannot transition to an impassable terrain type, such as `Mountain`. +* Партия может перейти из `CoastalSea` в `Plain` или `Forest`. +* Партия не может перейти на непроходимый тип местности, такой как `Mountain`. -This allows you to define embarkation and disembarkation points at any suitable navigable shoreline, not just at settlements. +Это позволяет вам определять точки посадки и высадки на любом подходящем судоходном береге, а не только в поселениях. -## Scripts +## Скрипты -One of the most important components in the world map scene is the `SettlementPositionScript`, located under the `settlement_scripts` entity. +Один из важнейших компонентов на сцене карты мира — `SettlementPositionScript`, расположенный на сущности `settlement_scripts`. -Whenever you make changes that affect navigation or settlement locations, the Settlement Distance Cache must be regenerated. This includes changes such as editing the navmesh or moving a settlement, including `town_gate`, `town_port`, or `drop_point`. +Всякий раз, когда вы вносите изменения, влияющие на навигацию или расположение поселений, необходимо регенерировать кэш расстояний между поселениями (Settlement Distance Cache). Это включает такие изменения, как редактирование навигационной сетки или перемещение поселения, включая `town_gate`, `town_port` или `drop_point`. -To safely regenerate the cache, perform the following steps in order: +Чтобы безопасно регенерировать кэш, выполните следующие шаги по порядку: -1. Before rebuilding the Settlement Distance Cache, verify that the following are selected: +1. Перед перестроением кэша расстояний между поселениями убедитесь, что выбраны следующие параметры: * `_partyNavigationModelOverridenClassName` → `NavalPartyNavigationModel` * `_distanceModelOverridenClassName` → `NavalDLCMapDistanceModel` -2. Check Positions - * Validates settlement-related positions and moves the camera to any problematic locations, making them easier to identify and fix. -3. Save Positions - * Saves the current settlement positions and all associated data. +2. Check Positions (Проверить позиции) + * Проверяет позиции, связанные с поселениями, и перемещает камеру к любым проблемным местам, облегчая их выявление и исправление. +3. Save Positions (Сохранить позиции) + * Сохраняет текущие позиции поселений и все связанные с ними данные. 4. `ComputeAndSaveSettlementDistanceCache` - * Rebuilds the Settlement Distance Cache. This final step can take a significant amount of time, depending on your hardware. During the process, the editor computes pathfinding routes between every settlement and every other settlement, then stores the results in the cache. + * Перестраивает кэш расстояний между поселениями. Этот заключительный шаг может занять значительное время в зависимости от вашего оборудования. В процессе редактор вычисляет маршруты поиска пути между каждым поселением и всеми остальными поселениями, а затем сохраняет результаты в кэше. -## Water Plane and Material +## Плоскость воды и материал -War Sails does not use the engine's automatically generated scene water. Instead, it uses custom planar meshes with water materials. +War Sails не использует автоматически генерируемую воду сцены движка. Вместо этого используются пользовательские плоские меши с материалами воды. -The built-in scene water is designed for mission scenes and has fixed scaling and behavior, making it unsuitable for the flexibility required by the campaign world map. Custom water planes allow you to precisely control the size, placement, and appearance of navigable water. +Встроенная вода сцены предназначена для миссионных сцен и имеет фиксированное масштабирование и поведение, что делает её непригодной для гибкости, необходимой для карты мира кампании. Пользовательские плоскости воды позволяют точно контролировать размер, расположение и внешний вид судоходной воды. -A standard War Sails water plane uses the following configuration: +Стандартная плоскость воды War Sails использует следующую конфигурацию: -* Material: `naval_worldmap_water` -* Scripts: +* Материал: `naval_worldmap_water` +* Скрипты: * `water_flowmap` * `CampaignMapAmbientOccluder` -* Tag: `snapped_water_body` +* Тег: `snapped_water_body` -The image below shows the required components and parameters for the main world map water plane. +На изображении ниже показаны необходимые компоненты и параметры для основной плоскости воды карты мира. -Note: The world map scene also contains additional `water_plane` entities used for lakes. Before making any changes, make sure you have selected the correct water plane. +Примечание: сцена карты мира также содержит дополнительные сущности `water_plane`, используемые для озёр. Прежде чем вносить какие-либо изменения, убедитесь, что вы выбрали правильную плоскость воды. -### Creating a New Water Plane +### Создание новой плоскости воды -To create a new water plane: +Чтобы создать новую плоскость воды: -1. Add the `water_plane` prefab to the scene. -2. Position, rotate, and scale it as needed. -3. In the Inspector, open the Materials tab and assign the desired water material (typically `naval_worldmap_water`). -4. Ensure the required scripts and tag are present if the water plane is intended to function as navigable world map water. +1. Добавьте префаб `water_plane` на сцену. +2. Позиционируйте, вращайте и масштабируйте его по мере необходимости. +3. В Inspector откройте вкладку Materials и назначьте нужный материал воды (обычно `naval_worldmap_water`). +4. Убедитесь, что необходимые скрипты и тег присутствуют, если плоскость воды предназначена для функционирования в качестве судоходной воды карты мира. -Once configured, the water plane will integrate with the War Sails water rendering and Flowmap systems. +После настройки плоскость воды будет интегрирована с системами рендеринга воды War Sails и Flowmap. -## Storm System +## Система штормов -War Sails features a dynamic storm system that generates storms over open water. +War Sails включает динамическую систему штормов, которая генерирует штормы над открытой водой. -The world map is divided into a grid of 32 × 32 unit cells. For each cell whose center lies on an `OpenSea` navmesh, the game periodically checks whether a storm should spawn. +Карта мира разделена на сетку ячеек размером 32 × 32 единицы. Для каждой ячейки, центр которой лежит на навигационной сетке `OpenSea`, игра периодически проверяет, должен ли появиться шторм. -Three storm types are available: +Доступны три типа штормов: * `Storm` * `ThunderStorm` * `Hurricane` -The type of storm generated depends on the Flowmap data at the selected location. Each storm type has its own movement speed, radius, and damage characteristics. +Тип генерируемого шторма зависит от данных Flowmap в выбранном месте. Каждый тип шторма имеет свою собственную скорость перемещения, радиус и характеристики урона. -### Configuring Storms +### Настройка штормов -Storm behavior can be customized by overriding the `StormModel` (through code, not in the editor). This allows you to adjust parameters such as: +Поведение шторма можно настроить, переопределив `StormModel` (через код, а не в редакторе). Это позволяет настраивать такие параметры, как: -* Hourly spawn chance -* Maximum number of active storms -* Storm type configuration -* Storm lifetime +* Почасовой шанс появления +* Максимальное количество активных штормов +* Конфигурация типов штормов +* Продолжительность жизни шторма -### Storm Movement +### Движение шторма -Storms do not follow predefined paths. Instead, they are driven by the Flowmap. +Штормы не следуют заранее определённым путям. Вместо этого ими управляет Flowmap. -As a storm moves across the world map, it continuously follows the flow direction defined by the Flowmap at its current location. This allows storm movement to naturally match the current patterns you've painted into the map. +По мере того как шторм перемещается по карте мира, он непрерывно следует направлению потока, определённому Flowmap в его текущем местоположении. Это позволяет движению шторма естественным образом соответствовать узорам течений, которые вы нарисовали на карте. -### Flowmap Considerations +### Соображения по Flowmap -Storms gradually weaken and eventually dissipate when they remain over land navmesh. +Штормы постепенно ослабевают и в конечном итоге рассеиваются, если остаются над навигационной сеткой суши. -For this reason, when painting the Flowmap near coastlines, it is recommended to direct the flow away from land and toward open water. This helps keep storms at sea and prevents them from immediately dissipating after spawning or drifting near the coast. +По этой причине при рисовании Flowmap вблизи береговых линий рекомендуется направлять поток от суши к открытой воде. Это помогает удерживать штормы в море и предотвращает их немедленное рассеивание после появления или дрейфа вблизи побережья. -## Pirate Spawn Points +## Точки появления пиратов -War Sails uses dedicated pirate spawn points to control where pirate parties appear and the regions they patrol over time. +War Sails использует выделенные точки появления пиратов для контроля того, где появляются пиратские партии и какие регионы они патрулируют со временем. -Each pirate spawn point must have a `PirateSpawnPoint` script attached. In the script, set the Clan String ID to the appropriate pirate clan. War Sails has two clans available: +К каждой точке появления пиратов должен быть прикреплён скрипт `PirateSpawnPoint`. В скрипте установите Clan String ID (строковый ID клана) на соответствующий пиратский клан. В War Sails доступны два клана: * `northern_pirates` * `southern_pirates` -If you wish to add new clans, you should define them in the `clans.xml`, and then proceed to add them to the world map. +Если вы хотите добавить новые кланы, вам следует определить их в `clans.xml`, а затем добавить их на карту мира. diff --git a/docs/content/russian/_index.md b/docs/content/russian/_index.md index d20873d4..c241a5e1 100644 --- a/docs/content/russian/_index.md +++ b/docs/content/russian/_index.md @@ -14,17 +14,17 @@ weight = 1 1. **[Создание модуля - Краткое руководство]({{< ref "quickguide_create_a_mod.md" >}})**: создайте и зарегистрируйте свой первый модуль. 2. **[Добавление и переопределение ассетов]({{< ref "overriding_assets.md" >}})**: добавляйте новые ассеты или заменяйте существующие. -3. **[Merging Module XML Files with Native]({{< ref "merging_module_xml_files_with_native.md" >}})**: изменяйте игровые данные, не копируя файлы целиком. -4. **[Uploading/Updating a Mod]({{< ref "uploading_updating_mod.md" >}})**: опубликуйте мод в Steam Workshop. +3. **[Слияние XML-файлов модуля с нативными файлами]({{< ref "merging_module_xml_files_with_native.md" >}})**: изменяйте игровые данные, не копируя файлы целиком. +4. **[Загрузка/обновление мода]({{< ref "uploading_updating_mod.md" >}})**: опубликуйте мод в Steam Workshop. 5. **[Часто задаваемые вопросы]({{< ref "faq.md" >}})**: ответы на частые проблемы. ## Я хочу... {{< cards >}} {{< card title="Создавать сцены и ландшафт" icon="fa-map" >}} -- [Terrain Creation]({{< ref "terrain_creation.md" >}}) -- [Navmesh]({{< ref "nav_mesh.md" >}}) -- [Editor Shortcuts]({{< ref "editor_shortcuts.md" >}}) +- [Создание рельефа]({{< ref "terrain_creation.md" >}}) +- [Навмеш]({{< ref "nav_mesh.md" >}}) +- [Горячие клавиши редактора]({{< ref "editor_shortcuts.md" >}}) - [Руководство по производительности сцены]({{< ref "scene_performance_guide.md" >}}) {{< /card >}} {{< card title="Создавать сцены миссий" icon="fa-chess-rook" >}} @@ -34,26 +34,26 @@ weight = 1 - [Сцены укрытий]({{< ref "hideouts.md" >}}) {{< /card >}} {{< card title="Добавлять предметы и оружие" icon="fa-shield" >}} -- [Weapon Smithing & Crafting Pieces]({{< ref "weapon_smithing.md" >}}) +- [Кузнечное дело и элементы крафта оружия]({{< ref "weapon_smithing.md" >}}) - [Сетки]({{< ref "meshes.md" >}}) - [Материалы]({{< ref "materials.md" >}}) - [Текстуры]({{< ref "textures.md" >}}) {{< /card >}} {{< card title="Добавлять звуки и музыку" icon="fa-music" >}} -- [Audio Modding with FMOD Studio]({{< ref "audio-modding-overview.md" >}}) -- [Event Setup]({{< ref "audio-modding-event-setup.md" >}}) -- [Scene Audio]({{< ref "audio-modding-scene-audio.md" >}}) -- [Audio Systems & Optimization]({{< ref "audio-modding-systems.md" >}}) +- [Моддинг звука с помощью FMOD Studio]({{< ref "audio-modding-overview.md" >}}) +- [Настройка событий (Event Setup)]({{< ref "audio-modding-event-setup.md" >}}) +- [Звук сцены]({{< ref "audio-modding-scene-audio.md" >}}) +- [Аудиосистемы и оптимизация]({{< ref "audio-modding-systems.md" >}}) {{< /card >}} {{< card title="Создавать корабли и морской контент" icon="fa-ship" >}} -- [Ship Creation]({{< ref "ship_creation.md" >}}) -- [Seaborne Raid Scenes]({{< ref "what_makes_seaborne_village_raid_scene.md" >}}) -- [War Sails World Map]({{< ref "wsworldmap.md" >}}) +- [Создание корабля]({{< ref "ship_creation.md" >}}) +- [Из чего состоит сцена морского набега]({{< ref "what_makes_seaborne_village_raid_scene.md" >}}) +- [Карта мира War Sails]({{< ref "wsworldmap.md" >}}) {{< /card >}} {{< card title="Создавать контент для мультиплеера" icon="fa-users" >}} -- [Creating a Custom Game Mode]({{< ref "custom_game_mode.md" >}}) -- [Hosting a Custom Server]({{< ref "hosting_server.md" >}}) -- [Multiplayer Scenes]({{< ref "multiplayer_scenes.md" >}}) +- [Создание пользовательского игрового режима]({{< ref "custom_game_mode.md" >}}) +- [Размещение пользовательского сервера]({{< ref "hosting_server.md" >}}) +- [Что делает сцену многопользовательской]({{< ref "multiplayer_scenes.md" >}}) {{< /card >}} {{< card title="Изменять интерфейс, шрифты и баннеры" icon="fa-paint-brush" >}} - [UI таблицы спрайтов]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}}) @@ -101,7 +101,51 @@ weight = 1 - **[Документация API](https://apidoc.bannerlord.com/)**: справочник по коду Bannerlord. - **[Discord сообщества моддинга Mount & Blade](https://discord.gg/ykFVJGQ)**: задавайте вопросы и общайтесь с другими моддерами. -- **[Bannerlord Documentation (сообщество)](https://docs.bannerlordmodding.com/)**: руководства от сообщества, включая Gauntlet UI и упаковку модов для Vortex. -- **[BannerlordModding.LT (сообщество)](https://docs.bannerlordmodding.lt/)**: вики сообщества о процессах, техниках и советах по моддингу. +- **[Developer Workshop – Map Editor](https://www.youtube.com/watch?v=ovQiJfeQB8s)**: официальная трансляция TaleWorlds о работе с редактором карты кампании (на английском языке). - **[Форумы TaleWorlds – The Smithy](https://forums.taleworlds.com/index.php?forums/the-smithy-mod-development.643/)**: официальный форум разработки модов. - **[Участие на GitHub](https://github.com/TaleWorlds/Documentations)**: предлагайте исправления или новые страницы для этой документации. + +## Ресурсы от сообщества + +Эти ресурсы созданы и поддерживаются сообществом, а не TaleWorlds. Некоторые из них сделаны для старых версий игры, поэтому детали могут отличаться в текущей версии. Большинство материалов доступно только на английском языке. + +### Документация и руководства + +- **[Bannerlord Documentation](https://docs.bannerlordmodding.com/)**: руководства от сообщества, включая Gauntlet UI и упаковку модов для Vortex. +- **[BannerlordModding.LT](https://docs.bannerlordmodding.lt/)**: вики сообщества о процессах, техниках и советах по моддингу. +- **[Unofficial Bannerlord API Docs (BUTR)](https://bannerlordapi.butr.link/)**: справочник API для каждой версии игры, созданный на основе файлов игры. +- **[BUTR Documentation](https://butr.github.io/documentation)**: инструкции по отладке Harmony, отчётам о сбоях и публикации модов через GitHub Actions. +- **[Форум Documentation & Tutorials](https://forums.taleworlds.com/index.php?forums/documentation-tutorials.753/)**: руководства от сообщества на форумах TaleWorlds. + +### Руководства сообщества (Google Docs) + +- **[3D Asset Workflow](https://docs.google.com/document/d/1aHBsO3mzkT0JsbCt9aCOh6CWAFATXwKtSaVb__TYIoo/edit)**: подготовка 3D-ассетов для Bannerlord. +- **[Asset Import Workflow](https://docs.google.com/document/d/11-J8HzS2FdnwwXfR7JmD_FQSQ6dWaJj_BZr1-vVW9Ks/edit)**: пошаговый процесс импорта ассетов. +- **[Importing Assets into BL Editor](https://docs.google.com/document/d/1ZnkRjNu6wUx3UM0exMiC8WhE8iDXPJKqYcbZdRh_q0o/edit)**: как добавить свои ассеты в редактор Bannerlord. +- **[Importing Material Maps in Editor](https://docs.google.com/document/d/1843jpWFYLylJya1-_-wQpkemV58KT3EomEoqUYKpZTo/edit)**: импорт текстур и карт материалов. +- **[Basic World Mapping](https://docs.google.com/document/d/1npGJ9p1ySdu2RDU19P_2aE-OCsKWie_G02vcws36UIs/edit)**: введение в создание собственной карты кампании. +- **[Adding Custom Scenes to Custom Battle](https://docs.google.com/document/d/1Rwsd9pdv5QA5s3K4oOuJX16_K9A5NaoWh0p78IcUi1w/edit)**: проверка собственных сцен в режиме «Своя битва». +- **[Adding Flora to flora_kinds](https://docs.google.com/document/d/1VGpct-__3s6hn15GXHo5P1TS-yMrGfDxCed1UZ3AaNI/edit)**: регистрация новой растительности в flora_kinds. +- **[Bannerlord Layer Buttons, Options, and Settings](https://docs.google.com/document/d/1EiLvSZEJ_88fnva6d9s8H36XLH13YkVdim6jABe095s/edit)** (не завершено): назначение кнопок слоёв, параметров и настроек редактора. + +### Видеоуроки + +- **[Lesser Scholar – Artisan Workshop Mod](https://www.youtube.com/playlist?list=PLzebdAxJeltRwfJ8jzsNolgHkRvLjoCRC)**: курс по C# из 19 частей: настройка, поведения кампании, диалоги, Gauntlet UI, Harmony и публикация. +- **[A_Jannik](https://www.youtube.com/playlist?list=PLXLt7zu34iHFzZVDzZpvareujNqbJiypj)**: точки входа C#, отладка и патчи Harmony. +- **[Danqna & Gispry](https://www.youtube.com/watch?v=duvR9xFvu9Q)**: серия по C# из 6 частей: настройка Visual Studio, диалоги, сохранения и меню MCM. +- **[Macbeth of Gondor](https://www.youtube.com/@MacbethofGondor)**: серия из 19 частей по редактору сцен: ландшафт, растительность, navmesh, сезоны, префабы и барьеры. +- **[Banner Lab](https://www.youtube.com/playlist?list=PLxhni8XI_dRDjRRDsCzEBZg4eUInzkzQT)**: моддинг XML без кода: войска, предметы, культуры, королевства, герои и поселения. +- **[Lykon Development](https://www.youtube.com/@LykonDevelopment/videos)**: войска, оружие и королевства в XML, экраны загрузки и рисование весов в Blender. +- **[Adam Dotlačil](https://www.youtube.com/@enpremi)**: собственные луки, арбалеты и колчаны, а также анимации рук для собственных моделей. +- **[BabyLettuce – Skeletons & Races](https://www.youtube.com/watch?v=eXHd8yjoxk0)**: полное руководство по собственным скелетам и расам. + +### Инструменты + +- **[Bannerlord Scene Toolkit](https://github.com/fiefevictionnotice/BannerlordSceneToolkit)** от FiefEvictionNotice: инструменты, работающие внутри редактора сцен: замена и перекраска материалов, создание, распределение и отражение префабов, анализ сцен и резервные копии. См. [видеоурок](https://www.youtube.com/watch?v=f1uzZ-qQm3c) (на английском языке). +- **[XBannerlord](https://forums.taleworlds.com/index.php?threads/tool-xbannerlord-an-ai-powered-xml-editor-for-bannerlord-mod-xmls.470278/)** от cookgreen: редактор XML для Windows, который показывает XML-файлы Bannerlord в виде дерева и позволяет изменять выбранный узел в диалоге с ИИ-моделью. Интерфейс на английском и китайском языках. [Исходный код на GitHub](https://github.com/cookgreen/XBannerlord). +- **[Bannerlord Crafting Tool](https://github.com/haterade22/TAOM/releases/tag/crafting-tool-v1.0)** от haterade22: инструмент для Windows, который показывает части оружия для ковки в 2D и 3D, позволяя настроить их смещения и проверить длину оружия без запуска игры. + +### Стартовые наборы + +- **[Campaign Map Prefab Starter Pack](https://www.nexusmods.com/mountandblade2bannerlord/mods/11608)** от Lemmy1916: готовая карта кампании с поселениями и скриптами для создания новой карты мира. +- **[War Sails Campaign Map Prefab Starter Pack](https://www.nexusmods.com/mountandblade2bannerlord/mods/13602)** от Lemmy1916: та же стартовая карта, настроенная для War Sails. diff --git a/docs/content/schinese/Asset Management/Asset Types/path.md b/docs/content/schinese/Asset Management/Asset Types/path.md index 61d3a120..22714687 100644 --- a/docs/content/schinese/Asset Management/Asset Types/path.md +++ b/docs/content/schinese/Asset Management/Asset Types/path.md @@ -1,5 +1,5 @@ +++ -title = "Paths" +title = "路径" description = "" weight = 1 +++ diff --git a/docs/content/schinese/Asset Management/Asset Types/shaders.md b/docs/content/schinese/Asset Management/Asset Types/shaders.md new file mode 100644 index 00000000..9d022eb9 --- /dev/null +++ b/docs/content/schinese/Asset Management/Asset Types/shaders.md @@ -0,0 +1,17 @@ ++++ +title = "着色器" +description = "" +weight = 1 +ai_translated = true ++++ + +着色器(Shader)是在 GPU 核心上运行的程序片段。它们定义了渲染方法。 + +##### 材质着色器标志与着色器组合(Material Shader Flags & Shader Combinations) +着色器定义了材质标志(material flags),这些标志可以按材质进行配置。每个材质着色器标志都会更改着色器代码的一部分,以改变材质的外观。例如,一旦启用了"USE_PROCEDURAL_WIND_ANIMATION"标志,材质将开始根据场景中的风力沿固定轴进行动画。 + +##### 着色器缓存(Shader Cache) +每个材质都定义了一种新的着色器标志组合,这反过来又定义了一个需要编译的新着色器代码。游戏附带了一个着色器缓存,其中包含基础游戏中所有独特的着色器 + 材质着色器标志组合。 + +##### 为模组进行批量着色器编译(Bulk Shader Compilation for Mods) +如果一个模组添加了相当多的新组合,运行时着色器编译可能会极大地影响游戏流程。为避免这种情况,模组所有者应该编译该模组中引入的独特着色器 + 材质组合。要做到这一点,在编辑器中通过"Publish Module"(发布模组)功能发布模组时,应勾选"Compile Shaders"(编译着色器)复选框。着色器缓存将被保存到"Modules/'ModuleName'/Shaders/D3D11"文件夹中。请注意,游戏着色器可能会在某些版本更新中发生更改,尽管这种情况并不常见,但在这些情况下,旧的着色器缓存文件将失效且不会被使用。为避免这种情况,建议在每次上传到游戏的新主要版本之前重新创建着色器缓存。着色器编译系统具有高度并行性,根据 CPU 的多核性能,可能需要大约 30 到 60 分钟才能完成。 diff --git a/docs/content/schinese/Asset Management/Asset Types/skeletons.md b/docs/content/schinese/Asset Management/Asset Types/skeletons.md index 2606205c..61732356 100644 --- a/docs/content/schinese/Asset Management/Asset Types/skeletons.md +++ b/docs/content/schinese/Asset Management/Asset Types/skeletons.md @@ -1,5 +1,5 @@ +++ -title = "Skeletons" +title = "骨骼" description = "" weight = 1 +++ diff --git a/docs/content/schinese/Asset Management/creating_custom_banner_icons.md b/docs/content/schinese/Asset Management/creating_custom_banner_icons.md index 3a944003..84650458 100644 --- a/docs/content/schinese/Asset Management/creating_custom_banner_icons.md +++ b/docs/content/schinese/Asset Management/creating_custom_banner_icons.md @@ -1,69 +1,71 @@ +++ -title = "Creating Custom Banner Icons & Colors" +title = "创建自定义旗帜图标与颜色" weight = 15 +ai_translated = true +++ -#### Introduction +#### 简介 -This documentation will go through the following steps: +本文档将介绍以下步骤: -* Setting up a custom texture containing banner icons. -* Generating a material for the custom banner icons. -* Adding newly created banner icons to a custom module. -* Adding custom icon colors to Banner Editor. +* 设置包含旗帜图标的自定义贴图。 +* 为自定义旗帜图标生成材质。 +* 将新创建的旗帜图标添加到自定义模组中。 +* 向旗帜编辑器(Banner Editor)添加自定义图标颜色。 -#### Prerequisites +#### 先决条件 -* Mount & Blade II: Bannerlord - Modding Kit downloaded from Steam. +* 从Steam下载的《骑马与砍杀2:领主》- 模组制作工具包(Modding Kit)。 -#### Creating a Banner Icon Texture +#### 创建旗帜图标贴图 -* To create a set of new banner icons, first create a PSD file with 2048x2048 resolution that is split into 16 equal grid parts. -* Then put this file into your module's **AssetSources\BannerIcons** directory. -* In the sample image below, canvas is split into a 4x4 grid and there is a sample banner icon at the first(0th) slot. -* Banner icon slots start with slots 0, 1, 2 and 3 at the top row and ends with slots 12, 13, 14, 15 at the bottom row. +* 要创建一套新的旗帜图标,首先需要创建一个分辨率为2048x2048的PSD文件,并将其分割为16个相等的网格部分。文件可以比这更大,但不建议将其做得更小。 +* 然后将此文件放入你的模组的**AssetSources\BannerIcons**目录中。请注意,该文件可以是PSD或DDS格式。 +* 此外,你还需要在**Assets\BannerIcons**中创建一个空文件夹。 +* 在下方的示例图片中,画布被分割为4x4网格,并且在第一个(第0个)槽位中有一个示例旗帜图标。 +* 旗帜图标槽位从顶行的0、1、2、3开始,到底行的12、13、14、15结束。 -#### Importing Banner Icon Texture In Game and Creating a new Material +#### 将旗帜图标贴图导入游戏并创建新材质 -* Now that the texture is added, Launch Mount & Blade II: Bannerlord - Modding Kit from Steam. -* Make sure your module is selected in the Mods section of the Launcher, then hit “Play”. -* On the main menu, press **Alt + `** to open the console. -* Type **resource.show_resource_browser** then hit enter. -* From the resource browser, select the folder with your module's name. -* While in this folder, click on "Scan new asset files". +* 现在贴图已添加完毕,请从Steam启动《骑马与砍杀2:领主》- 模组制作工具包(Modding Kit)。 +* 确保在启动器的Mods部分选中你的模组,然后点击"Play"。 +* 在主菜单中,按下**Alt + `**打开控制台。 +* 输入**resource.show_resource_browser**,然后按回车键。 +* 在资源浏览器(Resource Browser)中,选择与你的模组名称相同的文件夹。 +* 在该文件夹中,点击"Scan new asset files"(扫描新资源文件)。 -* If you've done the previous steps correctly, a popup should display a new file detected. Click import. +* 如果你正确完成了前面的步骤,会弹出一个窗口提示检测到新文件。点击导入(import)。 -* Go into **BannerIcons** subfolder and click on the texture you've created and set the Import Settings as shown below. +* 进入**BannerIcons**子文件夹,点击你创建的贴图,并按如下所示设置导入设置(Import Settings)。如果你的旗帜图案细节较多,也建议勾选"**Do not Compress**"(不压缩)选项。 -* While in the same folder, right click and select **Create** and then **Material**. Name this material with the same name that your texture has. +* 在同一文件夹中,右键单击并选择**Create**(创建),然后选择**Material**(材质)。将此材质命名为与你的贴图相同的名称。 -* The new material should show up as shown below. +* 新材质应如下图所示出现。 -* Initial settings for the new material: - * Remove all predefined textures from the Textures List. - * Add your banner icons texture to the diffuse slot of the Textures List. - * Set the shader from **pbr_metallic** to **gui_color_and_stroke**. +* 新材质的初始设置: + * 从贴图列表(Textures List)中移除所有预定义的贴图。 + * 将你的旗帜图标贴图添加到贴图列表的漫反射(diffuse)槽位中。 + * 将着色器(shader)从**pbr_metallic**设置为**gui_color_and_stroke**。 -* Additional settings for **Material Shader Flags**, **Transparency**, **Others** and **Vertex Layout** tabs: +* **材质着色器标志(Material Shader Flags)**、**透明度(Transparency)**、**其他(Others)**以及**顶点布局(Vertex Layout)**选项卡的附加设置: -* Now that we are done with the texture and the material of our custom banner icon, we can add it to our module. +* 现在我们已经完成了自定义旗帜图标的贴图和材质设置,可以将其添加到我们的模组中。 -#### Creating Custom Banner Definitions +#### 创建自定义旗帜定义 -* To use custom banner icons in game, an XML file containing banner definitions needs to be added to your module. -* Path of this file is **{MODULE_NAME}\ModuleData\banner_icons.xml**. -* This file is automatically loaded while your module is loading. -* An example **banner_icons.xml** is shown below. +* 要在游戏中使用自定义旗帜图标,需要向你的模组中添加一个包含旗帜定义的XML文件。 +* 该文件的路径为**{MODULE_NAME}\ModuleData\banner_icons.xml**。 +* 该文件会在你的模组加载时自动加载。 +* 下面展示了一个示例**banner_icons.xml**文件。 ```xml @@ -76,28 +78,29 @@ This documentation will go through the following steps: ``` -* After the baseline XML definition, a root element named **BannerIconData** is added. All of the custom icons are added under this element. -* For each icon group, a **BannerIconGroup** element needs to be added. The ID of this group needs to be unique. Check Native Module's banner icon group IDs before adding a custom group. -* The name parameter is decided by you, the modder, and can be anything. The naming scheme is the same with any other localized text. -* Children elements of **BannerIconGroup** are **Icon** elements. All icon elements also have to have a unique ID. The same ID rules as Banner Icon Groups apply for Icons as well. -* Material name of the icon needs to be the material we've created in the previous step. -* Texture Index is a number from 0 to 15 and it is described in the first step of this guide. -* If you've added the **banner_icons.xml** file shown above to your module and relaunch the game, you should be able to use the icon you've created. -* The icon with the empty thumbnail is the icon we've created. Click on that button to select the newly created banner icon. +* 在基础XML定义之后,添加了一个名为**BannerIconData**的根元素。所有自定义图标都添加在该元素之下。 +* 对于每个图标组,需要添加一个**BannerIconGroup**元素。该组的ID必须是唯一的。在添加自定义组之前,请先检查原生模组的旗帜图标组ID。 +* name参数由你(模组制作者)自行决定,可以是任意内容。其命名方式与其他本地化文本相同。 +* **BannerIconGroup**的子元素是**Icon**元素。所有图标元素同样必须具有唯一的ID。图标的ID规则与旗帜图标组相同。 +* 图标的材质名称需要与我们在上一步中创建的材质相同。 +* 贴图索引(Texture Index)是一个从0到15的数字,在本指南的第一步中已有说明。 +* 如果你已将上面展示的**banner_icons.xml**文件添加到你的模组中并重新启动游戏,你应该就能使用你创建的图标了。 +* 带有空白缩略图的图标就是我们创建的图标。点击该按钮以选择新创建的旗帜图标。 -* Notice that the thumbnail is missing. To add the thumbnail, follow the [Generating and Loading UI Sprite Sheets]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}}) guide. Note that the name of your sprite and the ID of the icon needs to be same. So for our example, thumbnail sprite's name is **16001.png** -* After generating the thumbnail, the banner icons list should look as follows. +* 请注意缩略图尚未显示。要添加缩略图,请参阅[生成和加载UI精灵表(Generating and Loading UI Sprite Sheets)]({{< ref "generating_and_loading_ui_sprite_sheets.md" >}})指南。请注意,你的精灵图名称需要与图标的ID相同。因此在我们的示例中,缩略图精灵图的名称为**16001.png**。 +* 生成缩略图后,旗帜图标列表应如下所示。 -#### Adding Custom Color Options +#### 添加自定义颜色选项 -* To add a set of colors, create a **BannerColors** element in your modules **banner_icons.xml** file. -* Children elements of **BannerColors** are **Color** elements. All color elements have to have a unique ID. Same ID rules as **Icon** elements apply here as well. -* There are two optional parameters for colors. - * **player_can_choose_for_background**: Makes color available at the Background Color section of the Banner Editor Screen. - * **player_can_choose_for_sigil**: Makes color available at the Sigil Color section of the Banner Editor Screen. -* If none of these parameters are given as **true**, the color is still added to use in banners but can be only used by NPC clans and factions. +* 要添加一组颜色,请在你的模组的**banner_icons.xml**文件中创建一个**BannerColors**元素。 +* **BannerColors**的子元素是**Color**元素。所有颜色元素必须具有唯一的ID。此处的ID规则与**Icon**元素相同。 +* 颜色有两个可选参数。 + * **player_can_choose_for_background**:使该颜色在旗帜编辑器界面(Banner Editor Screen)的背景颜色(Background Color)部分中可用。 + * **player_can_choose_for_sigil**:使该颜色在旗帜编辑器界面(Banner Editor Screen)的纹章颜色(Sigil Color)部分中可用。 +* 如果这些参数都没有设置为**true**,该颜色仍会被添加以用于旗帜,但只能被NPC氏族和势力使用。 +* 如果要添加大量新颜色,可能需要包含并更新位于**Native\GUI\Prefabs\BannerEditor**中名为**BannerEditor.xml**的预制件(prefab)。 ```xml @@ -114,5 +117,5 @@ This documentation will go through the following steps: ``` -* If you added the colors like shown above, you will get the following colors in Banner Editor Screen. +* 如果你按照上面所示添加了颜色,你将在旗帜编辑器界面(Banner Editor Screen)中获得以下颜色。 diff --git a/docs/content/schinese/Asset Management/generating_and_loading_ui_sprite_sheets.md b/docs/content/schinese/Asset Management/generating_and_loading_ui_sprite_sheets.md index 6cb21d5c..a24f82a8 100644 --- a/docs/content/schinese/Asset Management/generating_and_loading_ui_sprite_sheets.md +++ b/docs/content/schinese/Asset Management/generating_and_loading_ui_sprite_sheets.md @@ -1,80 +1,81 @@ +++ -title = "Generating and Loading UI Sprite Sheets" +title = "生成和加载 UI 精灵表" weight = 15 +ai_translated = true +++ -#### Introduction -Sprites are two-dimensional images that are mostly used in the user interface of a game. Sprite sheets are the collection of such images. In other words, sprites are packed together to form a sprite sheet. This documentation will go through the following steps: +#### 简介 +精灵(Sprite)是二维图像,主要用于游戏的用户界面中。精灵表(Sprite Sheet)是此类图像的集合。换句话说,精灵被打包在一起形成一张精灵表。本文档将介绍以下步骤: -* Adding new sprites. -* Generating sprite sheets from the sprites that you have added. -* Importing the sprite sheets to your module. -* Using sprites in UI XML files. -* Loading and unloading the sprite categories. +* 添加新的精灵。 +* 从你添加的精灵生成精灵表。 +* 将精灵表导入到你的模组中。 +* 在 UI XML 文件中使用精灵。 +* 加载和卸载精灵分类(category)。 -#### Prerequisites -* A submodule created under INSTALLATION_PATH\Mount & Blade II Bannerlord\Modules\ -* Knowing how to build your project from the Integrated Development Environment (IDE) like Visual Studio. -* Mount & Blade II: Bannerlord - Modding Kit downloaded from Steam. +#### 前提条件 +* 在 INSTALLATION_PATH\Mount & Blade II Bannerlord\Modules\ 下创建的子模组 +* 了解如何从集成开发环境(IDE),如 Visual Studio,构建你的项目。 +* 从 Steam 下载的 Mount & Blade II: Bannerlord - Modding Kit。 -#### Adding Sprites -* Create a new folder named GUI under Modules\YOUR_MODULE_NAME\ -* Create a new folder named SpriteParts under the newly created folder GUI. -* Create a new folder named ui_{YOUR_CATEGORY_NAME} under the newly created folder SpriteParts. In this documentation, it will be named **ui_mycategory**. -* Note: Content inside of ui_{YOUR_CATEGORY_NAME} will be put in a single category called YOUR_CATEGORY_NAME. All the sprites in a category are loaded and unloaded together. It is suggested to divide your sprites into categories (instead of having only one category) in order to avoid unnecessary sprites being loaded. For example, you may create a new screen in the game that requires certain sprites to be loaded. Those sprites could be packed into a category and once that screen is opened, you can then load the relevant sprites only, and then when the screen is closed you can then unload them (see Loading & Unloading Sprite Categories section). -* Put your sprites into the ui_{YOUR_CATEGORY_NAME} folder. For example, this sprite is added and named **mysprite.png**: -* For launcher, new sprites should be added to a category under MODULE_NAME\LauncherGUI\SpriteParts. +#### 添加精灵 +* 在 Modules\YOUR_MODULE_NAME\ 下创建一个名为 GUI 的新文件夹。 +* 在新创建的 GUI 文件夹下创建一个名为 SpriteParts 的新文件夹。 +* 在新创建的 SpriteParts 文件夹下创建一个名为 ui_{YOUR_CATEGORY_NAME} 的新文件夹。在本文档中,它将被命名为 **ui_mycategory**。 +* 注意:ui_{YOUR_CATEGORY_NAME} 内的内容将被放入一个名为 YOUR_CATEGORY_NAME 的单一分类中。一个分类中的所有精灵会一起被加载和卸载。建议将你的精灵划分为多个分类(而不是只有一个分类),以避免加载不必要的精灵。例如,你可能在游戏中创建一个新屏幕,需要加载某些精灵。这些精灵可以被打包成一个分类,一旦该屏幕打开,你就可以只加载相关的精灵,然后在屏幕关闭时将它们卸载(参见加载与卸载精灵分类部分)。 +* 将你的精灵放入 ui_{YOUR_CATEGORY_NAME} 文件夹中。例如,添加了这个精灵并命名为 **mysprite.png**: +* 对于启动器(Launcher),新精灵应添加到 MODULE_NAME\LauncherGUI\SpriteParts 下的某个分类中。 -#### Generating Sprite Sheets -In order to generate sprite sheets, run the TaleWorlds.TwoDimension.SpriteSheetGenerator.exe executable file located at INSTALLATION_PATH\Mount & Blade II Bannerlord\bin\Win64_Shipping_wEditor. If you have followed the steps above, after running SpriteSheetGenerator.exe, you should see the following window: +#### 生成精灵表 +为了生成精灵表,运行位于 INSTALLATION_PATH\Mount & Blade II Bannerlord\bin\Win64_Shipping_wEditor 的 TaleWorlds.TwoDimension.SpriteSheetGenerator.exe 可执行文件。如果你已按照上述步骤操作,在运行 SpriteSheetGenerator.exe 后,你应该会看到以下窗口: -SpriteSheetGenerator.exe will create two folders named Assets and AssetSources under Modules\YOUR_MODULE_NAME. It will also create a SpriteData.xml file (with a prefix of your module name) under Modules\YOUR_MODULE_NAME\GUI. +SpriteSheetGenerator.exe 将在 Modules\YOUR_MODULE_NAME 下创建两个名为 Assets 和 AssetSources 的文件夹。它还会在 Modules\YOUR_MODULE_NAME\GUI 下创建一个 SpriteData.xml 文件(带有你的模组名称前缀)。 -* If you are generating sprite sheets for the launcher, use **Update Launcher SpriteSheets.bat** script under LauncherGUI folder. +* 如果你是在为启动器生成精灵表,请使用 LauncherGUI 文件夹下的 **Update Launcher SpriteSheets.bat** 脚本。 -#### Importing Created Sprite Sheets -In order to use the sprites in your sprite sheets, you should also import them from the resource browser. Note that this step should be skipped if you are adding sprites just for the Launcher. +#### 导入已创建的精灵表 +为了使用你精灵表中的精灵,你还需要从资源浏览器(resource browser)中导入它们。请注意,如果你只是为启动器添加精灵,则应跳过此步骤。 -Follow these steps to import a sprite sheet: +按照以下步骤导入精灵表: -* Make sure you have built your project into Modules\YOUR_MODULE_NAME\bin\Win64_Shipping_wEditor (in addition to Win64_Shipping_Client). If your project is not built properly, you will get a crash while launching. -* Run Mount & Blade II: Bannerlord - Modding Kit from Steam. -* Make sure your mode is selected in the Mods section of the Launcher, then hit “Play”. -* On the main menu, press Alt + ` to open the console. -* Type resource.show_resource_browser, then hit enter. +* 确保你已将项目构建到 Modules\YOUR_MODULE_NAME\bin\Win64_Shipping_wEditor(除了 Win64_Shipping_Client 之外)。如果你的项目构建不正确,在启动时会发生崩溃。 +* 从 Steam 运行 Mount & Blade II: Bannerlord - Modding Kit。 +* 确保在启动器(Launcher)的 Mods 部分选中了你的模组,然后点击"Play"。 +* 在主菜单中,按 Alt + ` 打开控制台。 +* 输入 resource.show_resource_browser,然后按回车。 -This should open the resource browser: +这应该会打开资源浏览器: -Collapse the folder named Native on the left of the resource browser to see your module easily. Then, select your module. +折叠资源浏览器左侧名为 Native 的文件夹,以便更轻松地找到你的模组。然后,选择你的模组。 -Open the GauntletUI folder in your module. Then, press the “Scan new asset files” button which is pointed with a red arrow below (arrow on the right). +打开你模组中的 GauntletUI 文件夹。然后,按下下面用红色箭头标出的"Scan new asset files"(扫描新资源文件)按钮(右侧箭头)。 -This should open a new window: +这应该会打开一个新窗口: -Make sure your category is selected (in the example, it is ui_mycategory) then press the Import button. Then, you should see something similar to this: +确保选中了你的分类(在本示例中为 ui_mycategory),然后点击 Import(导入)按钮。然后,你应该会看到类似这样的内容: -Close the resource browser and the game. -You should now see a new file named ui_{YOUR_CATEGORY_NAME}_1_tex.tpac under Modules\YOUR_MODULE_NAME\Assets\GauntletUI. +关闭资源浏览器和游戏。 +你现在应该会在 Modules\YOUR_MODULE_NAME\Assets\GauntletUI 下看到一个名为 ui_{YOUR_CATEGORY_NAME}_1_tex.tpac 的新文件。 -#### Using Sprites In UI XML Files -You may now use the sprites in the sprite sheets that you have created (you also need to load the corresponding category which is explained below, in the Loading & Unloading Sprite Categories section). Sprites are used in UI XML files. You may refer to your sprites with their names. You can find the names of your sprites in the SpriteData.xml file (with a prefix of your module name) which is located at Modules\YOUR_MODULE_NAME\GUI. -To give an example, we will create a new UI XML file. To do that, go back to the folder named GUI under Modules\YOUR_MODULE_NAME\ and create a new folder named Prefabs. Create a new file named MyXml.xml under the Prefabs folder. You may now refer to your sprites in this file as Sprite="mysprite". For example, the content of the MyXml.xml file could be: +#### 在 UI XML 文件中使用精灵 +你现在可以使用你创建的精灵表中的精灵了(你还需要加载相应的分类,这在下面的加载与卸载精灵分类部分中有说明)。精灵在 UI XML 文件中使用。你可以通过名称来引用你的精灵。你可以在位于 Modules\YOUR_MODULE_NAME\GUI 的 SpriteData.xml 文件(带有你的模组名称前缀)中找到你精灵的名称。 +举个例子,我们将创建一个新的 UI XML 文件。为此,返回到 Modules\YOUR_MODULE_NAME\ 下名为 GUI 的文件夹,并创建一个名为 Prefabs 的新文件夹。在 Prefabs 文件夹下创建一个名为 MyXml.xml 的新文件。你现在可以在这个文件中通过 Sprite="mysprite" 来引用你的精灵。例如,MyXml.xml 文件的内容可以是: @@ -86,27 +87,27 @@ To give an example, we will create a new UI XML file. To do that, go back to the -#### Loading & Unloading Sprite Categories -In order to use the sprites that you have added, you need to load them. You have two options in this regard:¸ +#### 加载与卸载精灵分类 +为了使用你添加的精灵,你需要加载它们。在这方面,你有两种选择:¸ -1. Loading & Unloading Manually - * The developer has more control. They can choose when the sprite categories are loaded and unloaded. Thus, they can manage memory usage and performance. - * Requires writing code. Thus, more complex than The AlwaysLoad Option. +1. 手动加载与卸载 + * 开发者拥有更多的控制权。他们可以选择何时加载和卸载精灵分类。因此,他们可以管理内存使用和性能。 + * 需要编写代码。因此,比 AlwaysLoad 选项更复杂。 -2. Using The AlwaysLoad Option - * Sprite categories are loaded on startup automatically. - * Categories are kept in the memory until the game is closed. Thus, no need to manually load them every time they are used. - * Decreased UI loading time at the cost of increased memory usage. - * Easy to use. +2. 使用 AlwaysLoad 选项 + * 精灵分类在启动时自动加载。 + * 分类会保留在内存中,直到游戏关闭。因此,每次使用时无需手动加载它们。 + * 以增加内存使用为代价,减少 UI 加载时间。 + * 易于使用。 -##### 1. Loading & Unloading Manually -Here we show how to load & unload sprite categories manually. In the example below, we override the OnGameStart and OnGameEnd methods of MBSubModuleBase class to add and remove the MyScreen global layer respectively. Notice that the constructor of MyScreen loads the sprite category and the UI XML that we have created in previous sections. We also unload the sprite category inside the OnFinalize method. +##### 1. 手动加载与卸载 +这里我们展示如何手动加载和卸载精灵分类。在下面的示例中,我们重写了 MBSubModuleBase 类的 OnGameStart 和 OnGameEnd 方法,分别用于添加和移除 MyScreen 全局层(global layer)。请注意,MyScreen 的构造函数加载了我们在前面章节中创建的精灵分类和 UI XML。我们还在 OnFinalize 方法中卸载了该精灵分类。 -If you are going to copy the below code, do not forget to change the namespace and name of the Main function. They should match with the fields in your SubModule.xml. In other words, you should change SpritesheetDocumentation (namespace) to YOUR_MODULE_NAME and Main (name of the Main function) to YOUR_MAIN_FUNCTION_NAME in this field of the SubModule.xml: +如果你要复制下面的代码,别忘了更改命名空间(namespace)和 Main 函数的名称。它们应该与你 SubModule.xml 中的字段相匹配。换句话说,你应该在 SubModule.xml 的这个字段中,将 SpritesheetDocumentation(命名空间)更改为 YOUR_MODULE_NAME,将 Main(Main 函数的名称)更改为 YOUR_MAIN_FUNCTION_NAME: -Otherwise, they won’t be recognized and the game will crash while launching. +否则,它们将无法被识别,游戏将在启动时崩溃。 using TaleWorlds.Core; using TaleWorlds.MountAndBlade; @@ -172,14 +173,14 @@ Otherwise, they won’t be recognized and the game will crash while launching. } } -##### 2. Using The AlwaysLoad Option -Instead of manually loading sprite categories like in the Loading & Unloading Manually section, you can choose which sprite categories should be loaded automatically on startup by enabling the AlwaysLoad option for those categories. Unless they are manually unloaded by the developer, categories that have the AlwaysLoad option enabled will be kept in the memory until the game is closed so that you don’t have to load them manually every time they are used. Enabling the AlwaysLoad option decreases the load time of UI (since these categories are loaded only once on startup) but increases memory usage (since these categories will be kept in the memory even when they are not used). This option is very useful for the categories that are frequently loaded & unloaded (f.e. A category that is used in a screen that is opened and closed frequently). +##### 2. 使用 AlwaysLoad 选项 +与手动加载与卸载部分中手动加载精灵分类不同,你可以通过为特定分类启用 AlwaysLoad 选项,来选择哪些精灵分类应在启动时自动加载。除非开发者手动卸载,否则启用了 AlwaysLoad 选项的分类将一直保留在内存中,直到游戏关闭,这样你就不必每次使用时都手动加载它们。启用 AlwaysLoad 选项会减少 UI 的加载时间(因为这些分类只在启动时加载一次),但会增加内存使用(因为即使这些分类未被使用,也会保留在内存中)。此选项对于经常被加载和卸载的分类非常有用(例如,用于一个频繁打开和关闭的屏幕的分类)。 -Note: This feature has been released with e1.6.2. If you are on an earlier version and still want to use the AlwaysLoad option, please switch both the game and the modding kit to e1.6.2 or a newer version. +注意:此功能随 e1.6.2 版本发布。如果你使用的是更早的版本,但仍想使用 AlwaysLoad 选项,请将游戏和模组开发工具包(modding kit)都切换到 e1.6.2 或更新的版本。 -To enable the AlwaysLoad option for a category, follow the steps below: +要为某个分类启用 AlwaysLoad 选项,请按照以下步骤操作: -Create a new XML file named Config.xml under the folder Modules\YOUR_MODULE_NAME\GUI\SpriteParts. Copy and paste the following into Config.xml: +在文件夹 Modules\YOUR_MODULE_NAME\GUI\SpriteParts 下创建一个名为 Config.xml 的新 XML 文件。将以下内容复制并粘贴到 Config.xml 中: @@ -187,7 +188,7 @@ Create a new XML file named Config.xml under the folder Modules\YOUR_MODULE_NAME -Replace ui_{YOUR_CATEGORY_NAME} with your category. Then, generate sprite sheets by following the steps in the Generating Sprite Sheets section above. To check if everything is okay, open the file named {YOUR_MODULE_NAME}SpriteData.xml which is located at Modules\YOUR_MODULE_NAME\GUI. There you should see that the AlwaysLoad option is enabled for the categories that you have selected in the Config.xml: +将 ui_{YOUR_CATEGORY_NAME} 替换为你的分类。然后,按照上面生成精灵表部分中的步骤生成精灵表。要检查一切是否正常,请打开位于 Modules\YOUR_MODULE_NAME\GUI 的 {YOUR_MODULE_NAME}SpriteData.xml 文件。在那里你应该会看到,你在 Config.xml 中选择的分类已启用了 AlwaysLoad 选项: @@ -201,12 +202,12 @@ Replace ui_{YOUR_CATEGORY_NAME} with your category. Then, generate sprite sheets ... -You don’t need to change/add any code to load the new sprite sheet category. +你不需要更改/添加任何代码来加载新的精灵表分类。 -#### Conclusion -Make sure you have created a screen and loaded the UI XML file that you have created in Using Sprites In UI XML Files section in order to see the result below. +#### 结论 +为了看到下面的结果,请确保你已经创建了一个屏幕,并加载了你在"在 UI XML 文件中使用精灵"部分创建的 UI XML 文件。 -Note: If you have added your sprite category with the AlwaysLoad option and didn’t use the code shared in the Loading & Unloading Manually section, you can write your own code to create a screen and load the UI XML. If you don’t know how to do it, you can copy the code from the Loading & Unloading Manually section (please also read the details in that section) and delete the following lines since you have used the AlwaysLoad option and don’t need to load the category manually: +注意:如果你已经使用 AlwaysLoad 选项添加了你的精灵分类,但没有使用"手动加载与卸载"部分中分享的代码,你可以编写自己的代码来创建一个屏幕并加载 UI XML。如果你不知道该怎么做,可以复制"手动加载与卸载"部分中的代码(也请阅读该部分中的详细信息),并删除以下几行,因为你已经使用了 AlwaysLoad 选项,不需要手动加载该分类: var spriteData = UIResourceManager.SpriteData; var resourceContext = UIResourceManager.ResourceContext; @@ -215,11 +216,11 @@ Note: If you have added your sprite category with the AlwaysLoad option and didn _category = spriteData.SpriteCategories["ui_mycategory"]; // select which category to load, put your category name here _category.Load(resourceContext, resourceDepot); // load the selected category -You can also delete the _category field and remove its references. +你也可以删除 _category 字段并移除对它的引用。 -* Make sure you have built your project into Modules\YOUR_MODULE_NAME\bin\Win64_Shipping_Client. -* Launch the game (not the Modding Kit) from Steam and make sure your module is selected in the Mods section of the Launcher, then hit “Play”. -* Create a new campaign or load a compatible save file to open the campaign map. Both of them will start a game. Notice that the code we have written adds the screen once the game starts (check the OnGameStart method). -* After you start the game by creating a new campaign, you should see this screen: +* 确保你已将项目构建到 Modules\YOUR_MODULE_NAME\bin\Win64_Shipping_Client。 +* 从 Steam 启动游戏(不是 Modding Kit),并确保在启动器的 Mods 部分选中了你的模组,然后点击"Play"。 +* 创建一个新战役或加载一个兼容的存档以打开战役地图。两者都会启动一场游戏。请注意,我们编写的代码会在游戏开始时添加该屏幕(查看 OnGameStart 方法)。 +* 在你通过创建新战役启动游戏后,你应该会看到这个屏幕: - \ No newline at end of file + diff --git a/docs/content/schinese/Asset Management/horse_reins_simulation_creation.md b/docs/content/schinese/Asset Management/horse_reins_simulation_creation.md index fa508905..56067ac4 100644 --- a/docs/content/schinese/Asset Management/horse_reins_simulation_creation.md +++ b/docs/content/schinese/Asset Management/horse_reins_simulation_creation.md @@ -1,61 +1,62 @@ +++ -title = "Horse Reins Simulation Creation" +title = "马缰绳模拟制作" weight = 15 +ai_translated = true +++ -### Introduction +### 简介 -This tutorial explains how to add simulation to the reins of a horse armor set. +本教程介绍如何为马铠套装的缰绳添加模拟效果。 -We previously used only one mesh for horse armor, however the reins would hang in the air and not move according to gravity. We then decided to add simulation to the reins which meant applying some changes to the system. Instead of a single mesh, horse armors now contain 3 meshes. We will divide them into 2 groups. +我们之前只为马铠使用一个网格,但缰绳会悬在空中,不会根据重力移动。因此我们决定为缰绳添加模拟效果,这意味着需要对系统进行一些调整。现在马铠不再是单一网格,而是包含 3 个网格。我们将它们分为 2 组。 -#### Group 1: +#### 第一组: -- **The horse armor/harness**: The armor set that is related to the body of the horse as demonstrated in Image 2b (which has its own simulation but we’ll ignore that for now) Example: horse_harness_x -- **The original rein piece**: The part that is separated from the initial single mesh that we have mentioned above and it is seen in Image 2c. We kept this unsimulated piece for occasions where the simulated piece is not needed; that is when the camera is distant from the horse and the armor set begins to switch to LOD 1 and to the rest of the LODs. Example: horse_harness_x_rein +- **马铠/挽具 (The horse armor/harness)**:与马身体相关的铠甲套装部分,如图 2b 所示(它有自己的模拟效果,但我们这里暂不讨论)。例如:horse_harness_x +- **原始缰绳部件 (The original rein piece)**:从上述最初的单一网格中分离出来的部分,如图 2c 所示。我们保留了这个未经模拟的部件,用于不需要模拟部件的场合;也就是当相机距离马匹较远,铠甲套装开始切换到 LOD 1 及后续其他 LOD 时使用。例如:horse_harness_x_rein -#### Group 2: +#### 第二组: -- **The simulated rein piece**: When the camera is close to the horse, the rider holds the reins and the reins move according to physics. Example: horse_harness_x_rein_rope +- **模拟缰绳部件 (The simulated rein piece)**:当相机靠近马匹时,骑手手持缰绳,缰绳会根据物理效果移动。例如:horse_harness_x_rein_rope -This tutorial mainly explains how to create the third mesh which is “the simulated rein piece”. But before diving into the steps, we would like to clarify a few things. +本教程主要讲解如何创建第三个网格,也就是"模拟缰绳部件"。但在深入讲解步骤之前,我们想先澄清几点。 | | | | ------ | ----------- | | | | -| **Image 1a**; *Normally each component has a different name but we will refer to the parts of our mesh either as headpiece or rein as shown in Image 1b.* | **Image 1b**; *For simplicity and due to functionality we will only use “head piece” and “reins”.* | +| **图 1a**;*通常每个组件都有不同的名称,但我们将把网格的各部分统称为头饰(headpiece)或缰绳(rein),如图 1b 所示。* | **图 1b**;*为简单起见,出于功能上的考虑,我们将只使用"头饰"和"缰绳"这两个名称。* | -We named the horse harness as “horse_harness_x” to serve as an example below (marked light grey) while explaining the grouping (those names are only chosen as examples, please mind that there are meshes with names “horse_harness_x, horse_harness_x_rein, horse_harness_x_rein_rope” in the game already). +我们以下文将马挽具命名为"horse_harness_x"作为示例(以浅灰色标记),以便解释分组方式(这些名称仅作为示例选用,请注意游戏中已存在名为"horse_harness_x、horse_harness_x_rein、horse_harness_x_rein_rope"的网格)。 - | | + | | ------- | ------- | -------- | | -**Image 2a**; *This is the initial stage where you model the horse harness/armor and rein according to horse anatomy. The rein should be modelled so that it is positioned within the rider’s reach (we have modelled the armor sets in 3ds Max).* | **Image 2b**; *horse_harness_x.* | **Image 2c**; *horse_harness_x_rein (headpiece is part of this mesh which will later be duplicated to become horse_harness_x_rein_rope).* +**图 2a**;*这是初始阶段,在此阶段您根据马的解剖结构为马挽具/铠甲和缰绳建模(缰绳的建模位置应在骑手可触及的范围内,我们使用了 3ds Max 为铠甲套装建模)。* | **图 2b**;*horse_harness_x。* | **图 2c**;*horse_harness_x_rein(头饰是该网格的一部分,之后将被复制以生成 horse_harness_x_rein_rope)。* -In the following chapter, we will talk about how to create the third component; “the simulated rein piece” of the armor set. +在接下来的章节中,我们将讲解如何创建第三个组件,即铠甲套装的"模拟缰绳部件"。 -### Rein Simulated Piece: Horse_harness_x_rein_rope +### 模拟缰绳部件:Horse_harness_x_rein_rope -The simulated piece needs another skeleton for skinning which is part of our Modding Kit, accessible under Mount & Blade II Bannerlord\modding_resources (see image 3). +模拟部件需要使用另一个骨骼进行蒙皮,该骨骼是我们 Modding Kit 的一部分,位于 Mount & Blade II Bannerlord\modding_resources 目录下(参见图 3)。 -**Image 3**; *horse_harness_rein_skeleton which contains 22 bones is on the left. On the right we have a demonstration of how the horse_harness_x_rein_rope is supposed to fit on the skeleton.* +**图 3**;*左侧为包含 22 根骨骼的 horse_harness_rein_skeleton。右侧展示了 horse_harness_x_rein_rope 应如何适配该骨骼。* -#### Steps to create the simulation mesh: -1. Duplicate the mesh “horse_harness_x_rein”. -2. Rename it to “horse_harness_x_rein_rope”. -3. Tweak the new mesh (“horse_harness_x_rein_rope”) so that it sits perfectly on the “horse_harness_rein_skeleton” (when you are done the mesh should look like it does on Image 5a and 5b). -4. Skin “horse_harness_x_rein_rope” according to “horse_harness_rein_skeleton”. Image 4 shows the bone list of the skeleton in question. -5. Set the alpha of vertices of the simulated region to “100”. Set the other non-simulated vertices to “0” (see Image 6). +#### 创建模拟网格的步骤: +1. 复制网格"horse_harness_x_rein"。 +2. 将其重命名为"horse_harness_x_rein_rope"。 +3. 调整新网格("horse_harness_x_rein_rope"),使其完美贴合"horse_harness_rein_skeleton"(完成后网格应如图 5a 和 5b 所示)。 +4. 根据"horse_harness_rein_skeleton"对"horse_harness_x_rein_rope"进行蒙皮。图 4 展示了所涉及骨骼的骨骼列表。 +5. 将模拟区域顶点的 alpha 值设置为"100"。将其他非模拟顶点设置为"0"(参见图 6)。 - | | | + | | | ------- | ------- | -------- | -------- | | | -**Image 4**; *bones of horse_harness_rein_skeleton.* | **Image 5a**; *side view of horse_harness_x_rein_rope compared to horse_harness_x_rein.* | **Image 5b**; *top view of horse_harness_x_rein_rope (selected mesh) compared to horse_harness_x_rein.* | **Image 6**; *alphas of the selected vertices (red/lighter) are set to “100” since they belong to the simulated region of the rein. The part where the rider holds and the head piece (see Image 1b) are not simulated, hence they are set to “0”.* +**图 4**;*horse_harness_rein_skeleton 的骨骼。* | **图 5a**;*horse_harness_x_rein_rope 与 horse_harness_x_rein 的侧视图对比。* | **图 5b**;*horse_harness_x_rein_rope(选中的网格)与 horse_harness_x_rein 的俯视图对比。* | **图 6**;*所选顶点(红色/较亮)的 alpha 值被设置为"100",因为它们属于缰绳的模拟区域。骑手手持的部分和头饰部分(参见图 1b)不进行模拟,因此将其设置为"0"。* -### Exporting the meshes to the game +### 将网格导出到游戏中 -Export the meshes in fbx format to the designated folder: +将网格以 fbx 格式导出到指定文件夹: [Game Folder]\Modules\[Mod Folder]\AssetSources diff --git a/docs/content/schinese/Asset Management/implementing_flora.md b/docs/content/schinese/Asset Management/implementing_flora.md index 273add1a..291de08c 100644 --- a/docs/content/schinese/Asset Management/implementing_flora.md +++ b/docs/content/schinese/Asset Management/implementing_flora.md @@ -1,132 +1,133 @@ +++ -title = "Implementing Flora" +title = "植被实现" weight = 15 +ai_translated = true +++ -Flora is one of the most important rendering aspects in game engines. It takes up a large portion of the overall rendering task when it comes to performance. While creating a new flora mesh one should make sure that the mesh has a low amount of polygon overdraw. +植被是游戏引擎中最重要的渲染方面之一。在性能方面,它占据了整体渲染任务的很大一部分。在创建新的植被网格时,应确保该网格具有较低的多边形过度绘制(overdraw)量。 -There is also a tradeoff between empty pixels in texture (which increases overdraw) and the triangle count of the mesh (which increases the polygon count cost). The optimum triangle count and the UV layout may change depending on the specific case. +在纹理中的空白像素(会增加过度绘制)和网格的三角形数量(会增加多边形数量成本)之间也存在权衡。最佳三角形数量和 UV 布局可能因具体情况而异。 -Flora meshes are optimized render objects designed to be drawn in large scale view distances with large amounts of instances. +植被网格是经过优化的渲染对象,设计用于在大范围的可视距离内以大量实例进行绘制。 -To be able to add, remove or fix flora assets, first you need to open the “Resource Browser”. +要能够添加、移除或修复植被资源,首先需要打开"资源浏览器(Resource Browser)"。 -In the Assets folder, right-click on an empty space and create a new folder within the resource browser. +在 Assets 文件夹中,在资源浏览器内的空白处右键单击并创建一个新文件夹。 -Open your newly created folder and Import all of your meshes and textures one at a time. +打开你新创建的文件夹,逐个导入你的所有网格和纹理。 -Once imported, to be able to create SDF Alpha from the diffuse texture, you will need to check "Generate SDF Alpha" on the “Texture inspector” panel that opens up on the right side of the screen when a texture file is selected, and click save on the same panel. +导入后,为了能够从漫反射纹理(diffuse texture)创建 SDF Alpha,你需要在选中纹理文件时屏幕右侧打开的"纹理检查器(Texture inspector)"面板中勾选"Generate SDF Alpha"(生成 SDF Alpha),然后在同一面板上点击保存。 {{% notice tip %}} -SDF Alpha is a technique that we use to improve vegetation alpha performance in our engine. If not applied, the embedded alpha channel of the texture will not be processed. +SDF Alpha 是我们引擎中用于改善植被 Alpha 性能的一种技术。如果不应用此技术,纹理中嵌入的 Alpha 通道将不会被处理。 {{% /notice %}} -To create a Flora Material, right click on an empty area in the Resource Browser, then click Create>Material and after that you can give a name to your material. +要创建植被材质(Flora Material),在资源浏览器的空白区域右键单击,然后点击 Create > Material(创建 > 材质),之后你可以为你的材质命名。 {{% notice tip %}} -If you want to use materials that already exist or were created by you in the editor for your newly imported meshes, you can rename the materials of your meshes in the 3d modelling program after the existing materials that you want to use in the editor. After the import, the editor assigns those materials to your meshes automatically. +如果你想为新导入的网格使用编辑器中已有的或你自己创建的材质,可以在 3D 建模软件中,将你网格的材质重命名为你想在编辑器中使用的现有材质的名称。导入后,编辑器会自动将这些材质分配给你的网格。 {{% /notice %}} {{% notice tip %}} -Before diving into “material settings”, please check [Material Editor]({{< ref "material_editor" >}}) for more information. +在深入了解"材质设置(material settings)"之前,请查看[材质编辑器(Material Editor)]({{< ref "material_editor" >}})以获取更多信息。 {{% /notice %}} -Click on the newly created material and select the shader that you want to use on the shader panel on the right. It is important to discern the type of shader you want to use, e.g. if our flora is grass, we need to select the grass shader, for trees and shrubs we select the flora_leaf shader. For the purpose of this documentation we have created grass as a flora and selected the grass_shader. +点击新创建的材质,并在右侧的着色器面板中选择你想使用的着色器。辨别你想使用的着色器类型很重要,例如,如果我们的植被是草,我们需要选择 grass 着色器;对于树木和灌木,我们选择 flora_leaf 着色器。在本文档中,我们创建的是草类植被,并选择了 grass_shader。 -After selecting the shader for flora we need to connect (define) our textures to the flora materials. To achieve this, you can search for the texture in the Textures Panel or just drag and drop it to the texture slots from the Resource Browser. The same procedure should be followed for SDF Alphas. +为植被选择好着色器后,我们需要将纹理连接(定义)到植被材质上。要实现这一点,你可以在纹理面板(Textures Panel)中搜索纹理,或者直接从资源浏览器将其拖放到纹理槽中。SDF Alpha 也应遵循相同的流程。 {{% notice warning %}} -Make sure to save your changes by pressing “save” at the bottom of the Material Inspector, otherwise materials return to their default settings. +请确保通过点击材质检查器(Material Inspector)底部的"save"(保存)按钮来保存你的更改,否则材质将恢复为默认设置。 {{% /notice %}} -Next we are going to check alpha_test and use_albedo_alpha flags. Do NOT check the use_specular flag for Grass shader in order not to adversely affect performance. +接下来我们要检查 alpha_test 和 use_albedo_alpha 标志。为了不对性能造成不利影响,请勿为 Grass 着色器勾选 use_specular 标志。 -Then we move on to the “Transparency” tab and choose “Factor” from the Alpha Blend Mode drop down list and give a value to be used as a cutoff value for the “Alpha Test”. For most cases, a value of 45 would be suitable. +然后我们转到"Transparency"(透明度)选项卡,从 Alpha Blend Mode(Alpha 混合模式)下拉列表中选择"Factor"(系数),并为"Alpha Test"(Alpha 测试)提供一个用作截止值的数值。在大多数情况下,45 的数值是合适的。 -For the last step of our material settings we check the “Two Sided” box under the “Others” segment and then save. +在材质设置的最后一步,我们勾选"Others"(其他)部分下的"Two Sided"(双面)框,然后保存。 , -Now that the material settings are done, after selecting the related mesh, we can search for the name of the material on the right side of the screen and apply it to the selected mesh and save. Or we can also select/drag/drop. We can then doubleclick on the mesh in the mesh editor and see if the material has been applied or not. +现在材质设置已经完成,选中相关网格后,我们可以在屏幕右侧搜索材质名称,并将其应用到选中的网格上然后保存。或者我们也可以选择/拖放来应用。然后我们可以在网格编辑器中双击该网格,查看材质是否已被应用。 -## Flora Kind Editor +## 植被种类编辑器(Flora Kind Editor) -The Flora Kind Editor is where we define and manage imported floras. +植被种类编辑器(Flora Kind Editor)是我们定义和管理已导入植被的地方。 -### Adding Resources to the Flora Kind Editor +### 向植被种类编辑器添加资源 -To be able to add the flora we created into scenes, we need to define it within the Flora Kind Editor. We can access it from Window>Module Data>Flora Editor. +为了能够将我们创建的植被添加到场景中,我们需要在植被种类编辑器中定义它。我们可以从 Window > Module Data > Flora Editor 访问它。 -Through the Flora Kind Editor we can: +通过植被种类编辑器,我们可以: -1. Access a list of flora that exist/about to be added into the editor. -2. Name/Rename flora items. -3. Define parameters of flora. -4. View Flora variations according to seasons. -5. Add flora and variations. -6. View mesh information along with viewing or changing body objects and materials. +1. 访问已存在/即将添加到编辑器中的植被列表。 +2. 命名/重命名植被项目。 +3. 定义植被的参数。 +4. 查看按季节划分的植被变体。 +5. 添加植被及其变体。 +6. 查看网格信息,以及查看或更改物理体对象(body objects)和材质。 -To add new flora we can click “Add New Flora” on the top left side and then change its name in the Flora Kind Name text field on the right side of the screen. +要添加新植被,我们可以点击左上方的"Add New Flora"(添加新植被),然后在屏幕右侧的 Flora Kind Name(植被种类名称)文本字段中更改其名称。 -We define properties of our flora in the properties section. We check the “grass” box if our flora acts as grass. For the flora to snap to flatland or slopes we check the “align with ground” and “align with slope” respectively. If we want our flora to disappear at a certain distance, we check the “fading out” box and fill the “view distance” field right above with the correct amount. In case of using grass, we check the “no shadow” box to maximise the performance. Otherwise we leave that box **unchecked** for evidently larger and more scarcely placed flora objects like trees and shrubbery. +我们在属性(properties)部分定义植被的属性。如果我们的植被是以草的形式存在,我们勾选"grass"(草)框。为了让植被贴合平地或斜坡,我们分别勾选"align with ground"(贴合地面)和"align with slope"(贴合斜坡)。如果我们希望植被在一定距离外消失,我们勾选"fading out"(淡出)框,并在其正上方的"view distance"(视距)字段中填入正确的数值。在使用草的情况下,我们勾选"no shadow"(无阴影)框以最大化性能。而对于明显更大且分布更稀疏的植被对象,如树木和灌木丛,则**不勾选**该框。 -Click on “Add Variation” that is placed under the Seasons thumbnails in order to add the flora mesh you prepared. Here you can add different flora versions for different seasons so that season-specific flora will be displayed automatically. You can also add multiple flora meshes and create more variety. +点击位于 Seasons(季节)缩略图下方的"Add Variation"(添加变体),以添加你准备好的植被网格。在这里,你可以为不同季节添加不同的植被版本,以便特定季节的植被会自动显示。你还可以添加多个植被网格以创造更多样性。 -Now that we are done adding our flora to the “Flora Kind Editor” with the desired parameters, the creation can be saved by clicking “Save Flora” or, in case of addition of multiple flora kinds, “Save All”. +现在我们已经完成了将植被及其所需参数添加到"植被种类编辑器"中的工作,可以通过点击"Save Flora"(保存植被)来保存该创建;如果添加了多个植被种类,则点击"Save All"(全部保存)。 -### Adding Flora to Scenes +### 将植被添加到场景中 -After importing your mesh into the game and entering it into the Flora Kind Editor, we can use the “Flora Paint” to paint our flora into a scene. First we can generate a terrain in our scene. To do so, we can pick the “Select Terrain” tool from the top menu bar and then click “Generate Terrain” on the window that pops up on the right hand side and click ok on the next window to finally generate a terrain. We take these steps solely to create a terrain so that we can then use the Flora Paint tool. +将你的网格导入游戏并输入到植被种类编辑器后,我们可以使用"Flora Paint"(植被绘制)工具将我们的植被绘制到场景中。首先我们可以在场景中生成地形。为此,我们可以从顶部菜单栏选择"Select Terrain"(选择地形)工具,然后在弹出的右侧窗口中点击"Generate Terrain"(生成地形),并在接下来的窗口中点击 ok,以最终生成地形。我们执行这些步骤仅仅是为了创建地形,以便我们随后可以使用植被绘制工具。 -After a terrain is created, we pick the “Flora Paint” tool from the top bar. We then type in the name of the flora that we previously defined within the Flora Kind Editor and apply it on the scene. +地形创建完成后,我们从顶部栏选择"Flora Paint"(植被绘制)工具。然后我们输入之前在植被种类编辑器中定义的植被名称,并将其应用到场景中。 -Another way of adding our flora onto the scene is by putting it into one of the layers we created for terrain painting. To do this we can pick the “Paint Terrain Layer” tool from the top menu bar. Then we add a new layer from the new window that opens up on the right hand side. +另一种向场景添加植被的方法是,将其放入我们为地形绘制创建的某个图层中。为此,我们可以从顶部菜单栏选择"Paint Terrain Layer"(绘制地形图层)工具。然后我们从右侧打开的新窗口中添加一个新图层。 -We double click on the new layer and open its properties menu. We then check the “Flora Layer” box and expand the “Flora Meshes” tab. +我们双击新图层并打开其属性菜单。然后我们勾选"Flora Layer"(植被图层)框并展开"Flora Meshes"(植被网格)选项卡。 -Checking the Flora Layer box will deactivate the textures that are used to paint the terrain, however, the flora that we added will still be visible. If we want to view both flora and the textures that we added to the layers at the same time, this box should be left unchecked. +勾选 Flora Layer(植被图层)框将停用用于绘制地形的纹理,但是我们添加的植被仍然可见。如果我们想同时查看植被和我们添加到图层中的纹理,则应保持该框不勾选。 -Under the “Flora Meshes” section, click on the dropdown menu next to “Flora” and select the Flora you have prepared, then paint an area of your terrain. +在"Flora Meshes"(植被网格)部分下,点击"Flora"(植被)旁边的下拉菜单,选择你准备好的植被,然后绘制你地形的某个区域。 - \ No newline at end of file + diff --git a/docs/content/schinese/Asset Management/weapon_smithing.md b/docs/content/schinese/Asset Management/weapon_smithing.md index 9646e1f7..24c10dbc 100644 --- a/docs/content/schinese/Asset Management/weapon_smithing.md +++ b/docs/content/schinese/Asset Management/weapon_smithing.md @@ -1,26 +1,27 @@ +++ -title = "Weapon Smithing & Crafting Pieces" +title = "武器锻造与制作部件" weight = 15 +ai_translated = true +++ -#### Introduction -The Smithing screen allows for the creation of all melee and throwing weapons in the game (swords, daggers, throwing knives, throwing axes, maces, polearms, pikes, javelins). +#### 简介 +锻造界面(Smithing screen)允许创建游戏中所有的近战和投掷武器(剑、匕首、飞刀、飞斧、钉锤、长柄武器、长枪、标枪)。 -Picture 1: Fine Steel Cavalry Broadsword being created on Smithing screen. +图1:在锻造界面上创建精钢骑兵阔剑。 -#### Adding Weapons to the Smithing System -To be able to create a weapon on the Smithing screen, all the individual weapon parts need to be exported to the game separately. You can find out how to export assets to the editor on [Asset Management]({{< ref "Asset Management" >}}). After the meshes are added to the editor, the mesh name and measurements specific to the added weapon part need to be put into the relevant XML document. Adding weapon parts is explained below by giving sword and dagger parts as examples (other weapon parts can be added to the editor using the same process). +#### 将武器添加到锻造系统 +要能够在锻造界面上创建武器,所有单独的武器部件都需要单独导出到游戏中。你可以在[资源管理(Asset Management)]({{< ref "Asset Management" >}})中了解如何将资源导出到编辑器。网格被添加到编辑器后,需要将网格名称以及该武器部件特有的尺寸信息填入相应的XML文档中。下面以剑和匕首的部件为例说明如何添加武器部件(其他武器部件也可以使用相同的流程添加到编辑器中)。 -#### Swords And Daggers -Five parts are needed to create a sword (similar to daggers). Those are the blade, guard, grip, pommel and optionally scabbard. All meshes’ pivot points need to be at the numeric centre of the object and the position of the object needs to be at the world origin (Picture 2, Picture 3). This way we can export all the parts in a single FBX file or export each part individually using separate FBX files. For example, we export all of the sword blades in a single FBX file. Other parts are also exported together to their respective FBX files (guards, grips, pommels, scabbards). (Picture 4) +#### 剑和匕首 +制作一把剑(与匕首类似)需要五个部件。它们分别是刀身(blade)、护手(guard)、握柄(grip)、剑柄头(pommel),以及可选的剑鞘(scabbard)。所有网格的轴心点(pivot point)都需要位于物体的数值中心,并且物体的位置需要位于世界原点(图2、图3)。这样我们就可以将所有部件导出到单个FBX文件中,或使用单独的FBX文件分别导出每个部件。例如,我们将所有的剑刀身导出到一个FBX文件中。其他部件也会一起导出到各自对应的FBX文件中(护手、握柄、剑柄头、剑鞘)。(图4) -Picture 2: Example, battania_grip_1 mesh in Blender viewport before exporting. +图2:示例,battania_grip_1网格在导出前于Blender视口中的样子。 -Picture 3: All weapon parts positioned neatly at the world origin. +图3:所有武器部件整齐地定位在世界原点处。 -Picture 4: Sword parts directory hierarchy. +图4:剑部件目录层级结构。 -#### CraftingPieces XmlNode Example +#### CraftingPieces XmlNode 示例 ``` @@ -55,40 +56,40 @@ Five parts are needed to create a sword (similar to daggers). Those are the blad ``` -##### CraftingPieces/CraftingPiece Node -When a crafting piece is created the following pieces of information should be defined. - -* **id**: Unique string id of the piece. Each piece must have a unique id to differ from other pieces. -* **name**: Name of the piece that will be shown to the players in the game. -* **piece_type**: References to the “CraftingPiece.PieceTypes”. PieceTypes are definitions that are used to label which part the piece belongs to. Each crafting piece is composed of different pieces. -* **mesh**: A unique mesh id is required to define the visual shape of the crafting piece. -* **weight**: Weight of the crafting piece in kilograms. -* **length**: Measured length of the piece in centimeters (Pivot point is always centered). -* **culture (optional)**: Defined culture of the current item. If an item is set for a culture, the item will only be sold on the markets of the same culture. -* **full_scale (optional)**: Defines scaling factors of the piece in dimensions. When set as "true" the piece should scale in all three dimensions. Setting it "false" scales in a single dimension which is the build axis. -* **appearance (optional)**: A value (price) calculation factor. -* **center_of_mass (optional)**: Center of mass percentage of the piece, normally 0.5 (in the middle). -* **tier (optional)**: Defaults as “1”. Tier defines the quality of the crafting piece. Tier helps setting the weapon tier and the crafting difficulty. -* **is_default (optional)**: When set as "true" the piece comes out unlocked for the crafting feature, if the piece is set as "false" the piece must be unlocked through crafting different weapons. -* **is_hidden (optional)**: When set as “true” the piece won’t show up on the crafting feature. Therefore it won’t be usable. When this variable is not set or set as “false” the crafting piece is available for the crafting feature. -* **item_holster_pos_shift (optional)**: Value given to this parameter sets position offset for the holster. -* **excluded_item_usage_features (optional)**: ":" separated values of item usage features which the piece cannot use. For example, when "thrust" is defined as an exclusion on a weapon piece. A weapon with that piece can not make thrust attacks. - -##### CraftingPieces/CraftingPiece/BuildData Node -* **piece_offset**: Given value sets distance adjustment for the piece from the origin of the weapon in centimeters. -* **next_piece_offset**: Given value sets the distance of the next piece in terms of centimeters. When a positive number is set, the distance to the next piece is closer. Negative values can be given to separate the pieces further apart. -* **previous_piece_offset**: Given value sets the distance of the previous piece in terms of centimeters. While the positive values bring pieces together, negative pieces set them further apart. - -##### CraftingPieces/CraftingPiece/Materials/Material Node -Material sets the required number of materials needed to craft the piece. Materials are also used in the smelting formula. Results of the smelting can not be more than material count and can not result in materials that are not listed in the material list. (Current formula in Bannerlord generates 1 lesser quality material of the highest material defined) Multiple materials can be set for specific items. A sword guard might require 3 counts of Iron2 and 1 count of Iron4. - -* **id**: References to the “CraftingMaterials”. CraftingMaterials are definitions used for pieces that generate a crafting piece when combined. -* **count**: Amount of material required to craft the piece. - -##### CraftingPieces/CraftingPiece/Flags/Flag Node -Flags are used for defining different properties that allow crafted items to have different features. There are two different variables when a flag needs to be set; - -**name**: References to the “ItemFlags” or “WeaponFlags”. +##### CraftingPieces/CraftingPiece 节点 +创建制作部件(crafting piece)时,需要定义以下信息。 + +* **id**:部件的唯一字符串ID。每个部件都必须拥有唯一的ID,以区别于其他部件。 +* **name**:该部件在游戏中向玩家显示的名称。 +* **piece_type**:引用"CraftingPiece.PieceTypes"。PieceTypes是用于标记该部件所属类别的定义。每个制作部件都由不同的部件组成。 +* **mesh**:需要一个唯一的网格ID来定义制作部件的视觉形状。 +* **weight**:制作部件的重量,单位为千克。 +* **length**:部件的测量长度,单位为厘米(轴心点始终位于中心)。 +* **culture(可选)**:当前物品所属的文化。如果为物品设置了文化,该物品将只会在相同文化的市场上出售。 +* **full_scale(可选)**:定义该部件在各维度上的缩放系数。设置为"true"时,部件会在所有三个维度上进行缩放。设置为"false"则只在单一维度(即构建轴)上缩放。 +* **appearance(可选)**:一个价值(价格)计算系数。 +* **center_of_mass(可选)**:部件的质心百分比,通常为0.5(即居中)。 +* **tier(可选)**:默认值为"1"。Tier定义了制作部件的品质。Tier有助于设定武器的等级和制作难度。 +* **is_default(可选)**:设置为"true"时,该部件在制作功能中默认处于解锁状态;如果设置为"false",则该部件必须通过制作不同的武器来解锁。 +* **is_hidden(可选)**:设置为"true"时,该部件不会出现在制作功能中,因此无法使用。当未设置该变量或将其设置为"false"时,该制作部件可用于制作功能。 +* **item_holster_pos_shift(可选)**:为该参数赋值可设置挂载位置(holster)的位置偏移。 +* **excluded_item_usage_features(可选)**:以":"分隔的值,表示该部件无法使用的物品使用特性(item usage features)。例如,当武器部件上定义了排除"thrust"(突刺)时,使用该部件的武器将无法进行突刺攻击。 + +##### CraftingPieces/CraftingPiece/BuildData 节点 +* **piece_offset**:给定的值以厘米为单位,设置该部件相对于武器原点的距离调整。 +* **next_piece_offset**:给定的值以厘米为单位,设置与下一个部件之间的距离。设置为正数时,与下一个部件的距离会更近。可以设置负值使部件进一步分离。 +* **previous_piece_offset**:给定的值以厘米为单位,设置与上一个部件之间的距离。正值会使部件靠拢,负值则会使部件进一步分离。 + +##### CraftingPieces/CraftingPiece/Materials/Material 节点 +Material用于设置制作该部件所需的材料数量。材料同时也用于熔炼公式(smelting formula)。熔炼的结果不能超过材料数量,也不能产生材料列表中未列出的材料。(Bannerlord中当前的公式会生成1个品质低于所定义最高品质材料的材料)可以为特定物品设置多种材料。例如,一个剑护手可能需要3个Iron2和1个Iron4。 + +* **id**:引用"CraftingMaterials"。CraftingMaterials是用于组合生成制作部件的材料定义。 +* **count**:制作该部件所需的材料数量。 + +##### CraftingPieces/CraftingPiece/Flags/Flag 节点 +Flags用于定义允许已制作物品拥有不同特性的各种属性。设置Flag时需要两个不同的变量; + +**name**:引用"ItemFlags"或"WeaponFlags"。 * ItemFlags * ForceAttachOffHandPrimaryItemBone @@ -149,9 +150,9 @@ Flags are used for defining different properties that allow crafted items to hav * AmmoBreakOnBounceBackMask * AmmoSticksWhenShot -**type**: “ItemFlags” or “WeaponFlags”. WeaponFlags is the default if omitted. +**type**:"ItemFlags"或"WeaponFlags"。如果省略,则默认为WeaponFlags。 -#### CraftingTemplates XmlNode Example +#### CraftingTemplates XmlNode 示例 ``` @@ -205,41 +206,41 @@ Flags are used for defining different properties that allow crafted items to hav ``` -##### CraftingTemplates/CraftingTemplate Node -When generating a crafting template the following values must be defined. +##### CraftingTemplates/CraftingTemplate 节点 +生成制作模板(crafting template)时必须定义以下值。 -* **id**: Unique string id of the template. Each template must have a unique id to differ from other templates. -* **item_modifier_group**: A reference to an item modifier group from item_modifier_groups.xml. +* **id**:模板的唯一字符串ID。每个模板都必须拥有唯一的ID,以区别于其他模板。 +* **item_modifier_group**:引用item_modifier_groups.xml中的一个物品修饰符组(item modifier group)。 -For example both two handed maces and maces fall under the mace category here. +例如,双手钉锤和单手钉锤在这里都属于钉锤(mace)类别。 item_modifier_group="mace" -* **item_holsters**: Defines where the item can be holstered. For items of multiple pieces common holsters will be used within the game. Piece types should be separated by ”:”. Separated references can be found from item_holsters.xml. -* **piece_type_to_scale_holster_with**: This defines the piece type to scale the holster mesh (if exists) with. As an example if the “Blade” is set for this parameter, the blade piece will be scaling the holster of the weapon. Other pieces will be disregarded. -* **hidden_piece_types_on_holster**: ":" separated values of “CraftingPiece.PieceTypes” to be hidden in the holster mesh. -* **default_item_holster_position_offset**: Default position offset for the holster. This is set in the format of "x,y,z". Applies to all weapons that are using the template. Further adjustment per piece can be applied from item_holster_pos_shift variable under a crafting piece. -* **use_weapon_as_holster_mesh**: When set as “true”, all weapons using the template will have itself as the holster mesh. The weapon itself will appear in place of the holster. -* **rotate_weapon_in_holster**: When set as “true”, all weapons using the template will be put in the opposite direction in the holster mesh. Useful for javelins to have their blades sticking out. -* **always_show_holster_with_weapon**: When set as “true”, the weapon mesh inside the holster mesh will not be hidden when the weapon is drawn. This feature is most useful for weapons with multiple stacks inside the holster such as quivers. +* **item_holsters**:定义该物品可以挂载(holster)的位置。对于由多个部件组成的物品,游戏中会使用通用的挂载点。部件类型之间应以":"分隔。可以在item_holsters.xml中找到可引用的分隔值。 +* **piece_type_to_scale_holster_with**:定义用于缩放挂载网格(如果存在)的部件类型。例如,如果此参数设置为"Blade",则刀身部件将用于缩放武器的挂载网格。其他部件将被忽略。 +* **hidden_piece_types_on_holster**:以":"分隔的"CraftingPiece.PieceTypes"值,表示在挂载网格中应隐藏的部件类型。 +* **default_item_holster_position_offset**:挂载点的默认位置偏移。格式为"x,y,z"。适用于所有使用该模板的武器。每个部件还可以通过制作部件下的item_holster_pos_shift变量进行进一步调整。 +* **use_weapon_as_holster_mesh**:设置为"true"时,所有使用该模板的武器都会以自身作为挂载网格。武器本身会出现在挂载位置。 +* **rotate_weapon_in_holster**:设置为"true"时,所有使用该模板的武器在挂载网格中会以相反方向放置。这对于需要刀身露出的标枪很有用。 +* **always_show_holster_with_weapon**:设置为"true"时,当武器被拔出时,挂载网格内的武器模型不会被隐藏。此特性对于箭袋等在挂载处有多层堆叠的武器最为有用。 -##### CraftingTemplates/CraftingTemplate/PieceDatas/PieceData Node -Defines which type of pieces can be used with the template and in which order they will be assembled. +##### CraftingTemplates/CraftingTemplate/PieceDatas/PieceData 节点 +定义可与该模板一起使用的部件类型及其组装顺序。 -* **piece_type**: References to the “CraftingPiece.PieceTypes”. -* **build_order**: In which order the piece is going to be built. All weapons are built around the handle pieces. Since all weapons must have handles, the order of a handle should be set to 0. Any piece which is on top of a handle should have incremental positive values and any piece which is on the other side of the handle should have incremental negative values. +* **piece_type**:引用"CraftingPiece.PieceTypes"。 +* **build_order**:部件的构建顺序。所有武器都是围绕握柄部件构建的。由于所有武器都必须拥有握柄,握柄的顺序应设置为0。位于握柄一侧的部件应使用递增的正值,位于握柄另一侧的部件应使用递减的负值。 -##### CraftingTemplates/CraftingTemplate/WeaponDescriptions/WeaponDescription Node -A WeaponDescription is simply the primary usage or one of the alternative usages of a weapon. They are defined in weapon_descriptions.xml and referenced in the template. +##### CraftingTemplates/CraftingTemplate/WeaponDescriptions/WeaponDescription 节点 +WeaponDescription即武器的主要用途或其中一种替代用途。它们在weapon_descriptions.xml中定义,并在模板中被引用。 -* **id**: Unique string id of the description. Each description must have a unique id to differ from other descriptions. +* **id**:描述的唯一字符串ID。每个描述都必须拥有唯一的ID,以区别于其他描述。 -##### CraftingTemplates/CraftingTemplate/StatsData Node -This is used for defining which basic stats for the weapon will be shown on the inventory or the crafting screen. +##### CraftingTemplates/CraftingTemplate/StatsData 节点 +用于定义将在库存界面或制作界面上显示的武器基础属性。 -* **weapon_description (optional)**: If specified, given data will be used only for the defined description instead of the template. When at least one StatsData node has this optional attribute defined, either all weapon descriptions referenced in the template must have their own StatsData entries or a default one must be provided before the specific one. +* **weapon_description(可选)**:如果指定,给定的数据将仅用于所定义的描述,而非整个模板。当至少有一个StatsData节点定义了此可选属性时,模板中引用的所有武器描述要么必须拥有各自的StatsData条目,要么必须在特定条目之前提供一个默认条目。 -An example is given below; +下面给出一个示例; -##### CraftingTemplates/CraftingTemplate/StatsData/StatData Node -* **stat_type**: References to the “CraftingTemplate.CraftingStatTypes”. Defines different characteristics of a weapon. -* **max_value**: Maximum value defines the upper limit a stat can have. +##### CraftingTemplates/CraftingTemplate/StatsData/StatData 节点 +* **stat_type**:引用"CraftingTemplate.CraftingStatTypes"。定义武器的不同特性。 +* **max_value**:最大值定义了某项属性可达到的上限。 -##### CraftingTemplates/CraftingTemplate/UsablePieces/UsablePiece Node -* **piece_id**: References to the “CraftingPiece.PieceTypes”. +##### CraftingTemplates/CraftingTemplate/UsablePieces/UsablePiece 节点 +* **piece_id**:引用"CraftingPiece.PieceTypes"。 -Example: In order to enable spear_blade_7 as a javelin part, it must be listed under the “javelin” id. The same piece must also be listed on the weapon_descriptions.xml under the related part. +示例:要将spear_blade_7启用为标枪(javelin)部件,必须将其列在"javelin" id下。同一部件也必须在weapon_descriptions.xml中列在相关部分下。 -#### WeaponDescriptions XmlNode Example +#### WeaponDescriptions XmlNode 示例 ``` @@ -287,32 +288,32 @@ Example: In order to enable spear_blade_7 as a javelin part, it must be listed u ``` -##### WeaponDescriptions/WeaponDescription Node -A **Weapon description** is used for defining different usages and features. Defined parts listed under the crafting templates nodes must also be listed under the weapon_descriptions.xml to be used. +##### WeaponDescriptions/WeaponDescription 节点 +**Weapon description(武器描述)**用于定义不同的用途和特性。在制作模板节点下列出的部件,也必须在weapon_descriptions.xml中列出才能使用。 -* **id**: Unique string id of the WeaponDescription. -* **weapon_class**: References to the “WeaponClass”. This defines which weapon type will be used by the weapon descriptions. -* **item_usage_features**: “:” separated values of item usage features which are available for the description. This is used for defining possible features (“_” separated pieces) of an item_usage_set (from item_usage_sets.xml). +* **id**:WeaponDescription的唯一字符串ID。 +* **weapon_class**:引用"WeaponClass"。定义该武器描述将使用哪种武器类型。 +* **item_usage_features**:以":"分隔的物品使用特性值,表示该描述可用的特性。这用于定义item_usage_set(来自item_usage_sets.xml)的可能特性(以"_"分隔的部件)。 -An example is listed below; +下面列出一个示例; item_usage_features="onehanded:block:shield:swing:thrust"> -* **rotated_in_hand**: When set as “true”, all weapons using the description will be held 180 degrees rotated in hand. A common use case for this is throwable polearms. -* **use_center_of_mass_as_hand_base**: When set as “true”, instead of the usual handle pivot, the weapon will be held from the calculated center of mass position. This is also used in throwable polearms. +* **rotated_in_hand**:设置为"true"时,所有使用该描述的武器在手中会旋转180度持握。此特性常用于可投掷的长柄武器。 +* **use_center_of_mass_as_hand_base**:设置为"true"时,武器将以计算出的质心位置持握,而不是通常的握柄轴心。这同样也用于可投掷的长柄武器。 -##### WeaponDescriptions/WeaponDescription/WeaponFlags/WeaponFlag Node -Default WeaponFlags used for all weapons for the description. +##### WeaponDescriptions/WeaponDescription/WeaponFlags/WeaponFlag 节点 +该描述下所有武器使用的默认WeaponFlags。 -* **value**: References to the “WeaponFlags”. +* **value**:引用"WeaponFlags"。 -##### WeaponDescriptions/WeaponDescription/AvailablePieces/AvailablePiece Node -List of available pieces. +##### WeaponDescriptions/WeaponDescription/AvailablePieces/AvailablePiece 节点 +可用部件列表。 -* **id**: A reference to a crafting piece. +* **id**:对制作部件的引用。 -#### Example: Adding crafting pieces to existing weapon templates via XML & XSLT -**Example case**: We have created 8 crafting pieces suitable for one handed swords with the following mesh names in the .fbx files: +#### 示例:通过XML和XSLT向现有武器模板添加制作部件 +**示例情况**:我们已经创建了8个适用于单手剑的制作部件,其在.fbx文件中的网格名称如下: * yourforumusername_blade_1 * yourforumusername_blade_2 @@ -323,24 +324,24 @@ List of available pieces. * yourforumusername_pommel_1 * yourforumusername_pommel_2 -We have also created 4 crafting pieces suitable for two handed swords: +我们还创建了4个适用于双手剑的制作部件: * yourforumusername_blade_3 * yourforumusername_guard_3 * yourforumusername_grip_3 * yourforumusername_pommel_3 -We **haven’t yet created our new module** which is why we launched the Mount & Blade II: Bannerlord Modding Kit, opened the Editor, clicked on File->Create New Module, gave our module a name **“OurModule”** and clicked “Create”. +我们**尚未创建自己的新模组**,因此我们启动了《骑马与砍杀2:领主》模组制作工具包(Modding Kit),打开编辑器(Editor),点击File->Create New Module,为我们的模组命名为**"OurModule"**,然后点击"Create"。 -We have then added **all of the meshes and materials** to our module with the help of the editor. This requires more than just adding the source files to the AssetSources\element folder. The files then need to be exported to the game via the Resource browser and the module published. +然后我们借助编辑器将**所有网格和材质**添加到了我们的模组中。这不仅仅是将源文件添加到AssetSources\element文件夹那么简单。这些文件还需要通过资源浏览器(Resource browser)导出到游戏中,并发布模组。 -Now, we want to do the necessary steps for these crafting pieces to **appear in-game**. We need to create a **new XML** file within our module: +现在,我们需要执行必要的步骤,使这些制作部件能够**在游戏中显示**。我们需要在模组中创建一个**新的XML**文件: * Modules\OurModule\ModuleData\Custom_crafting_pieces.xml -We also need to modify the native Crafting_templates.xml and Weapon_descriptions.xml via XSLT. That’s why we need to create these 2 files within our module: +我们还需要通过XSLT修改原生的Crafting_templates.xml和Weapon_descriptions.xml。因此我们需要在模组中创建以下这2个文件: * Modules\OurModule\ModuleData\Crafting_templates.xsl * Modules\OurModule\ModuleData\Weapon_descriptions.xsl @@ -348,7 +349,7 @@ We also need to modify the native Crafting_templates.xml and Weapon_descriptions ##### SubModule.xml -We also need to add the new XML & XSL files to our SubModule.xml: +我们还需要将新的XML和XSL文件添加到我们的SubModule.xml中: @@ -375,7 +376,7 @@ We also need to add the new XML & XSL files to our SubModule.xml: ##### Custom_crafting_pieces.xml -Within the **Custom_crafting_pieces.xml**, we’ll add the 12 crafting pieces. We’ll also define all of the required properties of these pieces as explained in this document above. +在**Custom_crafting_pieces.xml**中,我们将添加12个制作部件。我们还将按照本文档前面说明的方式,定义这些部件所需的所有属性。 ``` @@ -596,7 +597,7 @@ Within the **Custom_crafting_pieces.xml**, we’ll add the 12 crafting pieces. W ``` ##### Crafting_templates.xsl -Now, we need to add the crafting pieces to the **Crafting_templates.xsl**: +现在,我们需要将这些制作部件添加到**Crafting_templates.xsl**中: ``` @@ -635,10 +636,10 @@ Now, we need to add the crafting pieces to the **Crafting_templates.xsl**: ``` -The above XSLT code modifies the two native crafting templates “OneHandedSword” and “TwoHandedSword”. The use of XSLT is required in order to modify the existing templates. If we were to add a new template, for example “Firearms”, the use of XSLT wouldn’t be required. Instead, we could simply create a new custom_crafting_templates.xml and add the new template there. +上面的XSLT代码修改了两个原生制作模板"OneHandedSword"和"TwoHandedSword"。要修改现有模板,必须使用XSLT。如果我们要添加一个新模板,例如"Firearms",则不需要使用XSLT。相反,我们只需简单地创建一个新的custom_crafting_templates.xml并在其中添加新模板即可。 ##### Weapon_descriptions.xsl -We also need to modify the **Weapon_descriptions.xsl** with the following: +我们还需要按照以下内容修改**Weapon_descriptions.xsl**: ``` @@ -678,21 +679,7 @@ We also need to modify the **Weapon_descriptions.xsl** with the following: ``` -That’s it. Our crafting pieces will now show up on the crafting screen in-game. - -##### Example Mod Download -If you would like to download the example module presented above [click here](https://download3.taleworlds.com/OurModule.zip). - - - - - - - - - - - - - +就是这样。我们的制作部件现在将在游戏中的锻造界面上显示出来。 +##### 示例模组下载 +如果你想下载上文展示的示例模组,请[点击这里](https://download3.taleworlds.com/OurModule.zip)。 diff --git a/docs/content/schinese/Audio Modding/Adding Custom Sounds.md b/docs/content/schinese/Audio Modding/Adding Custom Sounds.md index cd62488f..b6113bf8 100644 --- a/docs/content/schinese/Audio Modding/Adding Custom Sounds.md +++ b/docs/content/schinese/Audio Modding/Adding Custom Sounds.md @@ -1,5 +1,5 @@ +++ -title = "给你的Mod添加音乐 (Outdated)" +title = "给你的Mod添加音乐 (已过时)" weight = 100 +++ diff --git a/docs/content/schinese/Audio Modding/_index.md b/docs/content/schinese/Audio Modding/_index.md index 6e3a5ae3..e8efc74b 100644 --- a/docs/content/schinese/Audio Modding/_index.md +++ b/docs/content/schinese/Audio Modding/_index.md @@ -1,5 +1,5 @@ +++ -title = "Audio Modding" +title = "音频 Mod 制作" description = "" weight = 5 +++ diff --git a/docs/content/schinese/Audio Modding/audio-modding-event-setup.md b/docs/content/schinese/Audio Modding/audio-modding-event-setup.md index 52b6a9b3..3f62b795 100644 --- a/docs/content/schinese/Audio Modding/audio-modding-event-setup.md +++ b/docs/content/schinese/Audio Modding/audio-modding-event-setup.md @@ -1,164 +1,165 @@ +++ -title = "Event Setup" +title = "事件设置" weight = 20 +ai_translated = true +++ -_Last updated: April 3, 2026_ +_最后更新:2026 年 4 月 3 日_ --- -## Parameters +## 参数 (Parameters) -Parameters in FMOD Studio are variables that control how an event behaves during playback. They can drive changes in volume, pitch, filters, instrument playback, or event logic — making sounds dynamic and responsive rather than static. +FMOD Studio 中的参数(Parameters)是控制事件在播放期间行为方式的变量。它们可以驱动音量、音高、滤波器、乐器播放或事件逻辑的变化——使声音变得动态且富有响应性,而不是一成不变。 -Each parameter has a name, a range of values, and a type. During gameplay, your code can set or adjust these values, or they can be driven automatically by game states, distance, velocity, or other inputs. +每个参数都有一个名称、一个取值范围和一个类型。在游戏运行期间,你的代码可以设置或调整这些值,它们也可以由游戏状态、距离、速度或其他输入自动驱动。 -Parameters are the main bridge between the game and the sound design. They let audio react directly to gameplay, giving you fine-grained, real-time control over how sound evolves. +参数是游戏与声音设计之间的主要桥梁。它们让音频能够直接对游戏玩法做出反应,使你能够对声音的演变方式进行精细的实时控制。 -You can use existing parameters or create your own presets. To view existing parameters, go to **Window > Preset Browser** or press **Ctrl+8** to open the Preset Browser. +你可以使用现有参数,也可以创建自己的预设。要查看现有参数,请转到 **Window > Preset Browser**,或按 **Ctrl+8** 打开预设浏览器(Preset Browser)。 -### Adding Parameters +### 添加参数 (Adding Parameters) -To add a custom parameter, click **New Parameter** or press **Ctrl+P**. This opens the **Add Parameter** dialog. +要添加自定义参数,点击 **New Parameter** 或按 **Ctrl+P**。这将打开**添加参数 (Add Parameter)** 对话框。 -| Field | Description | +| 字段 | 说明 | |---|---| -| **Parameter Type** | Defines what kind of values the parameter accepts (see types below) | -| **Parameter Name** | A unique, self-explanatory identifier | -| **Range** | Minimum and maximum values | -| **Labels** | Names for each label, if using a Labeled type | -| **Initial Value** | The default value when the event starts | -| **Parameter Scope** | Local (separate per instance) or Global (shared across all instances) | +| **参数类型 (Parameter Type)** | 定义该参数接受何种类型的值(见下方类型说明) | +| **参数名称 (Parameter Name)** | 唯一且含义明确的标识符 | +| **范围 (Range)** | 最小值与最大值 | +| **标签 (Labels)** | 若使用 Labeled 类型,为每个标签指定的名称 | +| **初始值 (Initial Value)** | 事件开始时的默认值 | +| **参数作用域 (Parameter Scope)** | Local(每个实例独立)或 Global(所有实例共享) | -**Parameter Types:** +**参数类型(Parameter Types):** -| Type | Description | +| 类型 | 说明 | |---|---| -| User: Continuous | Float values for smooth, gradual changes | -| User: Discrete | Integer values for stepped states | -| User: Labeled | String values for named categories | -| Built-in: Distance | Listener–emitter distance | -| Built-in: Distance (Normalized) | Distance scaled 0–1 by min/max | -| Built-in: Direction | Horizontal angle relative to listener facing | -| Built-in: Elevation | Vertical angle relative to listener | -| Built-in: Event Cone Angle | Emitter's facing direction relative to the listener | -| Built-in: Event Orientation | Difference in facing between listener and emitter | -| Built-in: Speed (Relative) | Emitter speed relative to listener | -| Built-in: Speed (Absolute) | World-space emitter speed | - -**Additional options in the dialog:** - -| Option | Description | +| User: Continuous | 浮点值,用于平滑、渐进的变化 | +| User: Discrete | 整数值,用于分级的状态 | +| User: Labeled | 字符串值,用于命名的分类 | +| Built-in: Distance | 监听者与发射器之间的距离 | +| Built-in: Distance (Normalized) | 根据最小/最大值将距离归一化到 0–1 | +| Built-in: Direction | 相对于监听者朝向的水平角度 | +| Built-in: Elevation | 相对于监听者的垂直角度 | +| Built-in: Event Cone Angle | 发射器朝向相对于监听者的方向 | +| Built-in: Event Orientation | 监听者与发射器朝向之间的差异 | +| Built-in: Speed (Relative) | 发射器相对于监听者的速度 | +| Built-in: Speed (Absolute) | 发射器在世界空间中的速度 | + +**对话框中的其他选项:** + +| 选项 | 说明 | |---|---| -| Exposed recursively via event instrument | Makes the parameter accessible through nested event instruments | -| Read-only | The parameter can be monitored but not modified | -| Hold value during playback | Local held parameters can only be set before an event starts or when it is stopped/paused. Global held parameters cannot be changed by the game at all. | +| Exposed recursively via event instrument | 使该参数可通过嵌套的事件乐器(event instrument)进行访问 | +| Read-only | 该参数可以被监视,但不能被修改 | +| Hold value during playback | Local 类型的保持参数只能在事件开始之前,或在事件停止/暂停时设置。Global 类型的保持参数则完全无法被游戏更改 | --- -### Global Parameters +### 全局参数 (Global Parameters) -Global parameters are project-wide variables that exist once, affect any event that references them, and can be read or modified from anywhere. +全局参数是项目范围内的变量,只存在一份,会影响任何引用它们的事件,并且可以从任何地方读取或修改。 -| Name | Type | Range / Default | Description | +| 名称 | 类型 | 范围 / 默认值 | 说明 | |---|---|---|---| -| ArenaIntensity | Discrete | 1–3, default: 1 | Number of people in the arena audience. **1** = Low, **2** = Medium, **3** = High | -| CampaignCameraHeight | Continuous | 0.0–1000.0, default: 0.0 | Camera distance above campaign terrain | -| Daytime | Continuous | 0.0–24.0, default: 12.0 | Time of day in 24-hour format | -| MissionCombatMode | Labeled | default: False | **True** = Scene is in combat, **False** = Scene is non-combat | -| MissionCulture | Labeled | default: None | Culture assigned to the scene: None, Aserai, Battania, Empire, Khuzait, Sturgia, Vlandia, Nord _(War Sails DLC)_, Outlaw, Reserved A, Reserved B | -| MissionProsperity | Labeled | default: None | Prosperity level: None _(e.g. Hideouts)_, Low, Medium, High | -| Rainfall | Continuous | 0.0–1.0, default: 0.0 | Rain presence and intensity. **0.0** = no rain | -| SceneType | Labeled | default: Exterior | **Exterior** = Outdoor scene, **Interior** = Indoor scene | -| Season | Labeled | default: Summer | Summer, Fall, Winter, Spring | -| SlowMotionMode | Labeled | default: False | **False** = Normal speed, **True** = Slow motion enabled | -| SoundPreset | Labeled | default: Speakers | Audio output profile: Speakers, Headphones, TV, Night Mode | -| WaveHeight | Continuous | −10.0–10.0, default: −10.0 | Vertical height of waves | -| WaveStrength | Continuous | 0.0–10.0, default: 0.0 | Intensity of wave motion | -| WindStrength | Continuous | 0.0–10.0, default: 0.0 | Intensity of wind | +| ArenaIntensity | Discrete | 1–3,默认值:1 | 竞技场观众的人数。**1** = 低,**2** = 中,**3** = 高 | +| CampaignCameraHeight | Continuous | 0.0–1000.0,默认值:0.0 | 摄像机相对于战役地图地形的高度 | +| Daytime | Continuous | 0.0–24.0,默认值:12.0 | 以 24 小时制表示的时间 | +| MissionCombatMode | Labeled | 默认值:False | **True** = 场景处于战斗状态,**False** = 场景处于非战斗状态 | +| MissionCulture | Labeled | 默认值:None | 分配给场景的文化:None、Aserai、Battania、Empire、Khuzait、Sturgia、Vlandia、Nord _(War Sails DLC)_、Outlaw、Reserved A、Reserved B | +| MissionProsperity | Labeled | 默认值:None | 繁荣度等级:None _(例如藏身处)_、Low、Medium、High | +| Rainfall | Continuous | 0.0–1.0,默认值:0.0 | 降雨的存在与强度。**0.0** = 无雨 | +| SceneType | Labeled | 默认值:Exterior | **Exterior** = 室外场景,**Interior** = 室内场景 | +| Season | Labeled | 默认值:Summer | Summer、Fall、Winter、Spring | +| SlowMotionMode | Labeled | 默认值:False | **False** = 正常速度,**True** = 启用慢动作 | +| SoundPreset | Labeled | 默认值:Speakers | 音频输出配置:Speakers、Headphones、TV、Night Mode | +| WaveHeight | Continuous | −10.0–10.0,默认值:−10.0 | 波浪的垂直高度 | +| WaveStrength | Continuous | 0.0–10.0,默认值:0.0 | 波浪运动的强度 | +| WindStrength | Continuous | 0.0–10.0,默认值:0.0 | 风力的强度 | --- -### Local Parameters +### 局部参数 (Local Parameters) -Local parameters belong to a specific event instance. Each instance keeps its own value and changes don't affect any other event. +局部参数属于某个特定的事件实例。每个实例都保有各自独立的值,其变化不会影响任何其他事件。 -| Name | Type | Range / Default | Description | +| 名称 | 类型 | 范围 / 默认值 | 说明 | |---|---|---|---| -| agent_state | Labeled | default: nothing | Awareness level of agents during stealth missions. **nothing** = unaware, **neutral** = briefly noticed, **cautious** = detected signs, **super_cautious** = actively searching, **alarmed** = located and alerted | -| Alert Distance | Built-in: Distance | 0.0–10.0 | Distance at which mission alerts trigger relative to the player | -| Armor Type | Continuous | 0.0–0.5, default: 0.0 | Armor worn by player/agent. **0.0–0.15** = Cloth, **0.15–0.25** = Leather, **0.25–0.35** = Chain mail, **0.35–0.5** = Plate mail | -| ArmySize | Continuous | 0.0–20.0, default: 0.0 | Size of an army on the campaign map | -| battle_size | Continuous | 0.0–4.0, default: 0.0 | Total troop count in a campaign map battle | -| Crowd Size | Continuous | 0.0–1000.0, default: 0.0 | Number of troops gathered at a location | -| Depth | Continuous | 0.0–1.0, default: 0.0 | Water depth | -| Direction | Built-in: Direction | −180.0–180.0 | Angle between listener facing and line to emitter. **0** = in front, **±90** = to the side, **±180** = behind | -| Distance Ambient 20 | Built-in: Distance | 0.0–50.0 | Distance of 3D ambient events within 50 m | -| Distance Campaign Node | Built-in: Distance | 0.0–30.0 | Distance of 3D campaign node events within 30 m | -| Distance Combat 500 | Built-in: Distance | 0.0–500.0 | Distance of combat sound events within 500 m | -| Distance Gallop 500 | Built-in: Distance | 0.0–500.0 | Distance of mount gallop events within 500 m | -| Distance Horse Walk 35 | Built-in: Distance | 0.0–35.0 | Distance of mount walking events within 35 m | -| Distance Human Walk 150 | Built-in: Distance | 0.0–150.0 | Distance of human walking events within 150 m | -| Distance Impact 75 | Built-in: Distance | 0.0–75.0 | Distance of impact events within 75 m | -| Distance Siege 500 | Built-in: Distance | 0.0–500.0 | Distance of siege events within 500 m | -| Distance Siege Med 250 | Built-in: Distance | 0.0–250.0 | Distance of siege events within 250 m | -| Distance Tavern Music | Built-in: Distance | 0.0–100.0 | Distance of tavern/street music events within 100 m | -| Distance Voice Long | Built-in: Distance | 0.0–500.0 | Distance of voice events within 500 m | -| Distance | Built-in: Distance | 0.0–80.0 | Generic distance parameter (default 80 m) | -| Event Cone Angle | Built-in: Event Cone Angle | 0.0–180.0 | How far the listener is from the emitter's forward direction. **0** = directly in front, **90** = to the side, **180** = directly behind | -| Event Orientation | Built-in: Event Orientation | −180.0–180.0 | Difference in facing between listener and emitter. **0** = same direction, **±90** = perpendicular, **±180** = opposite | -| Force | Continuous | 0.0–0.1, default: 0.57 | Instant physical force applied to an object | -| ForceContinuous | Continuous | 0.0–1.0, default: 0.0 | Continuous physical force applied to an object | -| impactModifier | Continuous | 0.0–0.6, default: 0.0 | Defensive block modifier. **0.0** = None, **0.1** = Active block, **0.2** = Chamber block, **0.3** = Crush through | -| isMissile | Continuous | 0.0–1.0, default: 0.0 | Whether the object is a projectile | -| isPlayer | Continuous | 0.0–1.0 | Whether the agent is the player. **0.0** = NPC, **1.0** = Player | -| Loop | Continuous | 0.0–1.0, default: 0.0 | Whether an event loops (music/video) | -| mpMusicSwitcher | Continuous | 0.0–1.0, default: 0.0 | Multiplayer state music. **0.0** = Main menu, **1.0** = Loading state | -| Occlusion | Continuous | 0.0–1.0, default: 0.0 | Degree of sound occlusion. **0.0** = None, **1.0** = Full | -| Size | Continuous | 0.0–1.0, default: 0.0 | Mass of an object (affects water collision sounds) | -| Speed | Built-in: Speed (Relative) | 0.0–10.0 | Relative speed of a game object | -| VibrationSend | Continuous | 0.0–1.0, default: 1.0 | Intensity of controller vibration | +| agent_state | Labeled | 默认值:nothing | 潜行任务中角色(agent)的警觉等级。**nothing** = 未察觉,**neutral** = 短暂注意到,**cautious** = 察觉到迹象,**super_cautious** = 正在主动搜索,**alarmed** = 已被定位并警觉 | +| Alert Distance | Built-in: Distance | 0.0–10.0 | 相对于玩家触发任务警报的距离 | +| Armor Type | Continuous | 0.0–0.5,默认值:0.0 | 玩家/角色所穿的护甲。**0.0–0.15** = 布甲,**0.15–0.25** = 皮甲,**0.25–0.35** = 锁子甲,**0.35–0.5** = 板甲 | +| ArmySize | Continuous | 0.0–20.0,默认值:0.0 | 战役地图上军队的规模 | +| battle_size | Continuous | 0.0–4.0,默认值:0.0 | 战役地图战斗中的总部队数量 | +| Crowd Size | Continuous | 0.0–1000.0,默认值:0.0 | 聚集在某地点的部队数量 | +| Depth | Continuous | 0.0–1.0,默认值:0.0 | 水深 | +| Direction | Built-in: Direction | −180.0–180.0 | 监听者朝向与指向发射器连线之间的夹角。**0** = 正前方,**±90** = 侧方,**±180** = 正后方 | +| Distance Ambient 20 | Built-in: Distance | 0.0–50.0 | 50 米范围内 3D 环境事件的距离 | +| Distance Campaign Node | Built-in: Distance | 0.0–30.0 | 30 米范围内 3D 战役节点事件的距离 | +| Distance Combat 500 | Built-in: Distance | 0.0–500.0 | 500 米范围内战斗声音事件的距离 | +| Distance Gallop 500 | Built-in: Distance | 0.0–500.0 | 500 米范围内坐骑疾驰事件的距离 | +| Distance Horse Walk 35 | Built-in: Distance | 0.0–35.0 | 35 米范围内坐骑行走事件的距离 | +| Distance Human Walk 150 | Built-in: Distance | 0.0–150.0 | 150 米范围内人类行走事件的距离 | +| Distance Impact 75 | Built-in: Distance | 0.0–75.0 | 75 米范围内撞击事件的距离 | +| Distance Siege 500 | Built-in: Distance | 0.0–500.0 | 500 米范围内攻城事件的距离 | +| Distance Siege Med 250 | Built-in: Distance | 0.0–250.0 | 250 米范围内攻城事件的距离 | +| Distance Tavern Music | Built-in: Distance | 0.0–100.0 | 100 米范围内酒馆/街头音乐事件的距离 | +| Distance Voice Long | Built-in: Distance | 0.0–500.0 | 500 米范围内语音事件的距离 | +| Distance | Built-in: Distance | 0.0–80.0 | 通用距离参数(默认 80 米) | +| Event Cone Angle | Built-in: Event Cone Angle | 0.0–180.0 | 监听者与发射器正前方向之间的偏离程度。**0** = 正前方,**90** = 侧方,**180** = 正后方 | +| Event Orientation | Built-in: Event Orientation | −180.0–180.0 | 监听者与发射器朝向之间的差异。**0** = 相同方向,**±90** = 垂直,**±180** = 相反方向 | +| Force | Continuous | 0.0–0.1,默认值:0.57 | 施加于物体的瞬时物理力 | +| ForceContinuous | Continuous | 0.0–1.0,默认值:0.0 | 施加于物体的持续性物理力 | +| impactModifier | Continuous | 0.0–0.6,默认值:0.0 | 防御格挡修正值。**0.0** = 无,**0.1** = 主动格挡,**0.2** = 完美格挡(Chamber block),**0.3** = 破防(Crush through) | +| isMissile | Continuous | 0.0–1.0,默认值:0.0 | 该物体是否为抛射物 | +| isPlayer | Continuous | 0.0–1.0 | 该角色是否为玩家。**0.0** = NPC,**1.0** = 玩家 | +| Loop | Continuous | 0.0–1.0,默认值:0.0 | 事件(音乐/视频)是否循环播放 | +| mpMusicSwitcher | Continuous | 0.0–1.0,默认值:0.0 | 多人游戏状态音乐。**0.0** = 主菜单,**1.0** = 加载状态 | +| Occlusion | Continuous | 0.0–1.0,默认值:0.0 | 声音遮挡的程度。**0.0** = 无遮挡,**1.0** = 完全遮挡 | +| Size | Continuous | 0.0–1.0,默认值:0.0 | 物体的质量(影响水面碰撞声音) | +| Speed | Built-in: Speed (Relative) | 0.0–10.0 | 游戏对象的相对速度 | +| VibrationSend | Continuous | 0.0–1.0,默认值:1.0 | 手柄震动的强度 | --- -### War Sails Parameters +### War Sails 参数 -These parameters only exist in the War Sails DLC module and are not available without it. +这些参数仅存在于 War Sails DLC 模块中,若未安装该 DLC 则不可用。 -| Name | Type | Range / Default | Description | +| 名称 | 类型 | 范围 / 默认值 | 说明 | |---|---|---|---| -| Campaign Ship Damage | Continuous | 0.0–1.0, default: 0.0 | Damage sustained by the player's ship on the campaign map | -| RowingPower | Continuous | 0.0–500.0, default: 0 | Collective force applied by oarsmen | -| RudderStress | Continuous | 0.0–1.0, default: 0.0 | Stress applied to the ship's rudder during maneuvering | -| SailRotation | Continuous | 0.0–1.0, default: 0.0 | Rotation speed of the ship's mast | -| ShipScrapingStatus | Labeled | default: NotScraping | **Scraping** = Ship is scraping, **NotScraping** = No scraping | -| ShipSpeed | Continuous | 0.0–1.0, default: 0.0 | Current speed of the ship | -| StormIntensity | Continuous | 0.0–2.0, default: 0.0 | Storm intensity on the campaign map. **0.0** = Storm, **1.0** = Thunderstorm, **2.0** = Hurricane | +| Campaign Ship Damage | Continuous | 0.0–1.0,默认值:0.0 | 战役地图上玩家船只所受到的损伤 | +| RowingPower | Continuous | 0.0–500.0,默认值:0 | 桨手施加的总合力 | +| RudderStress | Continuous | 0.0–1.0,默认值:0.0 | 船只在操纵时施加于舵上的应力 | +| SailRotation | Continuous | 0.0–1.0,默认值:0.0 | 船只桅杆的旋转速度 | +| ShipScrapingStatus | Labeled | 默认值:NotScraping | **Scraping** = 船只正在刮擦,**NotScraping** = 无刮擦 | +| ShipSpeed | Continuous | 0.0–1.0,默认值:0.0 | 船只当前的速度 | +| StormIntensity | Continuous | 0.0–2.0,默认值:0.0 | 战役地图上的暴风强度。**0.0** = 暴风雨,**1.0** = 雷暴,**2.0** = 飓风 | --- -## Effects Presets +## 效果预设 (Effects Presets) -Effect presets are pre-configured DSP setups that cover common use cases without manual configuration from scratch. Instead of building every effect chain yourself, you can apply a preset — such as a compressor, EQ, or reverb — that comes with sensible defaults designed for a specific purpose. +效果预设(Effect presets)是预先配置好的 DSP 设置,涵盖常见使用场景,无需从零手动配置。你无需自行搭建每一条效果链,而是可以直接应用一个预设——例如压缩器、均衡器或混响——该预设自带针对特定用途设计的合理默认值。 -Presets let you get immediate results and fine-tune from there. They speed up workflow, ensure consistency across the project, and give everyone a shared baseline for commonly used effects. You can also create your own custom presets, or modify the existing ones. +预设可以让你立即获得效果,并在此基础上进行微调。它们能加快工作流程、确保项目内的一致性,并为大家提供一个关于常用效果的共同基准。你也可以创建自己的自定义预设,或修改现有的预设。 -To browse presets, go to **Window > Effect Presets** or press **Ctrl+8**. In the Preset Browser, select the **Effects** tab to see all pre-configured presets currently used in **Mount & Blade II: Bannerlord**. +要浏览预设,请转到 **Window > Effect Presets** 或按 **Ctrl+8**。在预设浏览器(Preset Browser)中,选择 **Effects** 标签页,即可查看**《骑马与砍杀2:霸主》(Mount & Blade II: Bannerlord)** 中当前使用的所有预配置预设。 -When adding a new preset, you have these options: +添加新预设时,你有以下几个选项: -| Option | Description | +| 选项 | 说明 | |---|---| -| **New Effect** | Add a single DSP effect and configure it | -| **New Send** | Add and configure a bus send | -| **New Sidechain** | Add and configure a sidechain input | -| **New Effect Chain** | Build a chain of multiple DSP effects and configure them together | +| **New Effect** | 添加并配置单个 DSP 效果 | +| **New Send** | 添加并配置一个总线发送(bus send) | +| **New Sidechain** | 添加并配置一个侧链输入(sidechain input) | +| **New Effect Chain** | 构建由多个 DSP 效果组成的效果链,并统一进行配置 | -Once a preset is created, give it a unique, self-explanatory name so it can be easily identified and reused across the project. +创建预设后,请为其指定一个唯一且含义明确的名称,以便在项目中易于识别和复用。 -### Effects Preset List +### 效果预设列表 (Effects Preset List) -| Name | Type | Driving Parameter(s) | +| 名称 | 类型 | 驱动参数 | |---|---|---| | Alert Nod Spatializer | Spatializer | — | | Alert Spatializer | Spatializer | Alert Distance | @@ -235,53 +236,53 @@ Once a preset is created, give it a unique, self-explanatory name so it can be e --- -## Snapshots +## 快照 (Snapshots) -Snapshots let you control the overall mix dynamically based on game states. If you've ever seen a digital mixing console where pressing a button moves all the faders to new positions at once — that's exactly how FMOD snapshots work. +快照(Snapshots)让你能够根据游戏状态动态控制整体混音。如果你曾见过数字调音台上按下一个按钮就能让所有推子同时移动到新位置的场景——FMOD 快照的工作原理正是如此。 -### Adding Snapshots +### 添加快照 (Adding Snapshots) -To add a snapshot, open the Mixer window via **Window > Mixer** or press **Ctrl+2**. On the left side of the Mixer, switch to the **Snapshots** tab to see existing snapshots or create new ones. +要添加快照,请通过 **Window > Mixer** 或按 **Ctrl+2** 打开混音器窗口(Mixer window)。在混音器左侧,切换到 **Snapshots** 标签页,即可查看现有快照或创建新快照。 -Right-click on an empty space to create a new snapshot. You'll be asked to choose between two types: +在空白处右键单击以创建新快照。系统会要求你在两种类型中进行选择: -| Type | Description | +| 类型 | 说明 | |---|---| -| **Overriding Snapshot** | Takes full control of the affected mix properties, replacing existing values until released | -| **Blending Snapshot** | Layers its changes on top of the current mix, combining with other active snapshots for smoother transitions | +| **Overriding Snapshot** | 完全接管受影响的混音属性,替换现有值,直至被释放 | +| **Blending Snapshot** | 将其更改叠加到当前混音之上,与其他激活的快照相结合,实现更平滑的过渡 | -When multiple snapshots are active simultaneously, priority is determined by their position in the **Priority List**. Snapshots higher in the list take precedence over those below. For example, `GameMinimized` sits above `CampaignMap` in the priority list, meaning it overrides campaign map audio rules whenever the game is minimized. +当多个快照同时激活时,优先级由它们在**优先级列表 (Priority List)** 中的位置决定。列表中位置更高的快照优先于位置较低的快照。例如,`GameMinimized` 在优先级列表中位于 `CampaignMap` 之上,这意味着每当游戏被最小化时,它会覆盖战役地图的音频规则。 -When a snapshot is selected, the faders in the Mixer change color — this signals that any fader you adjust will only apply when that snapshot is active, not in the normal mix. The same applies to DSP effects and bus sends — for example, you can add a single algorithmic reverb to a return bus and adjust its properties per snapshot. +当选中某个快照时,混音器中的推子会改变颜色——这表示你所调整的任何推子仅会在该快照激活时生效,而不会影响正常混音。这同样适用于 DSP 效果和总线发送——例如,你可以在一个返回总线(return bus)上添加单个算法混响,并按快照调整其属性。 -In the `GameMinimized` snapshot, all faders are set to −∞ dB, so that whenever the player minimizes the game window, every sound is muted. Once the snapshot goes out of scope, the faders automatically return to their original positions. +在 `GameMinimized` 快照中,所有推子都被设置为 −∞ dB,因此每当玩家最小化游戏窗口时,所有声音都会被静音。一旦该快照失效,推子会自动恢复到其原始位置。 -### Snapshot Events +### 快照事件 (Snapshot Events) -Snapshots can be triggered by code, but they can also be triggered by events — which is especially useful for reverb zones in a scene. For more on reverb zones, see the [Scene Audio]({{< ref "audio-modding-scene-audio.md" >}}) page. +快照可以由代码触发,但也可以由事件触发——这对场景中的混响区域尤其有用。有关混响区域的更多信息,请参阅[场景音频]({{< ref "audio-modding-scene-audio.md" >}})页面。 -To add a snapshot event, first create a **timeline event** (snapshot instruments cannot be placed in action events). Give the event a clear, descriptive name. +要添加快照事件,首先创建一个**时间轴事件 (timeline event)**(快照乐器无法放置在 action 事件中)。为该事件指定一个清晰、描述性的名称。 -Right-click the track in the timeline where you want to place the snapshot instrument. If a snapshot already exists you'll see it listed; otherwise you can create a new one. For reverb control, always use **blending snapshots**. +在你想要放置快照乐器的时间轴轨道上右键单击。如果已存在快照,你将看到其列在列表中;否则你可以创建一个新快照。对于混响控制,请始终使用**混合式快照 (blending snapshots)**。 -Once placed, the snapshot instrument appears on the track. You can drag the left and right edges of the instrument to add fade-in and fade-out handles, which smooth the transition into and out of the snapshot. +放置完成后,快照乐器会出现在该轨道上。你可以拖动该乐器的左右边缘来添加淡入和淡出控制柄,从而使进入和退出快照的过渡更加平滑。 --- -## User Properties +## 用户属性 (User Properties) -Events in FMOD Studio can carry **User Properties** — custom variables you define to pass extra information to the game. These act as metadata markers, letting the game code check for them and apply special handling when needed. +FMOD Studio 中的事件可以携带**用户属性 (User Properties)**——由你自定义的变量,用于向游戏传递额外信息。这些属性充当元数据标记,让游戏代码可以检测它们并在需要时应用特殊处理。 -Every User Property has a name and a value. The name is always a string (letters and/or numbers). The value is interpreted automatically: if it's purely numeric, it's treated as a floating-point number; if it contains any non-numeric characters, it's treated as a string. +每个用户属性都有一个名称和一个值。名称始终是字符串(字母和/或数字)。值会被自动解析:如果它纯粹是数字,则被视为浮点数;如果包含任何非数字字符,则被视为字符串。 -This system lets sound designers embed flexible, game-relevant data directly inside events, reducing the need for programmers to hard-code rules. User Properties are defined in the event's deck area in FMOD Studio — each row has a name field and a value field. +这一系统让音效设计师可以直接在事件内部嵌入灵活的、与游戏相关的数据,从而减少程序员硬编码规则的需求。用户属性在 FMOD Studio 中事件的卡片区域(deck area)内定义——每一行都有一个名称字段和一个值字段。 -| Property | Description | +| 属性 | 说明 | |---|---| -| **isQuad** | Used for ambient sounds. When set to `True`, the system will use the quadraphonic version of the ambient instead of the stereo fallback. A matching quad setup must exist before enabling this. See [Quadraphonic Ambients]({{< ref "audio-modding-scene-audio.md#quadraphonic-ambients" >}}). | -| **Pausable** | Used by the event-based pausing system. Default is `True`. Set to `False` for persistent events such as ambiences or music that should not be paused. | -| **priorityMultiplier** | Adjusts the relative priority of an event within the priority system — raising or lowering its likelihood of being culled. See [Priority System]({{< ref "audio-modding-systems.md#priority-system" >}}). | -| **maxLength** | Prevents build errors for timeline events without a timeline or instrument. Defines a duration so FMOD has the necessary length data without a timeline track. Not needed for Action events. | -| **battle_ambient_group_id** | Assigns an event to a specific group in the Battle Ambient Sound System (BASS), allowing events to be managed and optimized collectively. See [Battle Ambient Sound System]({{< ref "audio-modding-systems.md#battle-ambient-sound-system" >}}). | -| **customMaxDistance** | Overrides the default maximum audible distance of a 3D event. | -| **ignoreMaxDistance** | Ignores the maximum distance restriction of a 3D event. Accepts `0` (False) or `1` (True). | +| **isQuad** | 用于环境声音。设为 `True` 时,系统将使用该环境音的四声道版本,而不是立体声回退版本。启用此项前必须已存在匹配的四声道设置。参见[四声道环境音]({{< ref "audio-modding-scene-audio.md#quadraphonic-ambients" >}})。 | +| **Pausable** | 由基于事件的暂停系统使用。默认值为 `True`。对于不应被暂停的持续性事件(如环境音或音乐),应设为 `False`。 | +| **priorityMultiplier** | 调整某个事件在优先级系统中的相对优先级——提高或降低其被剔除(cull)的可能性。参见[优先级系统]({{< ref "audio-modding-systems.md#priority-system" >}})。 | +| **maxLength** | 防止没有时间轴或乐器的时间轴事件产生构建错误。为 FMOD 定义一个时长,使其在没有时间轴轨道的情况下也拥有必要的长度数据。Action 事件无需此项。 | +| **battle_ambient_group_id** | 将某个事件分配到战斗环境声音系统(Battle Ambient Sound System,BASS)中的特定分组,从而可以对事件进行集中管理和优化。参见[战斗环境声音系统]({{< ref "audio-modding-systems.md#battle-ambient-sound-system" >}})。 | +| **customMaxDistance** | 覆盖某个 3D 事件的默认最大可听距离。 | +| **ignoreMaxDistance** | 忽略某个 3D 事件的最大距离限制。接受 `0`(False)或 `1`(True)。 | diff --git a/docs/content/schinese/Audio Modding/audio-modding-overview.md b/docs/content/schinese/Audio Modding/audio-modding-overview.md index 1c1e56a6..53438e98 100644 --- a/docs/content/schinese/Audio Modding/audio-modding-overview.md +++ b/docs/content/schinese/Audio Modding/audio-modding-overview.md @@ -1,43 +1,44 @@ +++ -title = "Audio Modding with FMOD Studio" +title = "使用 FMOD Studio 进行音频模组制作" weight = 10 +ai_translated = true +++ -_Last updated: April 3, 2026_ +_最后更新:2026 年 4 月 3 日_ --- -## Introduction +## 简介 -This guide is not a replacement for the official FMOD Studio manual. If you're completely new to FMOD Studio or audio middleware in general, we recommend starting with the official documentation on FMOD's website before diving in here. +本指南并不是官方 FMOD Studio 手册的替代品。如果你完全不熟悉 FMOD Studio 或音频中间件,我们建议你在深入阅读本指南之前,先从 FMOD 官方网站上的官方文档开始学习。 -The purpose of this guide is to give you an up-to-date, Bannerlord-specific reference that helps you work efficiently with FMOD. It focuses on workflows, best practices, and performance considerations that are unique to **Mount & Blade II: Bannerlord**. +本指南的目的是为你提供一份最新的、针对 Bannerlord 的专用参考资料,帮助你高效地使用 FMOD 进行工作。它重点关注 **Mount & Blade II: Bannerlord** 特有的工作流程、最佳实践和性能方面的考量。 -With direct FMOD Studio support, modders now have access to nearly all of the tools used internally by the game's audio team. That means you can: +借助对 FMOD Studio 的直接支持,模组制作者现在几乎可以使用游戏音频团队内部使用的所有工具。这意味着你可以: -- Add and configure events -- Create instruments and layers -- Apply automations and modulations -- Build and manage soundbanks -- Add or re-route busses -- Create and tune snapshots -- Define or modify parameters -- Insert DSP effects -- Implement or modify controller vibrations +- 添加和配置事件(events) +- 创建乐器(instruments)和图层(layers) +- 应用自动化(automations)和调制(modulations) +- 构建和管理音效库(soundbanks) +- 添加或重新路由总线(busses) +- 创建和调整快照(snapshots) +- 定义或修改参数(parameters) +- 插入 DSP 效果 +- 实现或修改控制器震动 -**Mount & Blade II: Bannerlord** is a performance-critical title. Every change you make in FMOD Studio is reflected in real time inside the game, and a poorly optimized setup can hurt both audio quality and overall performance. Because of this, treat optimization as part of your workflow — not something to deal with at the end. +**Mount & Blade II: Bannerlord** 是一款对性能要求极高的游戏。你在 FMOD Studio 中所做的每一项更改都会实时反映在游戏中,而糟糕的优化设置既会损害音质,也会影响整体性能。因此,请将优化视为工作流程的一部分——而不是留到最后才处理的事情。 -A dedicated section of this guide covers performance optimization guidelines. We strongly encourage you to read it before finalizing any FMOD modifications. Following those practices will help you avoid common pitfalls like excessive voice counts, unnecessary DSP load, or inefficient streaming setups. +本指南有专门的一节介绍性能优化指南。我们强烈建议你在完成任何 FMOD 修改之前先阅读该部分内容。遵循这些做法将有助于你避免常见的陷阱,例如过多的声音数量(voice counts)、不必要的 DSP 负载,或低效的流式传输(streaming)设置。 --- -## Getting Started +## 快速入门 -Before anything shows up in-game, your mod needs to be wired up so that Bannerlord knows where to find your sound data. This involves two steps: registering the required data files in your `.mbproj` file, and generating those files using the FMOD Studio script provided. +在任何内容出现在游戏中之前,你的模组需要先进行相应配置,以便 Bannerlord 知道去哪里查找你的声音数据。这涉及两个步骤:在你的 `.mbproj` 文件中注册所需的数据文件,以及使用所提供的 FMOD Studio 脚本生成这些文件。 -### 1. Register Sound Files in Your .mbproj +### 1. 在你的 .mbproj 中注册声音文件 -Add the following lines to your mod's `.mbproj` file, inside the `base` scope: +在你的模组的 `.mbproj` 文件的 `base` 作用域内添加以下几行: ```xml @@ -45,44 +46,45 @@ Add the following lines to your mod's `.mbproj` file, inside the `base` scope: ``` -The `name` field specifies the XML file path relative to your mod's directory. The `id` and `type` fields must be kept exactly as shown. +`name` 字段指定了相对于你的模组目录的 XML 文件路径。`id` 和 `type` 字段必须保持与示例中完全一致。 -### 2. Generate the Data Files +### 2. 生成数据文件 -All three XML files — along with the associated sound banks — are generated by the **SEDFGen.js** script included with the project. To run it, use the scripting interface inside FMOD Studio: go to **Scripts > Taleworlds**. +这三个 XML 文件——以及相关联的音效库(sound banks)——都是由项目中附带的 **SEDFGen.js** 脚本生成的。要运行它,请使用 FMOD Studio 内部的脚本接口:前往 **Scripts > Taleworlds**。 -The script outputs: +该脚本会输出: -- XML data files to `ExampleSoundMod/ModuleData/` -- Sound bank files to `ExampleSoundMod/Sounds/` +- XML 数据文件至 `ExampleSoundMod/ModuleData/` +- 音效库文件至 `ExampleSoundMod/Sounds/` -An example directory structure with all required files is provided for reference. +提供了一个包含所有必需文件的示例目录结构供参考。 -### Important: Do Not Include main.bank +### 重要提示:不要包含 main.bank -In `soundfiles.xml`, `main.bank` is intentionally left out. Do **not** add your own `main.bank`. Including it can cause issues such as: +在 `soundfiles.xml` 中,`main.bank` 被有意排除在外。**请勿**添加你自己的 `main.bank`。包含它可能会导致以下问题: -- Volume sliders not working correctly -- Sounds not being routed to buses as expected +- 音量滑块无法正常工作 +- 声音未按预期路由到对应的总线(buses) -You **can** add your own VCAs and buses, as long as you do not modify any of the existing buses and VCAs provided by the base game. +只要你不修改基础游戏提供的任何现有总线和 VCA,你**可以**添加自己的 VCA 和总线。 -### Overriding Existing Sound Events +### 覆盖现有声音事件 -To override a sound event that already exists in the game, your event must match the original **exactly** — including the full event path, not just the event name. +要覆盖游戏中已经存在的声音事件,你的事件必须与原始事件**完全**匹配——包括完整的事件路径,而不仅仅是事件名称。 -For example, to override `event:/mission/combat/sword_hit`, your event must use that exact path. +例如,要覆盖 `event:/mission/combat/sword_hit`,你的事件必须使用那个确切的路径。 -### Mod Load Order +### 模组加载顺序 -If multiple sound mods are active at the same time and any of them define events with identical paths, the **mod loaded last takes priority**. Keep this in mind when publishing your mod or when testing alongside other audio mods. +如果同时启用了多个音频模组,并且其中任何模组定义了具有相同路径的事件,则**最后加载的模组将具有优先权**。在发布你的模组或与其他音频模组一起测试时,请牢记这一点。 --- -## Guide Structure +## 指南结构 -This guide is split into the following pages: +本指南分为以下几个页面: -- **[Event Setup]({{< ref "audio-modding-event-setup.md" >}})** — Parameters, effects presets, snapshots, and user properties -- **[Scene Audio]({{< ref "audio-modding-scene-audio.md" >}})** — Placing sounds in scenes, reverb zones, animation and particle audio, quadraphonic ambients -- **[Audio Systems & Optimization]({{< ref "audio-modding-systems.md" >}})** — Voice system, physics materials, priority system, battle ambient sound system, and performance guidelines +- **[事件设置(Event Setup)]({{< ref "audio-modding-event-setup.md" >}})** — 参数、效果预设、快照和用户属性 +- **[场景音频(Scene Audio)]({{< ref "audio-modding-scene-audio.md" >}})** — 在场景中放置声音、混响区域(reverb zones)、动画与粒子音频、四声道环境音 +- **[音频系统与优化(Audio Systems & Optimization)]({{< ref "audio-modding-systems.md" >}})** — 声音系统(voice system)、物理材质、优先级系统、战斗环境音系统,以及性能指南 + diff --git a/docs/content/schinese/Audio Modding/audio-modding-scene-audio.md b/docs/content/schinese/Audio Modding/audio-modding-scene-audio.md index 7bc91f74..b6b7e5f6 100644 --- a/docs/content/schinese/Audio Modding/audio-modding-scene-audio.md +++ b/docs/content/schinese/Audio Modding/audio-modding-scene-audio.md @@ -1,52 +1,53 @@ +++ -title = "Scene Audio" +title = "场景音频" weight = 30 +ai_translated = true +++ -_Last updated: April 3, 2026_ +_最后更新:2026 年 4 月 3 日_ --- -## Adding Sound Entities +## 添加声音实体 (Adding Sound Entities) -In our proprietary game engine, placing sounds into a scene is straightforward. Start by creating an **empty entity** in the scene. +在我们的专有游戏引擎中,将声音放入场景非常简单。首先在场景中创建一个**空实体 (empty entity)**。 -Once the entity is added, select it in the scene hierarchy to open the **Inspector Window**. If the Inspector doesn't appear, enable it through **Window > Inspector Window**. +添加实体后,在场景层级结构中选中它以打开**检查器窗口 (Inspector Window)**。如果检查器未显示,可通过 **Window > Inspector Window** 启用它。 -In the Inspector, expand the **Scripts** dropdown and choose **Add New Script**. From the dialog, select **AmbientSoundEmitter** to attach a sound emitter script to the entity. +在检查器中,展开 **Scripts** 下拉菜单并选择 **Add New Script**。在弹出的对话框中,选择 **AmbientSoundEmitter** 以将声音发射器脚本附加到该实体上。 -The script exposes several options for controlling playback: +该脚本提供了若干用于控制播放的选项: -| Property | Description | +| 属性 | 说明 | |---|---| -| **Event Path** | The FMOD event path for the sound to be played in the scene | -| **Play On Startup** | If enabled, the sound plays automatically when the scene loads. Useful for ambiences or persistent sounds | -| **Is Static** | Marks the emitter as fixed in place. Static emitters are cheaper to process since the engine doesn't need to track their position dynamically | -| **Override Sound** | Enables overrides for certain FMOD parameters specifically for 3D sound events | -| **Override Volume Multiplier** | Adjusts playback volume by a multiplier. Use commas (`,`) instead of periods (`.`) for decimal values | -| **Override Max Distance** | Sets a custom maximum audible distance for the event | -| **Override Min Distance** | Sets a custom minimum audible distance for the event | -| **Is Master Sound** | Tags the emitter as a master sound, used for global mix behaviors | -| **Is Master Suppressor** | When active inside a trigger volume, ducks (reduces) any sounds tagged as master sound | -| **Is Triggered** | Configures the emitter as a trigger volume, only playing when the listener enters the defined space | -| **Trigger Shape** | Defines the shape of the trigger volume (box or sphere) | +| **Event Path** | 要在场景中播放的声音的 FMOD 事件路径 | +| **Play On Startup** | 若启用,场景加载时声音会自动播放。适用于环境音或持续性声音 | +| **Is Static** | 将该发射器标记为固定不动。静态发射器处理成本更低,因为引擎无需动态追踪其位置 | +| **Override Sound** | 为特定的 3D 声音事件启用对某些 FMOD 参数的覆盖 | +| **Override Volume Multiplier** | 通过一个乘数调整播放音量。小数值请使用逗号(`,`)而非句点(`.`) | +| **Override Max Distance** | 为该事件设置自定义的最大可听距离 | +| **Override Min Distance** | 为该事件设置自定义的最小可听距离 | +| **Is Master Sound** | 将该发射器标记为主声音(master sound),用于全局混音行为 | +| **Is Master Suppressor** | 当在触发体积内激活时,压低(降低)所有被标记为主声音的声音 | +| **Is Triggered** | 将发射器配置为触发体积,仅当监听者进入定义的空间时才播放 | +| **Trigger Shape** | 定义触发体积的形状(box 或 sphere) | --- -## Reverb Zones +## 混响区域 (Reverb Zones) -The same process applies when adding reverb zones to a scene. In FMOD, reverbs are snapshot events that can be triggered through trigger volumes, just like standard sound events. +向场景添加混响区域的流程是一样的。在 FMOD 中,混响是可以像标准声音事件一样通过触发体积触发的快照事件(snapshot events)。 -To set one up: +设置步骤如下: -1. Create a new entity in the scene -2. Attach an **AmbientSoundEmitter** script -3. Enter the path to the reverb snapshot event -4. Enable **Is Triggered** -5. Select the appropriate trigger shape -6. Resize the volume using the transform tools to cover the desired area +1. 在场景中创建一个新实体 +2. 附加一个 **AmbientSoundEmitter** 脚本 +3. 输入混响快照事件的路径 +4. 启用 **Is Triggered** +5. 选择合适的触发形状 +6. 使用变换工具调整体积大小,以覆盖所需区域 -The following snapshot event paths are available out of the box. You're also free to create and add your own snapshots and snapshot events. +以下快照事件路径是开箱即用的。你也可以自由创建和添加自己的快照及快照事件。 - `event:/mission/ambient/reverb/alley` - `event:/mission/ambient/reverb/caves` @@ -62,54 +63,54 @@ The following snapshot event paths are available out of the box. You're also fre --- -## Paths +## 路径 (Paths) -Paths are routes you can place in a scene for entities to follow. This is useful when you want a sound emitter to move along a defined trajectory relative to the listener — for example, to simulate a river flowing past. +路径是你可以放置在场景中供实体跟随的路线。当你希望声音发射器沿着相对于监听者定义的轨迹移动时非常有用——例如,模拟河流流淌而过的效果。 -### Creating a Path +### 创建路径 -1. Click **Add New Path** on the taskbar -2. Assign a name to the path -3. Click **Add Component** -4. Place path points in the scene — they will automatically be connected in order +1. 在任务栏上点击 **Add New Path** +2. 为路径指定名称 +3. 点击 **Add Component** +4. 在场景中放置路径点——它们会按顺序自动连接 -To attach a sound emitter to a path, select the sound emitter entity, go to the **Scripts** tab, click **Add New Script**, and add the **path_converger** script. This enables the entity to follow the defined path. +要将声音发射器附加到路径上,请选中声音发射器实体,转到 **Scripts** 标签页,点击 **Add New Script**,然后添加 **path_converger** 脚本。这将使该实体能够沿着定义的路径移动。 -The **path_converger** script exposes a few options: +**path_converger** 脚本提供了几个选项: -| Property | Description | +| 属性 | 说明 | |---|---| -| **Path Name** | The name of the path the emitter should follow. Must exactly match the path you created | -| **Rotate To Camera** | If enabled, the emitter rotates to face the listener's camera as it moves along the path | -| **Apply Scale** | Determines whether the emitter inherits scaling transformations from the path | +| **Path Name** | 发射器应跟随的路径名称。必须与你创建的路径名称完全一致 | +| **Rotate To Camera** | 若启用,发射器在沿路径移动时会面向监听者的摄像机旋转 | +| **Apply Scale** | 决定发射器是否继承路径的缩放变换 | --- -## Modifying Emitter Transforms +## 修改发射器变换 (Modifying Emitter Transforms) -To see a sound emitter's trigger volume shape and its min/max distance spheres, you need to enable **Sound Entities** visibility. If the **Visibility** tab isn't visible, open it via **Window > Visibility Window**. +要查看声音发射器的触发体积形状及其最小/最大距离球体,你需要启用 **Sound Entities** 可见性。如果 **Visibility** 标签页不可见,可通过 **Window > Visibility Window** 打开它。 -In the **Visibility** tab, go to **Visibility Masks** and check the box next to **Sound Entities**. This enables display of sound-related components in the scene view. Once enabled, the trigger volume (a box or sphere wireframe) and two concentric distance spheres representing the min and max audible range become visible directly in the scene, making it much easier to position and resize emitters accurately. +在 **Visibility** 标签页中,进入 **Visibility Masks** 并勾选 **Sound Entities** 旁边的复选框。这将启用场景视图中声音相关组件的显示。启用后,触发体积(box 或 sphere 线框)以及代表最小和最大可听范围的两个同心距离球体会直接显示在场景中,从而大大方便了发射器的定位和调整大小。 --- -## Adding Sound Events to Animation Clips +## 为动画片段添加声音事件 (Adding Sound Events to Animation Clips) -To attach sounds to animation clips, open the **Resource Browser** via **Window > Show Resource Browser**. The Resource Browser lets you browse, filter, and search through project assets. +要将声音附加到动画片段,请通过 **Window > Show Resource Browser** 打开**资源浏览器 (Resource Browser)**。资源浏览器可让你浏览、筛选和搜索项目资源。 -You can filter by asset class to narrow down results. If you're not sure where an asset is, use the search bar — just make sure you're searching within the correct directory. Once you find the animation clip, select it to open the **Animation Clip Inspector**. +你可以按资源类别进行筛选以缩小结果范围。如果你不确定某个资源的位置,可以使用搜索栏——只需确保你是在正确的目录内进行搜索。找到动画片段后,选中它以打开**动画片段检查器 (Animation Clip Inspector)**。 -In the **Animation Clip Inspector**, you can view and adjust all parameters linked to the selected clip. For audio, focus on the sound-related parameters: +在**动画片段检查器**中,你可以查看和调整与所选片段相关联的所有参数。对于音频,请关注与声音相关的参数: -| Property | Description | +| 属性 | 说明 | |---|---| -| **Step Points** | The X-axis value defines the timing offset within the clip. Set to `−1.00` by default if no sound is attached. Set to `0.00` or adjust to sync sound with animation | -| **Sound Code** | The FMOD event path to attach. Entering a valid path ensures the sound plays at the correct point in the animation timeline | -| **Voice Code** | Combat voice type to attach to the animation. See built-in types below, or add custom types as described in the [Voice System]({{< ref "audio-modding-systems.md#voice-system" >}}) section | +| **Step Points** | X 轴值定义了片段内的时间偏移。如果未附加声音,默认值为 `−1.00`。将其设为 `0.00` 或进行调整以使声音与动画同步 | +| **Sound Code** | 要附加的 FMOD 事件路径。输入有效路径可确保声音在动画时间轴上的正确位置播放 | +| **Voice Code** | 要附加到动画的战斗语音类型。请参阅下方的内置类型,或按照 [语音系统]({{< ref "audio-modding-systems.md#voice-system" >}}) 一节所述添加自定义类型 | -**Built-in Voice Codes:** +**内置语音代码 (Built-in Voice Codes):** -| Voice Code | +| 语音代码 | |---| | Grunt | | Jump | @@ -126,66 +127,66 @@ In the **Animation Clip Inspector**, you can view and adjust all parameters link | HorseRally | | Drown | -**Animation sound flags:** +**动画声音标志 (Animation sound flags):** -| Flag | Description | +| 标志 | 说明 | |---|---| -| `make_bodyfall_sound` | Triggers a body-fall sound at this animation point | -| `make_walk_sound` | Triggers a footstep sound at this animation point | -| `do_not_keep_track_of_sound` | Stops the engine from tracking the sound's playback state | -| `attach_sound_to_agent` | Attaches the sound directly to the agent rather than the world position | +| `make_bodyfall_sound` | 在该动画点触发身体倒地声音 | +| `make_walk_sound` | 在该动画点触发脚步声 | +| `do_not_keep_track_of_sound` | 阻止引擎追踪该声音的播放状态 | +| `attach_sound_to_agent` | 将声音直接附加到角色(agent)上,而不是世界坐标位置 | --- -## Adding Sound Events to Particles +## 为粒子添加声音事件 (Adding Sound Events to Particles) -Just like animation clips, particle assets can be accessed through the **Resource Browser**. Filter the asset list to show only particles, or use the search bar to locate a specific particle within a directory. Once found, double-click it to open the **Inspector Window**. +与动画片段一样,粒子资源也可以通过**资源浏览器**访问。筛选资源列表仅显示粒子,或使用搜索栏在目录中定位特定粒子。找到后,双击它以打开**检查器窗口**。 -In the Inspector, you can view the particle's layers, LODs, and parameters. Before attaching audio, make sure you've selected the correct **layer** and **LOD** of the particle. +在检查器中,你可以查看该粒子的层(layers)、LOD 以及参数。在附加音频之前,请确保你已选中粒子正确的**层**和 **LOD**。 -> Keep in mind: if the effect isn't visually strong enough to justify rendering at a higher LOD, it isn't strong enough to justify a sound either. In those cases, keep audio only at **LOD 0**. +> 请记住:如果某个效果在视觉上不够突出,不足以在更高的 LOD 下渲染,那么它也不足以配上声音。在这种情况下,仅在 **LOD 0** 保留音频即可。 -Once the correct layer and LOD are selected, open the **Sound** tab: +选中正确的层和 LOD 后,打开 **Sound** 标签页: -| Property | Description | +| 属性 | 说明 | |---|---| -| **Continuous sound** | Use for looping sounds. Enter the FMOD event path of the looped event | -| **One shot sound** | Use for single-playback sounds. Enter the FMOD event path of the one-shot event | -| **Size Parameter** | Applies a multiplier to override the size of a 3D sound event | +| **Continuous sound** | 用于循环声音。输入循环事件的 FMOD 事件路径 | +| **One shot sound** | 用于单次播放的声音。输入单次事件的 FMOD 事件路径 | +| **Size Parameter** | 应用一个乘数,以覆盖 3D 声音事件的大小 | --- -## Quadraphonic Ambients {#quadraphonic-ambients} +## 四声道环境音 (Quadraphonic Ambients) {#quadraphonic-ambients} -**Mount & Blade II: Bannerlord** is a performance-critical title. Adding hundreds of 3D sound emitters into scenes can quickly overwhelm CPU, memory, and disk I/O — especially during large-scale battles with thousands of active agents. To maintain immersion without sacrificing performance, we use **quadraphonic ambients**. +**《骑马与砍杀2:霸主》(Mount & Blade II: Bannerlord)** 是一款对性能要求极高的游戏。在场景中添加数百个 3D 声音发射器会迅速耗尽 CPU、内存和磁盘 I/O 资源——尤其是在拥有数千个活跃角色的大规模战斗中。为了在不牺牲性能的前提下保持沉浸感,我们使用了**四声道环境音 (quadraphonic ambients)**。 -Quadraphonic is a four-channel surround format that creates the illusion of being surrounded by many emitters while actually using only four channels. Rather than relying on FMOD's built-in quad system, we implemented our own approach. It's a bit more involved to set up, but once you understand it, it's more flexible than FMOD's internal solution. +四声道(Quadraphonic)是一种四声道环绕格式,它能在实际上仅使用四个声道的情况下,营造出被众多发射器环绕的错觉。我们没有依赖 FMOD 内置的四声道系统,而是实现了自己的方案。虽然设置起来稍微复杂一些,但一旦理解其原理,它会比 FMOD 的内部方案更灵活。 -The system spawns **four 3D emitters** around the listener at fixed positions: **0°, 90°, 180°, and 270°** relative to the listener's facing direction. These emitters move with the listener's position, but their distance to the listener stays constant. As the listener turns, they continuously receive different signals from the surrounding emitters — creating the illusion of a dynamic, shifting environment without needing dozens of independent sources. +该系统会在监听者周围固定位置生成**四个 3D 发射器**:相对于监听者朝向的 **0°、90°、180° 和 270°**。这些发射器会随监听者的位置移动,但它们与监听者的距离保持不变。当监听者转向时,他们会持续从周围的发射器接收到不同的信号——从而在无需使用数十个独立声源的情况下,营造出动态变化环境的错觉。 -### Setting Up Quad Ambients +### 设置四声道环境音 -First, create a **stereo ambient event**. This is **not optional** — it acts as a fallback in case the quad setup fails or isn't found. Without it, ambience may be missing during gameplay. +首先,创建一个**立体声环境事件 (stereo ambient event)**。这一步**并非可选**——它充当了四声道设置失败或未找到时的回退方案。如果没有它,游戏过程中可能会缺失环境音。 -For example, create a 2D event called `plains`. +例如,创建一个名为 `plains` 的 2D 事件。 -Next, create a **folder with the same name** as the stereo event (`plains` in this example). This naming is critical — the system matches stereo events to their quad alternatives by name. Events inside this folder will be treated as the quad channels. +接下来,创建一个与立体声事件**同名的文件夹**(本例中为 `plains`)。这个命名至关重要——系统会根据名称将立体声事件与对应的四声道替代方案进行匹配。该文件夹内的事件将被视为四声道通道。 -Inside the folder, create four 3D events named exactly: +在该文件夹内,创建四个 3D 事件,名称必须严格为: - `north` - `east` - `south` - `west` -> The names are **case-sensitive** and must be **lowercase**. Event order doesn't matter. +> 这些名称**区分大小写**,必须全部为**小写**。事件的顺序无关紧要。 -For each of the four quad events, open the **Spatializer** and **disable distance attenuation**. These emitters should radiate a consistent signal regardless of their distance from the listener. If attenuation is left on, volumes may be incorrectly reduced depending on distance settings. +对于这四个四声道事件中的每一个,打开**空间化器 (Spatializer)** 并**禁用距离衰减 (distance attenuation)**。这些发射器应无论与监听者的距离如何,都发出一致的信号。如果衰减保持开启,音量可能会因距离设置而被错误地降低。 -Finally, go back to the stereo event (`plains`) and set a **User Property**: +最后,返回立体声事件(`plains`),设置一个**用户属性 (User Property)**: -| Property | Value | +| 属性 | 值 | |---|---| | `isQuad` | `True` | -This flag tells the system to look for a matching quad setup. If found, the quad version plays; if not, the stereo event plays as a fallback. +该标志会告知系统去查找匹配的四声道设置。如果找到,则播放四声道版本;如果未找到,则播放立体声事件作为回退方案。 diff --git a/docs/content/schinese/Audio Modding/audio-modding-systems.md b/docs/content/schinese/Audio Modding/audio-modding-systems.md index 55dce04e..655a553b 100644 --- a/docs/content/schinese/Audio Modding/audio-modding-systems.md +++ b/docs/content/schinese/Audio Modding/audio-modding-systems.md @@ -1,24 +1,25 @@ +++ -title = "Audio Systems & Optimization" +title = "音频系统与优化" weight = 40 +ai_translated = true +++ -_Last updated: April 3, 2026_ +_最后更新时间:2026年4月3日_ --- -## Voice System {#voice-system} +## 语音系统 {#voice-system} -Non-dialogue vocalizations for humans, mounts, and animals (grunts, pain sounds, commands, etc.) are not hardcoded into game logic. Instead, they're managed through an external configuration file called `voice_definitions.xml`. This makes it straightforward to add or adjust voices without touching code. All declarations and definitions are written in XML and link directly to FMOD event paths. +人类、坐骑和动物的非对话发声(呻吟、痛苦声、指令等)并未硬编码在游戏逻辑中,而是通过一个名为 `voice_definitions.xml` 的外部配置文件进行管理。这使得在不修改代码的情况下添加或调整语音变得非常简单。所有声明和定义都以 XML 编写,并直接链接到 FMOD 事件路径。 -**File path:** +**文件路径:** ``` ..\Modules\Native\ModuleData\voice_definitions.xml ``` -### Voice Type Declarations +### 语音类型声明 -Before a voice can be used, it must be declared under the `` section. This registers the voice type so it can be referenced later. +在使用某个语音之前,必须先在 `` 部分中声明它。这会注册该语音类型,以便之后可以被引用。 ```xml @@ -26,11 +27,11 @@ Before a voice can be used, it must be declared under the ` ``` -Here, the voice type `Grunt` is declared and can now be used in one or more definitions. +在此示例中,语音类型 `Grunt` 已被声明,现在可以在一个或多个定义中使用。 -### Voice Definitions +### 语音定义 -Once a type is declared, a **voice definition** links it to an FMOD event path and defines metadata such as pitch variation and usage restrictions. +声明类型后,**语音定义(voice definition)**会将其链接到一个 FMOD 事件路径,并定义诸如音高变化和使用限制之类的元数据。 ```xml ``` -### Definition Attributes +### 定义属性 -| Attribute | Description | +| 属性 | 描述 | |---|---| -| `name` | Unique identifier for the voice definition | -| `sound_and_collision_info_class` | Class of entity this voice belongs to (e.g. `human`, `horse`) | -| `only_for_npcs` | If `true`, this voice cannot be assigned to the player | -| `min_pitch_multiplier` / `max_pitch_multiplier` | Defines the pitch variation range | +| `name` | 语音定义的唯一标识符 | +| `sound_and_collision_info_class` | 该语音所属实体的类别(例如 `human`、`horse`) | +| `only_for_npcs` | 如果为 `true`,则该语音不能分配给玩家 | +| `min_pitch_multiplier` / `max_pitch_multiplier` | 定义音高变化范围 | -### Voice Node Details +### 语音节点详情 -Inside a ``, one or more `` entries can be added: +在 `` 内部,可以添加一个或多个 `` 条目: -| Attribute | Description | +| 属性 | 描述 | |---|---| -| `type` | Must match a declared `` | -| `path` | FMOD event path triggered for this voice | -| `face_anim` | Facial animation tag associated with this voice (e.g. `grunt`) | +| `type` | 必须与某个已声明的 `` 匹配 | +| `path` | 该语音所触发的 FMOD 事件路径 | +| `face_anim` | 与该语音关联的面部动画标签(例如 `grunt`) | -### Workflow Summary +### 工作流程摘要 -1. Add a new `` under `` -2. Create a `` with a name, class, restrictions, and pitch range -3. Add one or more `` elements linking the definition to FMOD event paths -4. Assign `face_anim` for animation syncing +1. 在 `` 下添加一个新的 `` +2. 创建一个 ``,并指定名称、类别、限制条件和音高范围 +3. 添加一个或多个 `` 元素,将该定义链接到 FMOD 事件路径 +4. 为动画同步分配 `face_anim` --- -## Physics Materials +## 物理材质 -The physics system manages all material-to-material interactions in the game and determines which sound events are triggered when collisions occur. Instead of handling each case independently, all physical interactions — wood striking metal, stone colliding with a projectile, metal on metal — are processed in a single unified system. This keeps logic consistent, reduces duplication, and makes it easier to maintain and expand audio coverage as the game grows. +物理系统管理游戏中所有材质与材质之间的交互,并决定碰撞发生时触发哪些声音事件。所有物理交互——木材撞击金属、石头碰撞抛射物、金属对金属——都在一个统一的系统中处理,而不是单独处理每种情况。这样可以保持逻辑的一致性,减少重复工作,并使得随着游戏的发展更容易维护和扩展音频覆盖范围。 -### Material Interaction Handling +### 材质交互处理 -Each material type is defined in the physics system along with its interaction rules when colliding with other materials. For example: +每种材质类型都在物理系统中定义,并附带其与其他材质碰撞时的交互规则。例如: -| Interaction | Result | +| 交互 | 结果 | |---|---| -| Wood vs. Metal | A metallic clash with resonant overtones | -| Stone vs. Missile | A sharp, brittle impact sound | -| Wood vs. Stone | A dull, muted collision | +| 木材 vs. 金属 | 带有共鸣泛音的金属碰撞声 | +| 石头 vs. 抛射物 | 尖锐、脆硬的撞击声 | +| 木材 vs. 石头 | 沉闷、低沉的碰撞声 | -When two materials collide, the system evaluates their properties and selects the correct FMOD event to play. This removes the need to hard-code every possible pairwise interaction and ensures audio scales automatically as new materials are introduced. +当两种材质碰撞时,系统会评估它们的属性并选择正确的 FMOD 事件进行播放。这样就无需为每一种可能的成对交互手动编写代码,并确保音频在引入新材质时能够自动扩展。 -### Special Case: Water Interactions +### 特殊情况:水的交互 -Water requires unique treatment compared to solid materials. Unlike other pairings, "object + water" doesn't need a dedicated event for every possible object type. Regardless of what enters the water, the player primarily perceives it as a water sound — not as "body hitting water" or "stone hitting water." +与固体材质相比,水需要独特的处理方式。与其他配对不同,"物体 + 水"并不需要为每一种可能的物体类型都设置专门的事件。无论进入水中的是什么,玩家主要感知到的都是水声——而不是"物体撞击水面"或"石头撞击水面"。 -To simplify implementation, the system uses a **single generic water event** parameterized by the physical properties of the object entering the water: +为简化实现,系统使用一个**通用的水事件**,该事件通过进入水中物体的物理属性进行参数化: -| Parameter | Description | +| 参数 | 描述 | |---|---| -| **Volume** | Determines how large the displaced splash should sound | -| **Mass** | Scales the weight and depth of the impact | -| **Force** (velocity/acceleration) | Controls the intensity and sharpness of the splash | +| **体积(Volume)** | 决定溅起的水花听起来有多大 | +| **质量(Mass)** | 调整撞击的重量和深度 | +| **力(Force)**(速度/加速度) | 控制水花的强度和锐利程度 | -By combining these variables, the system can produce a wide range of splash sounds from the same event — from a small pebble skipping across the surface to a heavy boulder crashing into deep water. +通过组合这些变量,系统可以从同一个事件中产生各种各样的水花声——从一颗小石子在水面上掠过,到一块巨石坠入深水中。 -**Benefits of this approach:** +**此方法的优势:** -- **Unified logic** — All material interactions are handled consistently in one system -- **Scalability** — Adding new materials only requires defining their properties, not rewriting interaction logic -- **Efficiency** — Parameter-driven variations replace dozens of unique event definitions -- **Water optimization** — One generic event covers all possible water interactions, driven dynamically by physics parameters -- **Realism** — Splash sounds scale naturally with object size, weight, and velocity +- **统一逻辑** —— 所有材质交互都在一个系统中以一致的方式处理 +- **可扩展性** —— 添加新材质只需定义其属性,而无需重写交互逻辑 +- **效率** —— 参数驱动的变化取代了数十种独特的事件定义 +- **水体优化** —— 一个通用事件涵盖所有可能的水体交互,由物理参数动态驱动 +- **真实感** —— 水花声会随着物体的大小、重量和速度自然变化 --- -## Priority System {#priority-system} +## 优先级系统 {#priority-system} -This system runs **before** FMOD's built-in priority system, acting as a pre-filter to reduce the CPU cost of evaluating large numbers of events. It applies its own rules to decide which sounds are eligible, and only those are passed on to FMOD for playback. FMOD's internal priority system still applies once events are submitted, so you can continue using it to refine prioritization among active events. +该系统在 FMOD 内置的优先级系统**之前**运行,充当一个预过滤器,以降低评估大量事件所需的 CPU 成本。它应用自己的规则来决定哪些声音符合条件,只有这些声音才会被传递给 FMOD 进行播放。一旦事件被提交,FMOD 的内部优先级系统仍会生效,因此你仍然可以使用它来细化活动事件之间的优先级排序。 -### Core Mechanism +### 核心机制 -The system maintains an array whose maximum size corresponds to the maximum number of events it's allowed to manage at once. Each candidate event is evaluated against a priority scheme based on: +该系统维护一个数组,其最大大小对应于它一次可以管理的最大事件数量。每个候选事件都会根据以下优先级方案进行评估: -| Parameter | Description | +| 参数 | 描述 | |---|---| -| **Length** | Duration of the event — used to determine whether short transient sounds or long events should be favored | -| **Distance** | Spatial distance between emitter and listener. If this exceeds the event's defined max distance in FMOD, the sound is culled immediately and never passed to FMOD | -| **PriorityMultiplier** | A user-defined multiplier that adjusts the relative importance of an event compared to others | +| **长度(Length)** | 事件的持续时间——用于决定应优先考虑短暂的瞬态声音还是较长的事件 | +| **距离(Distance)** | 发射器与监听器之间的空间距离。如果超过了事件在 FMOD 中定义的最大距离,该声音将被立即剔除,永远不会传递给 FMOD | +| **PriorityMultiplier(优先级乘数)** | 一个用户定义的乘数,用于调整某事件相对于其他事件的重要性 | -These parameters are stored in the **SEDF (Sound Event Data File)** for every event, ensuring consistent evaluation. +这些参数存储在每个事件的 **SEDF(Sound Event Data File,声音事件数据文件)**中,以确保评估的一致性。 -### Distance Filtering +### 距离过滤 -Events that fall outside their maximum audible distance are killed before FMOD ever processes them. This prevents FMOD from spending resources evaluating voices that can't be heard. +超出其最大可听距离的事件会在 FMOD 处理它们之前就被终止。这可以防止 FMOD 浪费资源去评估那些根本听不到的声音。 -### Exceptions and Looping Events +### 例外情况与循环事件 -Looping sounds need special handling: +循环声音需要特殊处理: -- **Ambient sounds** are excluded from this system entirely and marked as persistent within FMOD — they are never culled by pre-priority logic. -- **Looped sounds** present a problem: if they're killed and restarted, they can't resume from their previous play position, causing synchronization issues. +- **环境音(Ambient sounds)**完全不受此系统影响,并在 FMOD 中被标记为持久性——它们永远不会被预优先级逻辑剔除。 +- **循环声音(Looped sounds)**存在一个问题:如果它们被终止后重新启动,就无法从之前的播放位置继续,从而导致同步问题。 -To handle this, looped sounds can be **virtualized** instead of killed. Virtualization lets the event stop consuming CPU while still tracking its playback position, so when it returns to audible range it continues seamlessly from where it left off. +为解决此问题,循环声音可以被**虚拟化(virtualized)**,而不是被终止。虚拟化可以让该事件停止消耗 CPU,同时仍然追踪其播放位置,因此当它重新回到可听范围内时,可以从停止的位置无缝继续播放。 -### User Property Overrides +### 用户属性覆盖 -User Properties provide additional flexibility (see [User Properties]({{< ref "audio-modding-event-setup.md#user-properties" >}})): +用户属性(User Properties)提供了额外的灵活性(参见[用户属性]({{< ref "audio-modding-event-setup.md#user-properties" >}})): -- **Ignore flags** — Distance or length checks can be bypassed for specific events if tagged accordingly -- **Custom multipliers** — A multiplier can be defined per event through User Properties, modifying its relative priority when compared with others +- **忽略标志(Ignore flags)** —— 对于被相应标记的特定事件,可以跳过距离或长度检查 +- **自定义乘数(Custom multipliers)** —— 可以通过用户属性为每个事件定义一个乘数,从而在与其他事件比较时修改其相对优先级 -**Benefits:** +**优势:** -- **CPU efficiency** — Reduces FMOD's workload by culling inaudible or unnecessary sounds before they reach the engine -- **Flexible prioritization** — Length, distance, and multipliers allow fine-tuned control over event importance -- **Synchronization safety** — Virtualization ensures looped events remain consistent when reactivated -- **Designer control** — User Properties enable exceptions and weighting without code changes +- **CPU 效率** —— 在声音到达引擎之前剔除听不见或不必要的声音,从而减少 FMOD 的工作负载 +- **灵活的优先级排序** —— 长度、距离和乘数可对事件重要性进行精细化控制 +- **同步安全性** —— 虚拟化确保循环事件在重新激活时保持一致性 +- **设计师控制权** —— 用户属性无需修改代码即可实现例外情况和权重调整 --- -## Battle Ambient Sound System {#battle-ambient-sound-system} +## 战斗环境声音系统 {#battle-ambient-sound-system} -The Battle Ambient Sound System — abbreviated as **BASS** — is designed to optimize the playback of high-density sound effects, such as multiple sword clashes occurring in the same area. Instead of letting each individual sound play independently (which can quickly overwhelm both the mix and the CPU), BASS aggregates these events and replaces them with a single emitter that represents the group. +战斗环境声音系统(Battle Ambient Sound System)——简称为 **BASS**——旨在优化高密度音效的播放,例如同一区域内发生的多次刀剑碰撞声。该系统不会让每个独立的声音单独播放(这很快会使混音和 CPU 不堪重负),而是将这些事件聚合起来,并用代表整个群体的单个发射器替代它们。 -### How It Works +### 工作原理 -Within a defined region, BASS monitors the number of sound events triggered over a given period. When the count exceeds a specified threshold, the system suppresses the individual sounds in that region and spawns a single **group emitter event** in their place. +在一个指定区域内,BASS 会监控在给定时间段内触发的声音事件数量。当数量超过指定阈值时,系统会抑制该区域内的单个声音,并在其位置生成一个**群组发射器事件(group emitter event)**。 -This emitter event includes a parameter reflecting the density of sounds in the area. As the parameter increases, the mix shifts from sparse individual clashes to dense, chaotic battle noise. Players still perceive an intense soundscape, but without the overhead of dozens of overlapping one-shots. +该发射器事件包含一个反映该区域内声音密度的参数。随着该参数增加,混音会从稀疏的个别碰撞声转变为密集、混乱的战斗噪音。玩家仍然能感受到紧张激烈的音景,但不会产生数十个重叠单次声音所带来的开销。 -### Interaction with the Priority System +### 与优先级系统的交互 -BASS operates **before** our proprietary engine's priority system. Normally, the priority system decides which sounds to cull when many voices compete for playback. In this workflow, BASS preemptively reduces polyphony at the source level — only the grouped emitter remains active, meaning the priority system has fewer voices to manage. This prevents unnecessary CPU/DSP usage and ensures consistent sound quality during crowded combat. +BASS 在我们专有引擎的优先级系统**之前**运行。通常,当许多声音竞争播放时,优先级系统会决定剔除哪些声音。而在此工作流程中,BASS 会预先在源头减少复音数——只有分组后的发射器保持活动状态,这意味着优先级系统需要管理的声音更少。这可以防止不必要的 CPU/DSP 占用,并确保在拥挤的战斗场景中保持一致的声音质量。 -### BASS Group IDs +### BASS 分组 ID -Use the `battle_ambient_group_id` user property (see [User Properties]({{< ref "audio-modding-event-setup.md#user-properties" >}})) to assign an event to a BASS group. +使用 `battle_ambient_group_id` 用户属性(参见[用户属性]({{< ref "audio-modding-event-setup.md#user-properties" >}}))将事件分配到一个 BASS 分组。 -| ID | Group | +| ID | 分组 | |---|---| -| 0 | Infantry move | -| 1 | Cavalry move | -| 2 | Weapons fight | -| 3 | Shield fight | -| 4 | Missile volley | -| 5 | Human fight | -| 6 | Human victory | -| 7 | Horse vocal | +| 0 | 步兵移动 | +| 1 | 骑兵移动 | +| 2 | 武器战斗 | +| 3 | 盾牌战斗 | +| 4 | 抛射物齐射 | +| 5 | 人类战斗 | +| 6 | 人类胜利 | +| 7 | 马匹发声 | -**Examples:** -- Adding a new weapon event → set `battle_ambient_group_id` to **2** -- Adding a footstep event for a new mount type → set `battle_ambient_group_id` to **1** +**示例:** +- 添加一个新的武器事件 → 将 `battle_ambient_group_id` 设置为 **2** +- 为新的坐骑类型添加脚步声事件 → 将 `battle_ambient_group_id` 设置为 **1** -By assigning the correct group ID, BASS fires one unified event per group instead of hundreds of individual ones, significantly reducing active event count and saving system resources. +通过分配正确的分组 ID,BASS 会为每个分组触发一个统一的事件,而不是数百个独立事件,从而大幅减少活动事件数量并节省系统资源。 -**Benefits:** +**优势:** -- **Performance optimization** — Prevents CPU and memory spikes from excessive overlapping sounds -- **Mix clarity** — Replaces cluttered layers of transients with a single controlled emitter -- **Scalability** — Parameter-driven event design adapts automatically to combat density +- **性能优化** —— 防止过多重叠声音造成的 CPU 和内存峰值 +- **混音清晰度** —— 用单个受控发射器替代杂乱的瞬态层 +- **可扩展性** —— 参数驱动的事件设计可根据战斗密度自动调整 --- -## Performance and Optimization +## 性能与优化 -In a CPU- and memory-intensive title like **Mount & Blade II: Bannerlord**, FMOD must be treated as part of the overall performance budget. Poorly managed audio banks, codecs, or event design can consume resources the game engine needs for everything else. Optimization is not a one-off task — it's an ongoing discipline throughout the entire modding process. +在像 **Mount & Blade II: Bannerlord** 这样对 CPU 和内存要求很高的游戏中,FMOD 必须被视为整体性能预算的一部分。管理不善的音频库(bank)、编解码器或事件设计可能会消耗游戏引擎其他方面所需的资源。优化不是一次性的任务——它是贯穿整个模组制作过程的持续性工作。 -### Codec and Asset Strategy +### 编解码器与资产策略 -Every decoded sample costs CPU, every oversized file costs memory and disk I/O, and every resample costs even more CPU. Codec strategy must be set deliberately, not left to chance. +每个解码的采样都会消耗 CPU,每个过大的文件都会消耗内存和磁盘 I/O,每次重采样都会消耗更多的 CPU。编解码器策略必须经过深思熟虑地设定,而不是随意选择。 -FMOD lets you set a default codec for the entire audio build in the bank build settings (ensuring consistency across the project) and override codecs per asset when specific files demand different treatment. +FMOD 允许你在音频库(bank)构建设置中为整个音频构建设置默认编解码器(以确保项目的一致性),并在特定文件需要不同处理方式时针对各资产覆盖编解码器。 -FMOD Studio's practical PC formats are: +FMOD Studio 实用的 PC 格式包括: -| Codec | Characteristics | +| 编解码器 | 特性 | |---|---| -| **Vorbis** | Best compression, but higher decode cost. Best overall choice when CPU is available | -| **ADPCM** | Larger than Vorbis but almost free to decode. Good fallback when Vorbis is too CPU-heavy | -| **PCM** | No compression, no decode cost. Can quickly bloat memory — avoid unless strictly necessary | +| **Vorbis** | 压缩效果最好,但解码成本较高。在 CPU 资源充足时是最佳的整体选择 | +| **ADPCM** | 比 Vorbis 更大,但解码几乎不消耗资源。当 Vorbis 对 CPU 负担过重时是一个很好的备选方案 | +| **PCM** | 无压缩,无解码成本。会迅速占用大量内存——除非确有必要,否则应避免使用 | -#### Load Types +#### 加载类型 -Each asset has a **Load Type** setting that determines how it lives in memory: +每个资产都有一个**加载类型(Load Type)**设置,决定其在内存中的存在方式: -| Load Type | Description | +| 加载类型 | 描述 | |---|---| -| **Compressed** | Loaded in compressed form and decompressed at playback. Less memory, slightly more CPU at play time | -| **Decompressed** | Decompressed into PCM when banks load, not at playback. Not recommended unless you have a specific need (e.g. very low-spec devices) | -| **Streaming** | Loaded in chunks from disk as needed. Good for long music and ambiences that aren't time-sensitive | +| **Compressed(压缩)** | 以压缩形式加载,在播放时解压缩。占用内存较少,播放时 CPU 占用略高 | +| **Decompressed(解压缩)** | 在音频库(bank)加载时解压为 PCM,而不是在播放时解压。除非有特殊需求(例如非常低配置的设备),否则不建议使用 | +| **Streaming(流式传输)** | 根据需要分块从磁盘加载。适合对时间不敏感的长时间音乐和环境音 | -### Streaming and Bank Management +### 流式传输与音频库管理 -On PC, long assets like music or ambiences can balloon RAM usage if kept fully in memory. Streaming solves this by pulling audio in chunks from disk, but every stream adds CPU overhead and disk I/O pressure. Stream too many files at once and you risk stutters and thread contention, especially on HDDs or low-end systems. **Stream only what needs it.** +在 PC 上,如果长时间的资产(如音乐或环境音)完全保存在内存中,会导致内存占用激增。流式传输通过从磁盘分块拉取音频来解决这个问题,但每个流都会增加 CPU 开销和磁盘 I/O 压力。如果同时流式传输过多文件,就会有卡顿和线程争用的风险,尤其是在机械硬盘(HDD)或低端系统上。**只对确实需要的内容使用流式传输。** -Banks are containers for events, assets, and metadata — they determine what FMOD loads into RAM at runtime. Poorly structured banks leave unnecessary assets in memory, extend load times, and create streaming bottlenecks. Each event should live in a single bank; the same event should never appear in multiple banks unless there's an unavoidable design requirement. +音频库(Bank)是事件、资产和元数据的容器——它们决定了 FMOD 在运行时加载到内存中的内容。结构不良的音频库会在内存中留下不必要的资产,延长加载时间,并产生流式传输瓶颈。每个事件都应存在于单一一个音频库中;除非有不可避免的设计需求,否则同一个事件绝不应出现在多个音频库中。 -### Event, DSP, and Channel Management +### 事件、DSP 与声道管理 -Every event generates one or more voices, each consuming CPU and memory. Stereo, quad, or 5.1 events multiply the number of channels being mixed. Combine this with DSP on each path and costs grow fast. If you don't actively manage instances, channels, and DSP chains, your mix can choke the CPU long before your assets fill memory. +每个事件都会生成一个或多个声音(voice),每个声音都会消耗 CPU 和内存。立体声、四声道或 5.1 声道事件会增加需要混音的声道数量。再加上每条路径上的 DSP 处理,成本会迅速增长。如果你不积极管理实例、声道和 DSP 链,你的混音可能会在资产填满内存之前就拖垮 CPU。 -#### Controlling Event Instances and Channels +#### 控制事件实例与声道 -Although we already handle this with our custom priority system, you can set max instance limits on heavily triggered events if needed. For each event, define a sensible polyphony cap and choose a **stealing rule**: +虽然我们已经通过自定义优先级系统处理了这一点,但如有需要,你仍可以为触发频率高的事件设置最大实例数限制。为每个事件定义一个合理的复音数上限,并选择一个**抢占规则(stealing rule)**: -| Rule | Behavior | +| 规则 | 行为 | |---|---| -| **Oldest** | Cuts off the instance that has been playing the longest | -| **Newest** | Blocks the most recently triggered instance from starting | -| **Quietest** | Stops the currently lowest-volume instance | -| **Virtualize** | Suspends an instance into a no-CPU "virtual" state while keeping its timeline active. Useful for VO and music | -| **None** | Prevents new instances from starting if the max is already reached | -| **Furthest** | Stops the instance furthest from the listener | +| **Oldest(最早)** | 终止播放时间最长的实例 | +| **Newest(最新)** | 阻止最近触发的实例开始播放 | +| **Quietest(最安静)** | 停止当前音量最低的实例 | +| **Virtualize(虚拟化)** | 将实例挂起至不消耗 CPU 的"虚拟"状态,同时保持其时间轴处于活动状态。对语音和音乐非常有用 | +| **None(无)** | 如果已达到最大数量,则阻止新实例启动 | +| **Furthest(最远)** | 停止距离监听器最远的实例 | -Keep channel counts realistic: +保持声道数量合理: -- Use **mono** for any sound with no spatial width -- Use **stereo** only when width is essential (music, ambiences, UI) -- Save **quad or 5.1+** for true surround beds that justify the cost +- 对任何没有空间宽度需求的声音使用**单声道(mono)** +- 仅在宽度至关重要时使用**立体声(stereo)**(音乐、环境音、UI) +- 将**四声道或 5.1+ 声道**留给真正值得其成本的环绕声床 -Every extra channel means extra mixing, panning, and potential DSP. Don't waste channels on one-shots that will collapse to mono in most contexts anyway. +每增加一个声道都意味着额外的混音、声像(panning)以及潜在的 DSP 处理。不要在大多数情况下都会被折叠为单声道的单次音效上浪费声道资源。 -#### Managing DSP Load +#### 管理 DSP 负载 -DSP processing is the heaviest part of runtime audio performance. Effects like convolution reverb, FFT filters, and multiband dynamics consume significant CPU — often more than their audible benefit justifies. Apply DSP only when it provides clear value, such as shaping the overall mix in a way that can't be pre-baked. For common one-shot events, keep them clean or embed processing directly into the audio file. +DSP 处理是运行时音频性能中开销最大的部分。卷积混响、FFT 滤波器和多频段动态处理等效果会消耗大量 CPU——通常超过其可听收益所能证明的价值。只有在能提供明确价值时才应用 DSP,例如以无法预先烘焙的方式塑造整体混音。对于常见的单次事件,应保持其纯净,或将处理过程直接嵌入音频文件中。 -Channel count multiplies DSP cost: a stereo convolution reverb is twice the work of mono, and a quad instance multiplies it further. Use mono effects wherever possible. +声道数量会使 DSP 成本成倍增加:立体声卷积混响的工作量是单声道的两倍,而四声道实例则进一步成倍增加。应尽可能使用单声道效果。 -### Bus and Routing +### 总线与路由 -Bus hierarchies should stay functional and minimal. Group major categories under dedicated sub-buses only where it serves a clear purpose. Use sends and sidechains intentionally — every extra routing hop adds to channel mixing and DSP load. Consolidate DSP chains at the bus level instead of stacking them across many individual events. Snapshots can then modify the properties of a single DSP effect across multiple states, significantly cutting down on total DSP instances required. +总线层级结构应保持功能性和精简性。仅在有明确目的的情况下,才将主要类别归入专用子总线。有意识地使用发送(sends)和侧链(sidechains)——每增加一个路由跳转都会增加声道混音和 DSP 负载。应在总线级别整合 DSP 链,而不是在众多单独事件中叠加。快照(Snapshots)可以在多个状态下修改单个 DSP 效果的属性,从而大幅减少所需的 DSP 实例总数。 -### Using Baked Effects +### 使用预烘焙效果 -If a sound always needs coloration (EQ, distortion, static reverb), bake it into the source file. Reserve runtime DSP for genuinely interactive processing: parameter-driven filters, ducking, pitch modulation, or environmental reverb zones that change dynamically. This prevents the slow creep of redundant DSP costs. +如果某个声音始终需要染色处理(均衡、失真、静态混响),应将其烘焙进源文件中。将运行时 DSP 保留给真正需要交互处理的场景:参数驱动的滤波器、闪避(ducking)、音高调制,或动态变化的环境混响区域。这样可以防止冗余 DSP 成本的缓慢累积。 -### Importing Assets +### 导入资产 -Keep assets lean before they reach FMOD: +在资产进入 FMOD 之前保持其精简: -- **Trim silence** from samples -- **Normalize loudness** to a consistent LUFS baseline -- **Match the project sample rate** (48 kHz) to avoid hidden resampling and wasted CPU cycles +- 从采样中**修剪静音部分** +- **规范化响度(Normalize loudness)**至一致的 LUFS 基准 +- **匹配项目采样率**(48 kHz),以避免隐藏的重采样和浪费的 CPU 周期 -While FMOD encodes assets into its own formats at build time, the **source format** you import still affects workflow. Using `.wav` for everything bloats the project since .wav files are uncompressed. Switching to **`.flac`** for source assets can drastically reduce disk footprint while preserving lossless quality — this doesn't affect the final encoded format (PCM, Vorbis, ADPCM, etc.), but makes asset management lighter and faster. +虽然 FMOD 会在构建时将资产编码为自己的格式,但你导入时使用的**源格式**仍然会影响工作流程。对所有内容都使用 `.wav` 会使项目膨胀,因为 .wav 文件是未压缩的。将源资产切换为 **`.flac`** 格式可以在保持无损质量的同时大幅减少磁盘占用空间——这不会影响最终编码格式(PCM、Vorbis、ADPCM 等),但会使资产管理更加轻量和快速。 -### Testing for Edge Cases +### 测试边界情况 -Always test edge conditions: thousands of agents in combat, long campaign sessions, or rapid scene transitions. These scenarios reveal memory leaks, mismanaged banks, or runaway event counts before they become real-world problems reported by players. +务必测试边界条件:数千个代理(agent)参与战斗、长时间的战役会话或快速的场景切换。这些场景能够在内存泄漏、音频库管理不当或事件数量失控成为玩家报告的实际问题之前就将其揭示出来。 diff --git a/docs/content/schinese/Authoring Mission Scenes/arenas.md b/docs/content/schinese/Authoring Mission Scenes/arenas.md index 1e92dcef..ddf22571 100644 --- a/docs/content/schinese/Authoring Mission Scenes/arenas.md +++ b/docs/content/schinese/Authoring Mission Scenes/arenas.md @@ -1,110 +1,111 @@ +++ -title = "What Makes an Arena Scene" +title = "竞技场场景的构成要素" description = "" weight = 1 +ai_translated = true +++ -#### Intro +#### 简介 -* We are going to answer the “How to create an arena scene?” and “What should we take into consideration when creating an arena scene?” questions in this documentation. +* 本文档将回答“如何创建竞技场场景?”以及“创建竞技场场景时应考虑哪些因素?”这两个问题。 -#### Scene Preparation +#### 场景准备 -* The first topic that needs to be highlighted is that the terrain for the arena scene should not be too big. Fewer terrain nodes can be used in arena scenes. Far less than you need on other types of scenes. +* 首先需要强调的一点是,竞技场场景的地形不应过大。竞技场场景中可以使用较少的地形节点,远少于其他类型场景所需的数量。 -#### Terrain and scene models -* In an arena scene, the terrain should be flat or near flat with a few uneven parts (it is up to the scene author’s taste). -* Models should be placed before with modular parts (stands and lounges). - * Example: A Sturgian arena scene has `sturgia_arena_grandstand_a`, `sturgia_arena_grandstand_b`, `sturgia_arena_grandstand_c`, `sturgia_arena_grandstand_d` modular mesh parts. -* Fake houses should be used because we don’t want the background of the stands and the inner city view to be empty. We can do this by referencing the `Adam0` model’s head height view in the fighting areas and lounges. -* Each faction has unique models. These models should be used accordingly and should be placed on the appropriate parts of the scene. +#### 地形与场景模型 +* 在竞技场场景中,地形应该是平坦或接近平坦的,带有少量不平整的部分(具体取决于场景作者的喜好)。 +* 应事先使用模块化部件(看台和包厢)放置模型。 + * 示例:一个斯图尔基亚(Sturgian)竞技场场景拥有 `sturgia_arena_grandstand_a`、`sturgia_arena_grandstand_b`、`sturgia_arena_grandstand_c`、`sturgia_arena_grandstand_d` 等模块化网格部件。 +* 应使用假房屋(fake houses),因为我们不希望看台背景和内城景观显得空旷。我们可以通过参考 `Adam0` 模型在战斗区域和包厢中的头部高度视角来实现这一点。 +* 每个派系都有独特的模型。这些模型应被恰当地使用,并放置在场景的相应部位。 -#### Required spawn points -* In the active fighting area: +#### 必需的出生点(spawn points) +* 在活跃战斗区域: * `tournament_practice_set` * `tournament_fight_set` -* In the lounge area: +* 在包厢区域: * `sp_tournament_master` * `sp_player_near_arena_master` - * `_barrier_passage_center` (needs to be placed at the door or the lounge entry points) + * `_barrier_passage_center`(需要放置在门口或包厢入口点) * `sp_player` -#### Step-by-step arena creation with screenshots -* Terrain features: One node (Color Map Resolution: 512x512), LOD Multiplier (1) -* The fighting area is now specified. We have also done the terrain painting (we suggest you use `adam0` mesh to help with proportions). +#### 带截图的竞技场创建分步指南 +* 地形特性:一个节点(颜色贴图分辨率:512x512),LOD 倍率(1) +* 现在已指定战斗区域。我们还完成了地形绘制(建议使用 `adam0` 网格来辅助比例把控)。 | | | | ------ | ----------- | | | | -* After designating the arena place, the lounges and the stands should be placed (if you have your own custom models you can use them at this stage, otherwise use existing models in the prefab tab, like `arena_main_building`). -* In addition to the environmental elements, you can place various meshes for visual beautification (stones, broken barrels, logs, etc.). +* 在确定竞技场位置之后,应放置包厢和看台(如果你有自己的自定义模型,可以在此阶段使用它们,否则请使用预制件(prefab)标签页中的现有模型,例如 `arena_main_building`)。 +* 除了环境元素之外,你还可以放置各种网格用于视觉美化(石头、破损的木桶、原木等)。 -* Torches and light sources should also be placed on the scene. +* 还应在场景中放置火把和光源。 -* Search for `arena_audience_mid_point` in the prefab tab. Place it in the middle of the scene periodically. +* 在预制件标签页中搜索 `arena_audience_mid_point`。将其定期放置在场景中央。 -* Search for `crowd_man` in the prefab tab. Place the three variants as you like on the stands. +* 在预制件标签页中搜索 `crowd_man`。按你的喜好将三种变体放置在看台上。 -* This stage is one of the most important ones. The spawn points that should be placed in the arena's main building which we call lounges are the following: +* 这一阶段是最重要的阶段之一。需要放置在竞技场主建筑(我们称之为包厢)中的出生点如下: * `sp_tournament_master` * `sp_player_near_arena_master` * `_barrier_passage_center` * `sp_player` -* `sp_tournament_master` should be placed facing back to the fighting area. In front of this spawn point, you need to place `sp_player_near_arena_master` because they need to face each other. Besides this, `camera_height_limiter` needs to be placed as the lens should see the lounge area. -* Barries need to be placed in the lounge. +* `sp_tournament_master` 应面朝背对战斗区域放置。在此出生点前方,你需要放置 `sp_player_near_arena_master`,因为它们需要彼此面对面。此外,还需要放置 `camera_height_limiter`,因为镜头应当能看到包厢区域。 +* 需要在包厢中放置屏障(barries)。 -| Spawn point placements | Spawn point placements and placed barriers | +| 出生点放置 | 出生点放置与放置的屏障 | | ------ | ----------- | | | | -| Another angle of the placed spawn points | The level of the Camera Height Limiter, place, and lens’ target | +| 已放置出生点的另一个视角 | 摄像机高度限制器的水平、位置及镜头目标 | | ------ | ----------- | | | | -* `envmap_prop` should be placed in the arena centre. The height of this is important. It is suggested to use the `Adam0` model for proportioning. +* `envmap_prop` 应放置在竞技场中心。此物体的高度很重要。建议使用 `Adam0` 模型来进行比例把控。 -* If there are any areas that we don’t want the player or the AI to go to, we should place barriers. +* 如果有任何我们不希望玩家或 AI 进入的区域,应放置屏障。 -* A path should be drawn along the stands. This path is used for the stand audio. Don’t forget to name the path. - * Search for `arena_path_sound` in the prefab tab. Place the prefab on the scene wherever you want. Enlarge the `Scripts` drop-down menu on the `Entity Inspector` tab. You should see the `path_converger` script. Enter the path name you entered before into the `Path Name` field in the `path_converger` script. +* 应沿着看台绘制一条路径(path)。此路径用于看台音效。别忘了为该路径命名。 + * 在预制件标签页中搜索 `arena_path_sound`。将该预制件放置在场景中你想要的任意位置。展开 `Entity Inspector` 标签页中的 `Scripts` 下拉菜单,你应该会看到 `path_converger` 脚本。将你之前输入的路径名称输入到 `path_converger` 脚本中的 `Path Name` 字段。 | | | | ------ | ----------- | | | | -* A general camera needs to be placed on the scene. You can search for `camera_instance` in the prefabs tab. WARNING! There are two Camera Instances in the prefabs tab. The one we are going to use is the one named with lowercase letters. You can add your camera to the scene as shown in the screenshot. +* 需要在场景中放置一个通用摄像机。你可以在预制件标签页中搜索 `camera_instance`。警告!预制件标签页中有两个 Camera Instance。我们要使用的是名称以小写字母命名的那个。你可以按照截图所示将摄像机添加到场景中。 -* For the arena fighting area, you need to place two spawn points. These are: - * `tournament_practice_set` (used for “Practice fight” campaign option) - * `tournament_fight_set` (used for “Join the tournament” campaign option) -* After placing these two sets you need to place child spawn points. You can check the screenshot for details. +* 对于竞技场战斗区域,你需要放置两个出生点集(spawn point sets)。它们是: + * `tournament_practice_set`(用于“练习战斗”战役选项) + * `tournament_fight_set`(用于“加入锦标赛”战役选项) +* 放置这两个集合之后,你需要放置子出生点。详情请参见截图。 | | | | ------ | ----------- | | | | -* You need to place `border_soft` around the fighting area (not necessary around the stands). +* 你需要在战斗区域周围放置 `border_soft`(不需要环绕看台放置)。 -* The last stage consists of creating the navmesh for the lounge and the fighting area. +* 最后一个阶段是为包厢和战斗区域创建导航网格(navmesh)。 | | | | ------ | ----------- | -| | | \ No newline at end of file +| | | diff --git a/docs/content/schinese/Authoring Mission Scenes/custom_water_materials_for_non_naval_scenes.md b/docs/content/schinese/Authoring Mission Scenes/custom_water_materials_for_non_naval_scenes.md index affd7ea6..5575149b 100644 --- a/docs/content/schinese/Authoring Mission Scenes/custom_water_materials_for_non_naval_scenes.md +++ b/docs/content/schinese/Authoring Mission Scenes/custom_water_materials_for_non_naval_scenes.md @@ -1,134 +1,135 @@ +++ -title = "Custom Water Materials for Non-Naval Scenes" +title = "非海战场景的自定义水体材质" description = "" weight = 1 +ai_translated = true +++ -This guide explains how to give a scene its own water look when the Naval DLC macro-displacement renderer is **not** in use — for example, a river ford, a lake, or any land battle with a water body in it. +本指南介绍了在**未**使用 Naval DLC 宏观位移渲染器的情况下,如何为场景赋予自己独特的水体外观——例如河流浅滩、湖泊,或任何包含水体的陆地战斗场景。 --- -## Overview +## 概述 -By default every non-naval scene shares a single engine water material called `base_water_scene_default`. That material controls the colour of the water, how light scatters through it, and what the surface looks like. +默认情况下,每个非海战场景都共享一个名为 `base_water_scene_default` 的单一引擎水体材质。该材质控制着水的颜色、光线在水中散射的方式,以及水面的外观。 -You can replace it per-scene with any material that uses the `water_surface` shader. When you do, the engine uses your material instead — and the wave simulation parameters (strength, choppiness, wind direction influence) are no longer overridden by gameplay code, so you can tune them directly in the Scene Inspector. +你可以按场景使用任何采用 `water_surface` 着色器的材质来替换它。当你这样做时,引擎将使用你的材质——并且波浪模拟参数(强度、波浪尖锐度、风向影响)将不再被游戏玩法代码覆盖,因此你可以直接在场景检查器(Scene Inspector)中进行调整。 -> **Naval DLC note:** This override only applies when the Naval DLC macro-displacement renderer is **inactive**. In naval combat missions the override is ignored and the naval pipeline takes over as usual. +> **Naval DLC 说明:** 此覆盖仅在 Naval DLC 宏观位移渲染器**未激活**时生效。在海战任务中,该覆盖会被忽略,海战渲染管线会照常接管。 --- -## Step 1 — Create a Water Material +## 步骤 1 — 创建水体材质 -1. Open the **Resource Browser** and find `base_water_scene_default`. -2. Duplicate it and give it a clear name, for example `my_module_lake_water`. -3. Open the duplicate in the **Material Inspector**. -4. Verify that the **Shader** field shows `water_surface`. Only materials with this exact shader will appear in the scene's water material picker. +1. 打开 **资源浏览器(Resource Browser)**,找到 `base_water_scene_default`。 +2. 复制它,并给它起一个清晰的名称,例如 `my_module_lake_water`。 +3. 在 **材质检查器(Material Inspector)** 中打开该副本。 +4. 确认 **着色器(Shader)** 字段显示的是 `water_surface`。只有使用这一精确着色器的材质才会出现在场景的水体材质选择器中。 --- -## Step 2 — Set the Material on the Scene +## 步骤 2 — 在场景中设置材质 -1. Open your scene in the editor. -2. In the **Scene Inspector**, expand the **Water** group. -3. Find the **Non-Naval Water Material Override** field. -4. Click the picker and choose your material. - - The list is filtered to show only `water_surface` materials. - - Leave the field empty to revert to the engine default (`base_water_scene_default`). -5. Save the scene. The override is stored in the scene file and loaded automatically every time the scene is opened in-game or in the editor. +1. 在编辑器中打开你的场景。 +2. 在 **场景检查器(Scene Inspector)** 中,展开 **水(Water)** 组。 +3. 找到 **非海战水体材质覆盖(Non-Naval Water Material Override)** 字段。 +4. 点击选择器并选择你的材质。 + - 该列表已筛选为仅显示 `water_surface` 材质。 + - 将此字段留空以恢复为引擎默认值(`base_water_scene_default`)。 +5. 保存场景。该覆盖会被存储在场景文件中,并在每次于游戏内或编辑器中打开该场景时自动加载。 > -> **Editor preview:** If the Naval DLC is active in your editor session, the **Visibility Manager** panel will show a **"Preview Naval Water Renderer"** checkbox. Make sure this is **unchecked** while working on non-naval water — when it is checked the naval macro-displacement renderer is active and your material override will not be visible. Uncheck it to switch the viewport to the non-naval path and see your material changes live. +> **编辑器预览:** 如果你的编辑器会话中启用了 Naval DLC,**可见性管理器(Visibility Manager)** 面板将显示一个 **“Preview Naval Water Renderer”**(预览海战水体渲染器)复选框。请确保在处理非海战水体时**取消勾选**此项——当它被勾选时,海战宏观位移渲染器处于激活状态,你的材质覆盖将不可见。取消勾选它可将视口切换到非海战路径,从而实时查看你的材质更改效果。 --- -## Step 3 — Tune the Material +## 步骤 3 — 调整材质 -The two fields that have the most visual impact are in the Material Inspector. Everything else (wave animation, displacement, caustics) is driven by the simulation and cannot be changed per-material. +在材质检查器中,对视觉效果影响最大的两个字段如下。其他一切(波浪动画、位移、焦散)都由模拟系统驱动,无法按材质单独更改。 -### Factor Color — Water Body Color +### Factor Color(因子颜色)— 水体颜色 -This controls how light is absorbed as it travels down through the water. Think of it as the colour the water takes on when it is deep. +此参数控制光线在水中向下传播时被吸收的程度。可以将其理解为水在深处所呈现的颜色。 -| Channel | What it controls | +| 通道 | 作用 | | :---- | :---- | -| **R (red)** | How much red light survives at depth. Low \= reds disappear quickly, giving a blue-green tint. | -| **G (green)** | How much green light survives. | -| **B (blue)** | How much blue light survives. High \= clear blue water. | -| **A (alpha)** | How quickly the scattered haze takes over with depth. Low values make the haze appear almost immediately; higher values (0.5–2.0) give a natural depth gradient. | +| **R(红色)** | 红光在深处存活的程度。数值低 \= 红色迅速消失,呈现蓝绿色调。 | +| **G(绿色)** | 绿光存活的程度。 | +| **B(蓝色)** | 蓝光存活的程度。数值高 \= 清澈的蓝色水体。 | +| **A(透明度)** | 散射雾霭随深度加深而占主导的速度。数值低时雾霭几乎立即出现;数值较高(0.5–2.0)时则呈现自然的深度渐变。 | -**Starting points to try:** +**可尝试的起始数值:** -| Water type | Factor Color (R, G, B, A) | +| 水体类型 | Factor Color(R、G、B、A) | | :---- | :---- | -| Clear tropical blue | 0.05, 0.35, 0.80, 1.0 | -| Deep dark ocean | 0.02, 0.10, 0.25, 1.5 | -| Murky river | 0.10, 0.50, 0.30, 0.8 | -| Shallow lagoon | 0.15, 0.60, 0.70, 0.5 | -| Swamp / bog | 0.20, 0.35, 0.10, 0.4 | +| 清澈的热带蓝水 | 0.05, 0.35, 0.80, 1.0 | +| 深邃幽暗的海洋 | 0.02, 0.10, 0.25, 1.5 | +| 浑浊的河流 | 0.10, 0.50, 0.30, 0.8 | +| 浅水潟湖 | 0.15, 0.60, 0.70, 0.5 | +| 沼泽/泥潭 | 0.20, 0.35, 0.10, 0.4 | -> The colour values are in linear space. The Material Inspector displays them converted to sRGB for readability — what you see in the colour picker is approximately what you will see in-game in bright sunlight. +> 这些颜色数值处于线性空间。材质检查器会将其转换为 sRGB 以便于阅读——你在颜色选择器中看到的内容,大致就是你在明亮阳光下的游戏画面中会看到的效果。 -### Factor2 Color — Underwater Haze / Scatter Color +### Factor2 Color(因子2颜色)— 水下雾霭/散射颜色 -This is the tint of the murky glow you see when looking through shallow water at a lit surface below. Think of it as the colour of the water itself rather than what is behind it. +这是在浅水中透过水面观察下方被照亮表面时所看到的那种浑浊光晕的色调。可以将其理解为水本身的颜色,而非水后面物体的颜色。 -| Channel | What it controls | +| 通道 | 作用 | | :---- | :---- | -| **R, G, B** | The haze colour. A good starting point is a lighter, slightly greenish version of your Factor Color. | -| **A (alpha)** | How strongly the haze colour appears near the surface. 0.1–0.3 is a natural range. | +| **R、G、B** | 雾霭的颜色。一个不错的起点是采用比 Factor Color 更浅、略带绿色调的颜色。 | +| **A(透明度)** | 雾霭颜色在靠近水面处显现的强烈程度。0.1–0.3 是一个自然的取值范围。 | -**Starting points to try:** +**可尝试的起始数值:** -| Water type | Factor2 Color (R, G, B, A) | +| 水体类型 | Factor2 Color(R、G、B、A) | | :---- | :---- | -| Clear tropical blue | 0.10, 0.60, 0.50, 0.2 | -| Deep dark ocean | 0.05, 0.20, 0.40, 0.1 | -| Murky river | 0.15, 0.40, 0.20, 0.3 | -| Swamp / bog | 0.20, 0.30, 0.08, 0.35 | +| 清澈的热带蓝水 | 0.10, 0.60, 0.50, 0.2 | +| 深邃幽暗的海洋 | 0.05, 0.20, 0.40, 0.1 | +| 浑浊的河流 | 0.15, 0.40, 0.20, 0.3 | +| 沼泽/泥潭 | 0.20, 0.30, 0.08, 0.35 | -> Set Factor2 Color to a colour in the same family as Factor Color but lighter and slightly more green or cyan. Very saturated values can look unnatural. +> 将 Factor2 Color 设置为与 Factor Color 同色系但更浅、略偏绿色或青色的颜色。过于饱和的数值可能会显得不自然。 --- -## Step 4 — Tune the Scene Wave Settings +## 步骤 4 — 调整场景波浪设置 -When a custom water material override is active, the gameplay code no longer forces fixed wave parameters onto your scene. The sliders in the **Scene Inspector Water group** now have full effect. +当自定义水体材质覆盖处于激活状态时,游戏玩法代码将不再对你的场景强制施加固定的波浪参数。**场景检查器水组(Scene Inspector Water group)** 中的滑块现在将完全生效。 -| Slider | What it does | Suggested range | +| 滑块 | 作用 | 建议范围 | | :---- | :---- | :---- | -| **Strength** | Controls how energetic and tall the waves are. Higher \= choppier surface, more foam at the edges. | 0.5–3.0 for rivers and lakes; up to 6–8 for stormy coasts | -| **Choppiness** | Controls the shape of wave peaks. 0 \= smooth rolling waves, 1 \= sharp peaked waves. | 0.3–0.7 for most water bodies | -| **Wind Dependency** | How strongly the waves align with the wind direction. 0 \= waves travel in all directions equally, 1 \= waves strongly follow the wind. | 0.0–0.5 for enclosed water; 0.5–1.0 for open water | +| **Strength(强度)** | 控制波浪的能量和高度。数值越高 \= 水面越汹涌,边缘泡沫越多。 | 河流和湖泊为 0.5–3.0;暴风雨中的海岸可达 6–8 | +| **Choppiness(波浪尖锐度)** | 控制波峰的形状。0 \= 平滑的滚动波浪,1 \= 尖锐的波峰。 | 大多数水体为 0.3–0.7 | +| **Wind Dependency(风向依赖度)** | 波浪与风向对齐的强烈程度。0 \= 波浪在各个方向上均匀传播,1 \= 波浪强烈跟随风向。 | 封闭水域为 0.0–0.5;开阔水域为 0.5–1.0 | -> Without a material override, **Strength** is forced to 10 and **Wind Dependency** to 0 by the engine regardless of what you set here. The sliders only take effect when a custom material override is assigned. +> 如果没有材质覆盖,引擎会强制将 **Strength** 设为 10,将 **Wind Dependency** 设为 0,无论你在此处设置什么数值。只有在指定了自定义材质覆盖之后,这些滑块才会生效。 --- -## What Cannot Be Changed per Material +## 哪些内容无法按材质更改 -The following are driven by the engine simulation or the global render pipeline. They are the same for every non-naval water surface in every scene and cannot be overridden by changing the water material. +以下内容由引擎模拟系统或全局渲染管线驱动。它们在每个场景的每个非海战水面上都是相同的,无法通过更改水体材质来覆盖。 -- Wave normal maps and displacement (these come from the FFT water simulation) -- Caustics -- Refraction of the scene behind the water +- 波浪法线贴图与位移(这些来自 FFT 水体模拟) +- 焦散(Caustics) +- 水面背后场景的折射 --- -## Hot-Reloading in the Editor +## 编辑器中的热重载 -When you save changes to your water material while the scene is open in the editor, the engine detects the change and refreshes the water automatically within a few seconds. You do not need to reload the scene. +当你在编辑器中打开场景的同时保存对水体材质的更改时,引擎会检测到该更改,并在几秒钟内自动刷新水体效果。你无需重新加载场景。 -If the water does not update after saving the material, try toggling the **Non-Naval Water Material Override** picker off and back on to force a refresh. +如果保存材质后水体没有更新,请尝试将 **非海战水体材质覆盖(Non-Naval Water Material Override)** 选择器关闭再重新打开,以强制刷新。 --- -## Quick Checklist - -- [ ] Material shader is exactly `water_surface` -- [ ] Override field is set in the Scene Inspector Water group -- [ ] Scene is saved after setting the override -- [ ] Factor Color alpha is above 0.1 (very low values make all water look uniformly hazy) -- [ ] Factor2 Color is in the same colour family as Factor Color but lighter -- [ ] Strength and Choppiness sliders are set to the values you want (they now matter) +## 快速检查清单 +- [ ] 材质着色器精确为 `water_surface` +- [ ] 已在场景检查器的水组中设置覆盖字段 +- [ ] 设置覆盖后已保存场景 +- [ ] Factor Color 的透明度高于 0.1(数值过低会使所有水看起来均匀模糊) +- [ ] Factor2 Color 与 Factor Color 属于同一色系,但更浅 +- [ ] Strength 和 Choppiness 滑块已设置为你想要的数值(它们现在会产生实际效果) + diff --git a/docs/content/schinese/Authoring Mission Scenes/hideouts.md b/docs/content/schinese/Authoring Mission Scenes/hideouts.md index e6a7339b..55afde93 100644 --- a/docs/content/schinese/Authoring Mission Scenes/hideouts.md +++ b/docs/content/schinese/Authoring Mission Scenes/hideouts.md @@ -1,98 +1,99 @@ +++ -title = "What Makes a Hideout Scene" +title = "藏身处场景的构成要素" description = "" -weight = 1 +weight = 5 +ai_translated = true +++ -#### Introduction -This list of checkpoints should aid you in creation of hideout scenes and provide you with an insight into what we pay attention to when creating them. Unlike many other of our scenes, hideouts are only used for fighting missions and usually have a very strict one way layout. +#### 简介 +这份检查清单旨在帮助你制作藏身处场景,并让你了解我们在制作这类场景时所关注的要点。与我们的许多其他场景不同,藏身处场景仅用于战斗任务,通常具有非常严格的单向布局。 -#### Navigation Mesh -* [Works similarly to how it does with village scenes.]({{< ref "villages.md/#navigation-mesh" >}}) -* No need to have special ID’s on paths or around animal enclosures. -* Take special care to define the costs of navmeshes off the path correctly, to avoid having AI run sharply around rocks, or run through rough terrain like swamps, forests and such. +#### 导航网格 (Navigation Mesh) +* [其工作方式与村庄场景类似。]({{< ref "villages.md/#navigation-mesh" >}}) +* 路径上或动物围栏周围无需使用特殊 ID。 +* 要特别注意正确设置路径之外的导航网格的消耗值(costs),以避免 AI 紧贴岩石急转,或穿过沼泽、森林等崎岖地形。 -#### Spawn Points -##### General -* Don't use any animal spawns. +#### 生成点 (Spawn Points) +##### 概述 +* 不要使用任何动物生成点。 -##### Player Party -* Troop Prefab: **sp_hideout_group_attacker**. -* Player Prefab: **sp_player**. -* You will need a battle entry point for the players party. Make sure you have enough space around it to spawn in the other attacking troops. +##### 玩家队伍 (Player Party) +* 部队预制体:**sp_hideout_group_attacker**。 +* 玩家预制体:**sp_player**。 +* 你需要为玩家队伍设置一个战斗入口点。确保其周围有足够的空间,以便生成其余的进攻部队。  -##### Bandit Areas -* Hideout scenes are in essence a set of multiple Bandit Areas. -* Having these positions in a linear layout is generally the best idea, to avoid backtracking of players or them totally overlooking a position in general. -* Players need to clear every position for the battle to be over. -* Each Hideout Scene should contain between 6 and 8 common_area positions. - * Prefab: **common_area_x**. - * The defending bandit party will be split amongst these positions. - * Not every position is always defended (if the defender count is low). - * Make sure to have a sensible spacing in between. - * Having the positions close to each other might trigger defending agents of both positions to attack the player as they approach. - * If they are too far apart, the mission loses its pace. - * Keep in mind that the troops in most campaigns are probably going to have higher athletics than the player, hence run faster. - * You can increase the spawning radius of units by scaling the common area prefab. - * Make sure that there is some indication of where the defending units could be so that the player has a chance of finding them (especially at night). +##### 强盗区域 (Bandit Areas) +* 藏身处场景本质上是一组多个强盗区域。 +* 将这些位置按线性布局排列通常是最佳选择,以避免玩家走回头路或完全忽略某个位置。 +* 玩家必须清理每一个位置,战斗才算结束。 +* 每个藏身处场景应包含 6 到 8 个 common_area 位置。 + * 预制体:**common_area_x**。 + * 防守方的强盗队伍将被分配到这些位置之间。 + * 并非每个位置都总是有人防守(如果防守方人数较少)。 + * 确保各位置之间保持合理的间距。 + * 如果位置彼此过于靠近,可能会导致两个位置的防守单位在玩家接近时同时发起攻击。 + * 如果彼此距离过远,任务的节奏会变差。 + * 请记住,大多数战役中的部队的体能(athletics)可能高于玩家,因此跑得更快。 + * 你可以通过缩放 common area 预制体来增加单位的生成半径。 + * 确保有一些线索表明防守单位可能在哪里,以便玩家有机会找到他们(尤其是在夜间)。  -* Have around 10 to 15 spawnpoints per common area. - * Use **sp_npc_x** spawnpoints. Do not have them do chores like farming/smithing though. - * Use civilian animation points as spawn points for bandits, some suggestions: “**sp_npc_wait_wall, lookout, sp_npc_argue_set, sp_npc_wait**”. - * All spawn points in the radius will spawn bandits. +* 每个 common area 应有大约 10 到 15 个生成点。 + * 使用 **sp_npc_x** 生成点。但不要让他们做耕种/打铁之类的杂务。 + * 使用平民动画点作为强盗的生成点,一些建议:"**sp_npc_wait_wall, lookout, sp_npc_argue_set, sp_npc_wait**"。 + * 半径范围内的所有生成点都将生成强盗。  -* You can also use patrol spawnpoints: “**sp_guard_patrol_simple, sp_guard_patrol**”. - * These have a chance to spawn bandits. - * Can be used outside of the common area. +* 你也可以使用巡逻生成点:"**sp_guard_patrol_simple, sp_guard_patrol**"。 + * 这些有一定几率生成强盗。 + * 可以在 common area 之外使用。 -##### Boss Fight +##### Boss 战 (Boss Fight)  -* Prefab: **hideout_boss_fight**. -* At the end of each Hideout mission there is a boss fight. -* The position of it should be inside the last Bandit Area (common_area). Make sure that it’s likely for the player to end up around there in the normal fighting mission, so that they are not teleported around the map into a totally different area. -* How the boss fight works: - * Both parties spawn at their outer radius positions. - * They then move towards each other right up to the inner radius positions. - * You can adjust the distance between the outer and the inner radius with the "WalkDistance" property on the prefab. -* Inside the prefab you can toggle a preview of the positions. -* Make sure that the path is clear for both parties between those positions. -* Also make sure that the camera position isn't too close to other objects. - * You can’t adjust the camera in the editor, you will need to test the scene for this. - * Keep big prefabs out of the area shown by the preview and you will be fine. - -#### Soft Border -* [Works in the same manner as it does with village scenes.]({{< ref "villages.md/#soft-border" >}}) - -#### Sounds -* [Works in the same manner as it does with village scenes.]({{< ref "villages.md/#sounds" >}}) -* Make sure to not use any sounds with civilian life elements in them (like chatter, or town sounds). - -#### Lights -* [Works in the same manner as it does with village scenes.]({{< ref "villages.md/#lights" >}}) -* Take extra care that your scene works properly at night. -* Place enough torches along the paths and light up the bandit areas. +* 预制体:**hideout_boss_fight**。 +* 每个藏身处任务的结尾都有一场 Boss 战。 +* 其位置应在最后一个强盗区域(common_area)内。确保玩家在正常战斗任务中很可能会到达该附近区域,这样他们就不会被传送到地图上一个完全不同的区域。 +* Boss 战的运作方式: + * 双方队伍先在各自的外侧半径位置生成。 + * 然后双方相向移动,一直走到内侧半径位置。 + * 你可以通过预制体上的 "WalkDistance" 属性调整外侧半径与内侧半径之间的距离。 +* 在预制体内部,你可以切换这些位置的预览显示。 +* 确保两支队伍之间的路径是畅通的。 +* 同时确保摄像机位置不会离其他物体太近。 + * 你无法在编辑器中调整摄像机,需要通过实际测试场景来调整。 + * 只要将大型预制体放置在预览所显示的区域之外,就不会有问题。 + +#### 软边界 (Soft Border) +* [其工作方式与村庄场景相同。]({{< ref "villages.md/#soft-border" >}}) + +#### 声音 (Sounds) +* [其工作方式与村庄场景相同。]({{< ref "villages.md/#sounds" >}}) +* 请确保不要使用任何带有平民生活元素的声音(如闲聊声或城镇声音)。 + +#### 灯光 (Lights) +* [其工作方式与村庄场景相同。]({{< ref "villages.md/#lights" >}}) +* 要特别注意确保你的场景在夜间也能正常运作。 +* 沿路径放置足够的火把,并照亮强盗区域。  -#### Atmosphere -* [Works in the same manner as it does with village scenes.]({{< ref "villages.md/#atmosphere" >}}) +#### 氛围 (Atmosphere) +* [其工作方式与村庄场景相同。]({{< ref "villages.md/#atmosphere" >}}) -#### Gameplay Design Hints -You should keep in mind the following hints to ensure proper gameplay of your hideout scene. +#### 玩法设计提示 (Gameplay Design Hints) +你应当牢记以下提示,以确保藏身处场景拥有良好的游戏体验。 -* **Use a linear layout**. Giving the players many options for choosing paths and to experience your scene in itself is not a bad thing. Keep in mind though that the mission is designed to be linear. Bandits might or might not spawn in bandit areas or patrol paths. If your scene branches off too much the player might find themselves not knowing where the next bandit area might be or might be forced to backtrack the scene to find the remaining bandits. -* Only if all bandits are killed the mission is successful. **Your first priority should be to make sure the player finds them**. Spend extra detail & time on the navmesh on the paths and where the fights will be. -* **Make sure to keep the scene tight** so that the player doesn't accidently flank around bandit areas. Best practice is to border your scene with impassable props like cliffs, rather than with the artificial soft borders. -* **Make sure the scene works well at night**. It might be a little counterintuitive that bandits would blast hundreds of fires to light up their hideout but players will thank you for guiding them with those. -* **Take extra care to make the Bandit Boss fighting location great**. It's one of the few positions you can be sure that the player will always fight in. Also make sure that the Bandit Boss fight location is close to your last expected fighting position. -* **Focus your environmental storytelling around the paths and inside the bandit areas**. Since this mission has no civilian part, players will not have much time to explore the scene off the paths. +* **采用线性布局**。为玩家提供多种路径选择、让他们以自己的方式体验场景本身并不是坏事。但请记住,该任务被设计为线性的。强盗可能会、也可能不会在强盗区域或巡逻路径中生成。如果你的场景分支过多,玩家可能会不知道下一个强盗区域在哪里,或者被迫在场景中走回头路以寻找剩余的强盗。 +* 只有当所有强盗都被消灭后,任务才算成功。**你的首要任务是确保玩家能够找到他们**。请在路径以及将发生战斗的区域的导航网格上投入额外的精力和时间。 +* **确保场景保持紧凑**,这样玩家就不会意外地绕过强盗区域进行包抄。最佳做法是用悬崖等不可通行的道具来限定场景边界,而不是使用人为的软边界。 +* **确保场景在夜间也能良好运作**。强盗在藏身处点燃数百堆篝火来照明可能有点反直觉,但玩家会感谢你用这些篝火为他们指路。 +* **特别用心地打造强盗 Boss 战斗地点**。这是少数几个可以确定玩家一定会在此战斗的位置之一。同时确保强盗 Boss 战斗地点靠近你预期的最后一个战斗位置。 +* **将环境叙事的重点放在路径沿线和强盗区域内部**。由于该任务没有平民部分,玩家没有太多时间在路径之外探索场景。 - \ No newline at end of file + diff --git a/docs/content/schinese/Authoring Mission Scenes/villages.md b/docs/content/schinese/Authoring Mission Scenes/villages.md index 9d5d367b..cc5b8fec 100644 --- a/docs/content/schinese/Authoring Mission Scenes/villages.md +++ b/docs/content/schinese/Authoring Mission Scenes/villages.md @@ -1,205 +1,205 @@ +++ -title = "What Makes a Village Scene" +title = "村庄场景的构成要素" description = "" -weight = 3 +weight = 15 +ai_translated = true +++ -#### Introduction -This list of checkpoints should aid you in creation of village scenes and provide you with an insight into what we pay attention to when creating village scenes. - -#### Navigation Mesh - -* Navigation mesh consists of triangles and quads. It is used by the AI for pathfinding. The global illumination system also uses it to find the visible locations of the scene. -* Keep in mind that the navigation mesh faces should not be too far away from the physics below it. The distance should at 1.5m maximum. -* The faces can be labeled to give cues to the agent spawning and the navigation inside the scene. -* In order to make the agents follow roads, we label the faces on top of the roads with the ID 2. -* Note that all of the agent spawnpoints should be connected by navigation mesh faces with ID 2. -* For the animals, navigation mesh ID 3 can be used. Typically, these faces are kept within separate islands in structures like ditches. The animals will then roam inside those islands only. -* Change the ID's of all other faces to 1 (from 0). -* Remember that the agents will use the navigation mesh ID's 2. In order to create realistic pathing (on roads), scene designers should place a Navigation Mesh Deactivator (prefab name is Navigation_Mesh_Deactivator). It can be placed anywhere in the scene. Its purpose is to disable the ID 1 faces in civilian modes. The DisableFaceWithID variable of the script should be 1. -* For the animals, the variable "DisableFaceWithIDForAnimals" within the same script should be 3. -* Make sure the faces are fairly equal in size outside of the village area / where troops will maneuver. -* Make sure there are no disconnected navmeshes. -* The better the navmesh, the better will AI perform on it. Always think about that there might be big field battle inside the village. So try to avoid having many enclosed areas like a pig farm with only 1 entrance (for example: throw over some fences to create more entries) -* Avoid having big areas accessible to the player but not AI. Player will be able to shoot AI from places without navmesh. -* Use “_barrier_ai_x” to prevent AI from falling off from cliffs or getting stuck in tight areas (like a market booth) off the navmesh. +#### 简介 +这份检查清单旨在帮助你制作村庄场景,并让你了解我们在制作村庄场景时所关注的要点。 + +#### 导航网格 (Navigation Mesh) + +* 导航网格由三角形和四边形组成,AI 使用它进行寻路。全局光照系统也使用它来查找场景中的可见位置。 +* 请注意,导航网格面不应离其下方的物理碰撞体太远。最大距离应为 1.5 米。 +* 可以对这些面进行标记,为单位的生成和场景内的导航提供线索。 +* 为了让单位沿道路行走,我们将道路上方的面标记为 ID 2。 +* 请注意,所有单位生成点都应通过 ID 为 2 的导航网格面相连接。 +* 对于动物,可以使用导航网格 ID 3。通常,这些面会被保持在诸如壕沟之类的独立结构区域内。这样动物就只会在这些区域内游荡。 +* 将所有其他面的 ID 改为 1(从 0 改起)。 +* 请记住,单位会使用导航网格 ID 2。为了创造逼真的路径行走效果(在道路上),场景设计师应放置一个导航网格禁用器(Navigation Mesh Deactivator,预制体名称为 Navigation_Mesh_Deactivator)。它可以放置在场景中的任何位置。其作用是在平民模式下禁用 ID 为 1 的面。该脚本的 DisableFaceWithID 变量应设置为 1。 +* 对于动物,同一脚本中的 "DisableFaceWithIDForAnimals" 变量应设置为 3。 +* 确保村庄区域之外(即部队机动的区域)的面大小大致相等。 +* 确保没有断开连接的导航网格。 +* 导航网格质量越好,AI 的表现就越好。请始终考虑到村庄内部可能会发生大规模的野战。因此应尽量避免出现许多只有一个入口的封闭区域,例如猪圈(可以例如拆掉一些栅栏以创造更多入口)。 +* 避免出现玩家可以进入但 AI 无法进入的大面积区域。玩家将能够从没有导航网格的地方向 AI 射击。 +* 使用 "_barrier_ai_x" 来防止 AI 从悬崖上跌落,或在导航网格之外的狭小区域(例如市场摊位)中卡住。  -#### Spawn Points +#### 生成点 (Spawn Points) -As noted before, all spawn points need to be placed on top of navmesh (ID 2) and inside the soft borders. Remember that some prefabs (like chairs and benches) come with spawn points attached to them. If the spawn points aren't compatible with the village mission, they will most likely crash the game or cause errors. One example is "sp_blacksmith_with_smithing_machine". The most important thing about the entry points are their tags. They decide what type of NPC will spawn there. For your own sake, don't play around with those tags too much and keep them as they are from the prefabs. +如前所述,所有生成点都需要放置在导航网格(ID 2)之上且位于软边界内。请记住,某些预制体(如椅子和长凳)自带附加的生成点。如果生成点与村庄任务不兼容,它们很可能会导致游戏崩溃或产生错误。一个例子是 "sp_blacksmith_with_smithing_machine"。关于入口点,最重要的是它们的标签(tags),这些标签决定了哪种类型的 NPC 会在此生成。为了你自己着想,不要过多地改动这些标签,保持它们与预制体中的原样一致。  -##### Player Spawnpoint +##### 玩家生成点 (Player Spawnpoint) -* Prefab: **sp_player**. -* Make sure it's placed in a location where it can be seen from or at least has a clear path leading towards it. Do not place it too far away. -* There should be a navigation mesh under the spawnpoint. +* 预制体:**sp_player**。 +* 确保它放置在一个可以被看到、或者至少有一条清晰路径通往它的位置。不要放得太远。 +* 生成点下方应有导航网格。 -##### Battle Spawnpoints +##### 战斗生成点 (Battle Spawnpoints) -* Prefab: **Sp_battle_set**. -* Make sure the attacker and defender spawns aren't too close to each other or at least don't have direct line of sight to each other. -* Make sure to move the reinforcement point out of sight as best as possible while still not being too far from the front lines. -* Make sure all spawnpoints have some empty space around for troops to properly spawn in. - -##### Conversation Spawnpoints (civilian) - -* Prefab: **sp_player_conversation**. -* Conversation points define where the agent and the conversation partner spawn when the player enters the village via the "Talk to Notable" button from the World Map. -* Make sure they have a nice vista but keep them relatively close to the village center. - -##### Animation Points (civilian) - -* Prefab: **sp_npc_x**. -* These are used for normal villagers. You can use around 40 positions. -* They define the positions in scenes where the villagers will spawn and walk to. -* Make sure they are nicely spaced throughout the village and close surroundings. -* Villagers will wonder along paths to get to them. -* If the paths are too long you might find your villagers wondering around at all times with nobody actually doing anything. Try to avoid long distances and place points close to the main paths. -* Placing more or less spawnpoints doesn't influence how many villagers will populate the scene. - -##### Rural Noteable Spawnpoints - -* Prefab: **sp_notable_x**. -* The number of prefabs should be around 6. -* These are the spawnpoints for the notables of the village (quest givers) and lords. -* Make sure they are in a prominent location of the village or generally places where village elder / lords would hang around. -* You can check the Debug Window (documentation will cover that) to make sure you have placed the correct notable positions. -* Go to the “Scene Entity Check Tab” and tick the “NPCs” Box and count. - -##### Bandit Camps - -* Prefab: **common_area_x**. -* Each village scene has 3 Bandit Camps outside the village (place 3 prefabs), used for scene quests. -* Use the same spawns as for normal villagers (~15 per camp). Try to not have them do chores like farming. -* You can also use patrol spawnpoints: **sp_guard_patrol_simple, sp_guard_patrol”.** -* All spawn points in the radius will spawn bandits instead of villagers. -* You can increase the radius by scaling the common area prefab. -* Use civilian animation points as spawn points for bandits, some suggestions: “sp_npc_wait_wall, lookout, sp_npc_argue_set, sp_npc_wait”. -* Make sure that there is some indication to where they could be so that the player has a chance of finding them (especially at night). -* Don't place them too close to each other. +* 预制体:**Sp_battle_set**。 +* 确保进攻方和防守方的生成点彼此不要太近,或者至少彼此之间没有直接视线。 +* 确保尽可能将增援点移到视线之外,同时又不要离前线太远。 +* 确保所有生成点周围都有一些空地,以便部队能正常生成。 + +##### 对话生成点(平民) (Conversation Spawnpoints (civilian)) + +* 预制体:**sp_player_conversation**。 +* 对话点定义了当玩家通过世界地图上的"与名人交谈"按钮进入村庄时,角色与对话对象的生成位置。 +* 确保它们有不错的景观,但要让它们相对靠近村庄中心。 + +##### 动画点(平民) (Animation Points (civilian)) + +* 预制体:**sp_npc_x**。 +* 这些用于普通村民。你可以使用大约 40 个位置。 +* 它们定义了场景中村民会生成并走向的位置。 +* 确保它们在村庄及其周边区域内分布均匀。 +* 村民会沿着路径游荡到这些位置。 +* 如果路径过长,你可能会发现村民一直在四处游荡而没有真正做任何事情。尽量避免过长的距离,将这些点放置在靠近主路径的地方。 +* 放置更多或更少的生成点并不会影响场景中村民的数量。 + +##### 乡村名人生成点 (Rural Noteable Spawnpoints) + +* 预制体:**sp_notable_x**。 +* 预制体数量应约为 6 个。 +* 这些是村庄名人(任务发布者)和领主的生成点。 +* 确保它们位于村庄的显著位置,或者通常是村庄长者/领主会聚集的地方。 +* 你可以查看调试窗口(文档中会介绍)以确保正确放置了名人位置。 +* 转到 "场景实体检查标签页 (Scene Entity Check Tab)",勾选 "NPCs" 复选框并进行计数。 + +##### 强盗营地 (Bandit Camps) + +* 预制体:**common_area_x**。 +* 每个村庄场景在村外有 3 个强盗营地(放置 3 个预制体),用于场景任务。 +* 使用与普通村民相同的生成点(每个营地约 15 个)。尽量不要让他们做诸如耕种之类的杂务。 +* 你也可以使用巡逻生成点:**sp_guard_patrol_simple, sp_guard_patrol**。 +* 半径范围内的所有生成点将生成强盗而非村民。 +* 你可以通过缩放公共区域预制体来增大半径。 +* 使用平民动画点作为强盗的生成点,一些建议:"sp_npc_wait_wall, lookout, sp_npc_argue_set, sp_npc_wait"。 +* 确保有一些线索表明他们可能在哪里,以便玩家有机会找到他们(尤其是在夜间)。 +* 不要把它们放得太靠近彼此。  -##### Animal Spawnpoints +##### 动物生成点 (Animal Spawnpoints) -* Prefab: **sp_animalName**. -* Use “DisableWandering” in the AnimalSpawnSettings script, to stop animals from walking around your scene. -* Overall its best to put it on all bigger animals like cows and pigs if they aren't there to wonder around. +* 预制体:**sp_animalName**。 +* 在 AnimalSpawnSettings 脚本中使用 "DisableWandering",以阻止动物在你的场景中四处走动。 +* 总体而言,最好对所有不需要四处游荡的较大型动物(如牛和猪)启用此选项。 -##### Tactical Region +##### 战术区域 (Tactical Region) -* Prefab: **TacticalRegion**. -* Used to tell the AI where there are relevant bigger regions (forests, hills etc.). -* AI will position themselves inside the radius or avoid it. -* Don't overuse it, stick to ~5 (make sure there is some variety). +* 预制体:**TacticalRegion**。 +* 用于告知 AI 哪里存在相关的较大区域(森林、山丘等)。 +* AI 会在该半径范围内就位,或避开该区域。 +* 不要过度使用,保持在约 5 个左右(确保有一定的多样性)。 -##### Tactical Positions +##### 战术位置 (Tactical Positions) -* Prefab: **TacticalPosition**. -* Used to tell the AI where there are relevant smaller positions (like choke points between buildings, cliffs for archers and so on). -* AI will position themselves according to the rotation of the Prefab and in regards to the width given by the script. -* You can use them quite often. -* The higher the slope the “better” is the position. +* 预制体:**TacticalPosition**。 +* 用于告知 AI 哪里存在相关的较小位置(例如建筑物之间的瓶颈、适合弓箭手的悬崖等)。 +* AI 会根据预制体的旋转方向以及脚本给定的宽度来确定自身位置。 +* 你可以相当频繁地使用它们。 +* 坡度越大,该位置就"越好"。  -##### Flee Positions +##### 逃跑位置 (Flee Positions) -* Positions to which fleeing troops and also horses will run away too. -* Make sure they are inside the Soft Border and that there is a navmesh below them. +* 溃逃的部队以及马匹会逃向的位置。 +* 确保它们位于软边界内,并且下方有导航网格。  -#### Debug Window +#### 调试窗口 (Debug Window) -* Prefab: **SpawnPointDebugView**. -* There is a built-in debug tool which can be enabled by adding the above prefab to the scene. Place the prefab anywhere in the scene and activate the window with the check box in its script. -* This prefab opens a little debug window in the editor that helps you make sure you meet the requirements for the mission (like spawn points, navmesh). -* In the “Scene Entity Check Tab” you can count your Entry Points and make sure you have placed enough of them (or too many). -* In the “Navigation Mesh Check Tab” you can make sure all your Entry Points are connected to the navmesh properly. +* 预制体:**SpawnPointDebugView**。 +* 有一个内置的调试工具,可以通过将上述预制体添加到场景中来启用。将预制体放置在场景中的任意位置,并通过其脚本中的复选框激活该窗口。 +* 该预制体会在编辑器中打开一个小型调试窗口,帮助你确保满足任务的各项要求(如生成点、导航网格)。 +* 在 "场景实体检查标签页" 中,你可以统计入口点的数量,确保放置了足够数量(或没有放置过多)。 +* 在 "导航网格检查标签页 (Navigation Mesh Check Tab)" 中,你可以确保所有入口点都正确连接到导航网格。  -#### Soft Border +#### 软边界 (Soft Border) -* Prefab: **border_soft**. -* They define the red borders of the scene. -* When placed they form a polygon where the 2 edges connect between the closest two border entities (but never more than two). -* To check the current borders, go into the "Visibility Window" → "Visibility Masks" and enable "Borders". -* After crossing them the player has a few seconds to return inside the map borders, make sure this can't be abused somehow. +* 预制体:**border_soft**。 +* 它们定义了场景的红色边界。 +* 放置后,它们会在最接近的两个边界实体之间(但绝不会超过两个)形成一个多边形的两条边。 +* 要查看当前边界,进入 "可见性窗口 (Visibility Window)" → "可见性遮罩 (Visibility Masks)",并启用 "Borders"。 +* 玩家越过边界后会有几秒钟的时间返回地图边界内,请确保这一机制不会被以某种方式滥用。  -#### Sounds +#### 声音 (Sounds) -##### Master Ambient Sound +##### 主环境音效 (Master Ambient Sound) -* Prefab: **x_ambient_sound**. -* Choose a mandatory master ambient sound. -* You can place the prefab for the mandatory ambient sound anywhere. -* Make sure it has the “Is Master Sound” enabled. -* Make sure it doesn't have the “Is Triggered” enabled. +* 预制体:**x_ambient_sound**。 +* 选择一个必需的主环境音效。 +* 你可以将必需环境音效的预制体放置在任意位置。 +* 确保已启用 "Is Master Sound"。 +* 确保未启用 "Is Triggered"。 -##### Additional Ambient sounds +##### 附加环境音效 (Additional Ambient sounds) -* Used for bigger areas (like forests). -* Needs to have the “Is Triggered” bool. -* To see how far it reaches, from the "Visibility Window" enable "Sound Entities" under the ""Visibility Masks" group. -* To change their reach, you can scale them like you would do with other editor entities (using the “b” key or the gizmo). +* 用于较大区域(如森林)。 +* 需要启用 "Is Triggered" 布尔值。 +* 要查看其覆盖范围,可在 "可见性窗口" 中的 "可见性遮罩 (Visibility Masks)" 分组下启用 "Sound Entities"。 +* 要更改其覆盖范围,可以像处理其他编辑器实体一样对其进行缩放(使用 "b" 键或变换操纵器)。  -##### Reverb +##### 混响 (Reverb) -* There are different prefabs for each use case: **reverb_x**. -* Adds reverb effect to any sound spawned inside its boundary. -* They are generally used for tight or underground areas. -* You can place these in tight alleys between taller buildings, cliffs, in caves or in dense forests. -* Needs to have the “Is Triggered” enabled. +* 每种使用场景都有不同的预制体:**reverb_x**。 +* 为在其边界内生成的任何声音添加混响效果。 +* 它们通常用于狭窄或地下区域。 +* 你可以将它们放置在较高建筑之间的狭窄巷道、悬崖、洞穴或茂密的森林中。 +* 需要启用 "Is Triggered"。 -##### Detail +##### 细节音效 (Detail) -* Used for small details. -* Make sure “Is Triggered” is disabled. -* Place them where ever you want them to play. +* 用于小型细节。 +* 确保禁用 "Is Triggered"。 +* 可以放置在你希望它们播放的任何地方。 -##### Moving sounds on paths (for rivers and such) +##### 沿路径移动的声音(用于河流等) (Moving sounds on paths (for rivers and such)) -Sometimes it's useful to move sounds along a coast line or a river. The below technique is more performance-friendly and more precise than placing multiple sound entities along your river for example. +有时沿海岸线或河流移动声音会很有用。以下技术比沿河流放置多个声音实体更高效、更精确。 -* Place a path on the river. For more information, see [Path Editing]({{< ref "path_editing.md" >}}). -* Add the sound to the scene. -* Place any additional Ambient sound as explained above. -* Add the “path_converger” script to your ambient sound's entity. -* Enter the name of your path to the "path_converger". -* The sound will now follow the path according to the camera position. +* 在河流上放置一条路径。更多信息请参阅 [路径编辑]({{< ref "path_editing.md" >}})。 +* 将声音添加到场景中。 +* 按上文所述放置任何附加环境音效。 +* 将 "path_converger" 脚本添加到你的环境音效实体中。 +* 在 "path_converger" 中输入你的路径名称。 +* 现在声音将根据摄像机位置沿路径移动。 -##### Sounds in the Engine +##### 引擎中的声音 (Sounds in the Engine) -You can check the "MODDING_TOOLS_DIRECTORY/Sounds/GUIDs.txt" file for the list of the sounds in the game. These names can be used inside the script of the sound entities. +你可以查看 "MODDING_TOOLS_DIRECTORY/Sounds/GUIDs.txt" 文件以获取游戏中声音的列表。这些名称可以在声音实体的脚本中使用。 -#### Lights +#### 灯光 (Lights) -* Have at least one “**envmap_prop**” in your scene. -* For darker areas like caves use “**local_envmap_prop**”. -* It will affect the lighting in an area depending on the values of its “ReflectionCapturer” script. -* Make sure the village and bandit camps are nicely lit. -* Take extra care for the conversation points. -* Use torches and other entities. -* Make sure torches inside buildings and other dark areas have “alwaysBurn” enabled in the LightCycle script. -* Try to avoid placing “artificial lights” without an actual source. -* You can bake the ambient lighting in your scene with the GI system. This will make the ambient lighting much more realistic. For more information, see [GI System]({{< ref "prt.md" >}}). +* 场景中至少要有一个 "**envmap_prop**"。 +* 对于洞穴等较暗区域,使用 "**local_envmap_prop**"。 +* 它会根据其 "ReflectionCapturer" 脚本的值影响该区域的光照。 +* 确保村庄和强盗营地的照明充足美观。 +* 对对话点要格外留意。 +* 使用火把及其他实体。 +* 确保建筑物内部及其他黑暗区域的火把在 LightCycle 脚本中启用了 "alwaysBurn"。 +* 尽量避免放置没有实际光源的"人为光源"。 +* 你可以使用 GI 系统烘焙场景中的环境光照,这将使环境光照更加逼真。更多信息请参阅 [GI 系统]({{< ref "prt.md" >}})。  -#### Atmosphere +#### 氛围 (Atmosphere) -* Make sure your scene works and looks fine with all of the “**TOD_x**” atmospheres and in all seasons! (since it will be tested with those). -* Choose a “Color Grade” that fits your scene (we suggest using the ones for the faction your scene is for, like: “color_grade_empire_soft”). +* 确保你的场景在所有 "**TOD_x**" 氛围及所有季节下都能正常运作且外观良好!(因为将在这些条件下进行测试。) +* 选择适合你场景的 "调色分级 (Color Grade)"(我们建议使用适合场景所属阵营的调色分级,例如:"color_grade_empire_soft")。  - diff --git a/docs/content/schinese/BestPractices/merging_module_xml_files_with_native.md b/docs/content/schinese/BestPractices/merging_module_xml_files_with_native.md index 9e631673..3a614808 100644 --- a/docs/content/schinese/BestPractices/merging_module_xml_files_with_native.md +++ b/docs/content/schinese/BestPractices/merging_module_xml_files_with_native.md @@ -1,31 +1,32 @@ +++ -title = "Merging Module XML Files with Native" +title = "将模块XML文件与原生数据合并" +ai_translated = true [menu.main] identifier = "merging_module_xml_files_with_native" parent = "bestpractices" +++ -With Bannerlord v1.3, we have implemented an XML merging algorithm that assists in merging XML files defined in other modules' module data without using XSLT. We can add new elements to the XMLs or change some attributes during merging, using their unique attributes and other information gathered from XSDs. Follow these steps to enable the merging algorithm: +在Bannerlord v1.3中,我们实现了一种XML合并算法,可以在不使用XSLT的情况下,帮助将其他模块的模块数据中定义的XML文件进行合并。我们可以在合并过程中添加新元素或更改某些属性,这些操作会利用这些元素的唯一属性以及从XSD中收集到的其他信息。请按照以下步骤启用合并算法: -1. Create an XML file that needs to be merged with the base game -2. Add new elements with the content of the mod; they will be added to the appropriate places in the final merged XML file that is going to be used by the game -3. Change elements that are already present in the base game +1. 创建一个需要与基础游戏合并的XML文件 +2. 添加包含模组内容的新元素;它们将被添加到最终合并后的XML文件中的相应位置,该文件将被游戏使用 +3. 更改基础游戏中已经存在的元素 -In the engine, merging of native and other modules' data is done in two ways. +在引擎中,原生数据与其他模块数据的合并有两种方式。 -## Merging for Native +## 与原生数据的合并 -These are the XML files that start with "soln". In ModuleData, they are defined in the "project.mbproj" file. +这些是以"soln"开头的XML文件。在ModuleData中,它们在"project.mbproj"文件中定义。 -In the following code, we can see that this module registers: +在下面的代码中,我们可以看到该模块注册了: -* action_sets -* action_types -* movement_sets -* full_movement_sets -* combat_system -* skins +* action_sets(动作集) +* action_types(动作类型) +* movement_sets(移动集) +* full_movement_sets(完整移动集) +* combat_system(战斗系统) +* skins(皮肤) ```xml @@ -42,11 +43,11 @@ In the following code, we can see that this module registers: ``` -These files are automatically found by the system and merged with native. +系统会自动找到这些文件并将其与原生数据合并。 -## Managed XML Files +## 托管XML文件 -The other kind of merging is done with managed XML files such as items.xml, heroes.xml, and settlements.xml. They are defined in the SubModule.xml file located at the module's root. Here's an example of a SubModule file: +另一种合并方式是针对托管XML文件进行的,例如items.xml、heroes.xml和settlements.xml。它们在位于模块根目录的SubModule.xml文件中定义。以下是一个SubModule文件的示例: ```xml @@ -75,9 +76,9 @@ The other kind of merging is done with managed XML files such as items.xml, hero ``` -In the above example, we have registered an XMLNode to the game with the id="Items". So when we need merging, items.xml from the base game will merge with the items.xml from the mod. The only thing that needs to be done is to implement the items.xml file as usual, and they will be merged. +在上面的示例中,我们已经向游戏注册了一个id="Items"的XMLNode。因此,当需要进行合并时,基础游戏中的items.xml将与模组中的items.xml合并。唯一需要做的就是像往常一样实现items.xml文件,它们就会被自动合并。 -Let's have a look at the Torch item located in the native "items.xml": +让我们看看位于原生"items.xml"中的火把(Torch)物品: ```xml ``` -We can change some properties of this item by rewriting it in our own module. When the merge algorithm runs, it searches through the XML file and looks at the "unique" attributes of that element (which is "id" in this case). If a unique attribute is found, that element is changed, and if it is not found, the new item is added to the XML file. Let's say we wanted to change the above Torch item, which has the following unique attribute id: "torch". We want to make it available in shops, change its swing_damage to 9, and set the DropOnWeaponChange flag to false. We would insert the following code into our module's items.xml: +我们可以通过在自己的模块中重写该物品来更改它的某些属性。当合并算法运行时,它会遍历XML文件并查看该元素的"唯一"属性(在本例中为"id")。如果找到唯一属性,则会更改该元素;如果没有找到,则会将新物品添加到XML文件中。假设我们想更改上面的Torch物品,它的唯一属性id为"torch"。我们希望让它在商店中可用,将其swing_damage更改为9,并将DropOnWeaponChange标志设置为false。我们需要在模块的items.xml中插入以下代码: ```xml ``` -The algorithm then searches through the items and finds an item with a unique attribute that is already present in native files. It then starts the merging process. This is the resulting item: +然后,算法会遍历所有物品,找到一个在原生文件中已经存在相同唯一属性的物品。接着,它开始进行合并处理。这是合并后的结果物品: ```xml ``` -For each XML file, there is an XSD schema file that gives information about the structure of the XML file. The XSD files are located in the XmlSchemas folder. These files also tell us which attributes of an element are unique attributes. And there are some elements where the algorithm always prefers merging. In the XML files above, if we look at the corresponding XSD schemas, we will see that for the element "Item", the unique attribute is "id", for the element "ItemComponent", we should always prefer merging because it is restricted that there is only one "ItemComponent" element for each "Item". All these information is read from the xsd files by the algorithm. For example, let's look at the xsd schema of "ShipHulls": +对于每个XML文件,都有一个XSD模式文件,提供关于该XML文件结构的信息。XSD文件位于XmlSchemas文件夹中。这些文件还会告诉我们元素的哪些属性是唯一属性。而且有一些元素,算法总是更倾向于进行合并。在上面的XML文件中,如果我们查看相应的XSD模式,会发现对于元素"Item",唯一属性是"id";对于元素"ItemComponent",我们应该总是优先进行合并,因为规定每个"Item"只能有一个"ItemComponent"元素。所有这些信息都是算法从xsd文件中读取的。例如,让我们看一下"ShipHulls"的xsd模式: ```xml @@ -244,7 +245,7 @@ For each XML file, there is an XSD schema file that gives information about the ``` -In the schema above, we can see that "xs:unique" elements tells us which attributes of the element specified with "xpath" are unique. For example lets look at: +在上面的模式中,我们可以看到"xs:unique"元素告诉我们由"xpath"指定的元素的哪些属性是唯一的。例如,让我们看看: ```xml @@ -254,7 +255,7 @@ In the schema above, we can see that "xs:unique" elements tells us which attribu ``` -This tells that, "id" attribute of an element "ShipHull" is unique. So, the merging algorithm checks this "id" field while merging. There are also some annotations that can be seen in the xsd files such as: +这表明元素"ShipHull"的"id"属性是唯一的。因此,合并算法在合并时会检查这个"id"字段。在xsd文件中还可以看到一些注解,例如: ```xml @@ -265,4 +266,4 @@ This tells that, "id" attribute of an element "ShipHull" is unique. So, the merg ``` -This tells us that an "AvailableSlots" element occurs only once in its parent and when the algorithm encounters an "AvailableSlots" item while modifying the parent item with merging, it knows that the "AvailableSlots" present in the other element that we are trying to merge directly merges with the existing "AvailableSlots" without resulting in two "AvailableSlots" elements. Elements that are annotated like this do not have unique id's as well because we don't need one. +这告诉我们"AvailableSlots"元素在其父元素中只出现一次,当算法在对父项进行合并修改时遇到"AvailableSlots"项时,它知道我们试图合并的另一个元素中存在的"AvailableSlots"会直接与现有的"AvailableSlots"合并,而不会产生两个"AvailableSlots"元素。以这种方式注解的元素也不需要唯一id,因为我们不需要它。 diff --git a/docs/content/schinese/BestPractices/scene_performance_guide.md b/docs/content/schinese/BestPractices/scene_performance_guide.md index a0372592..15a4ae24 100644 --- a/docs/content/schinese/BestPractices/scene_performance_guide.md +++ b/docs/content/schinese/BestPractices/scene_performance_guide.md @@ -1,5 +1,6 @@ +++ -title = "Scene Performance Guide" +title = "场景性能指南" +ai_translated = true [menu.main] identifier = "scene_performance" @@ -7,40 +8,40 @@ parent = "bestpractices" +++ -##### Performance Requirements of Mount & Blade II: Bannerlord -- Singleplayer Scenes: Very High Config / 60 FPS / Gtx 1060. -- Multiplayer Scenes: Very High Config / 60 FPS / Gtx 970. +##### 《骑马与砍杀2:领主》的性能要求 +- 单人场景:极高配置 / 60 FPS / GTX 1060。 +- 多人场景:极高配置 / 60 FPS / GTX 970。 {{% notice warning %}} -Do not test the final performance of your scene in the Scene Editor. Editor has low performance due to being editable at runtime. Also, you should check the final performance with the agents in the mission. +请勿在场景编辑器(Scene Editor)中测试场景的最终性能。由于编辑器在运行时是可编辑的,因此其性能较低。此外,你还应该在任务中有代理(agents)的情况下检查最终性能。 {{% /notice %}} -#### Possible Performance Bottlenecks +#### 可能的性能瓶颈 -##### Missing occluders -Occluders are physical objects that define occlusion boundaries for meshes. If an object’s bounding box is fully occluded by an occluder, those objects are not rendered. Occluders drastically reduce the performance problems of wide and large scenes. At runtime, all of the occluders are rendered to a different screen and the depth values of every pixel in this screen is checked with every mesh' bounding box. In your scene, all of the building blocks and big meshes should have occluders. If the “Enable Occlusion Culling” and “Show Occluders” options are enabled from the “Visibility” tab, the occluders of every mesh are rendered with debug meshes. If any of the big meshes in your scene has missing occluders, you should contact the ART team. +##### 缺少遮挡体(Occluders) +遮挡体(Occluders)是定义网格遮挡边界的物理对象。如果一个物体的包围盒完全被遮挡体遮挡,那么这些物体将不会被渲染。遮挡体可以大幅减少宽阔及大型场景的性能问题。在运行时,所有遮挡体都会被渲染到一个单独的屏幕上,并将该屏幕中每个像素的深度值与每个网格的包围盒进行比对。在你的场景中,所有建筑模块和大型网格都应该拥有遮挡体。如果在"可见性(Visibility)"选项卡中启用了"启用遮挡剔除(Enable Occlusion Culling)"和"显示遮挡体(Show Occluders)"选项,每个网格的遮挡体都会以调试网格的形式渲染出来。如果场景中任何大型网格缺少遮挡体,你应该联系美术(ART)团队。 -##### Too much pointlight overdraw & unnecessary shadow maps -Our engine uses a grid based point light rendering system. This system divides the screen into fixed size grids. Then, the visible point lights are registered to every grid in which it’s bounding box intersects. Then, every shaded pixel in the screen uses all of the point lights inside its tile to shade itself. Every pointlight in your scene should have the minimum possible radius. Also, to not increase the overdraw, you should not use too many point lights. You can use the “Debug Tiled Lights” debug renderer to fix issues like too much point light in tight spots or lights with high radius. If there are any grid tiles with yellowish or red color, than those tiles probably have low performance. Those areas of the scene should be re-adjusted by either decreasing the point light radiuses or decreasing the point light count. +##### 过多的点光源过度绘制(Overdraw)与不必要的阴影贴图 +我们的引擎使用基于网格的点光源渲染系统。该系统将屏幕划分为固定大小的网格。然后,可见的点光源会被注册到其包围盒相交的每个网格中。接着,屏幕中每个被着色的像素都会使用其所在网格内的所有点光源进行着色。场景中的每个点光源都应具有尽可能小的半径。此外,为了不增加过度绘制(overdraw),你不应使用过多的点光源。你可以使用"调试平铺光源(Debug Tiled Lights)"调试渲染器来修复诸如狭小空间中点光源过多或光源半径过大等问题。如果有任何网格块显示为黄色或红色,那么这些区域的性能可能较低。场景中的这些区域应通过减少点光源半径或减少点光源数量来进行重新调整。 -##### Outer Areas Flora Usage -The grass like flora that we use in our scenes has a limited viewing range. Also, we can cull out (decide to not render) these floras in high ranges. However, this flora will have a major memory impact in the scenes, also there will be a mild CPU culling cost as well. Thus, for the outer areas where the grass would not be rendered, you should not use terrain layers with high grass density. +##### 外围区域植被(Flora)的使用 +我们在场景中使用的类似草地的植被(flora)具有有限的可视范围。此外,我们可以在较远距离剔除(决定不渲染)这些植被。然而,这些植被会对场景产生较大的内存影响,同时也会带来一定的CPU剔除开销。因此,对于那些不会渲染草地的外围区域,你不应使用具有高草密度的地形图层。 -##### Too many meshes without LOD’s -For modern GPUs, performance wise, polygon density per pixel is much more important than the total polygon count. In this case, the worst situation are meshes without LOD. This can be checked by switching into wireframe mode. Every triangle in the scene should contain a healthy amount of pixels inside, not the other way around. You should contact the ART team if you find a mesh without LOD’s. +##### 过多没有LOD的网格 +对于现代GPU而言,从性能角度看,每像素的多边形密度远比多边形总数更重要。在这种情况下,最糟糕的情况就是没有LOD的网格。你可以通过切换到线框模式来检查这一点。场景中的每个三角形内部都应包含适量的像素,而不是相反的情况。如果你发现没有LOD的网格,应联系美术(ART)团队。 -##### Terrain LOD Multiplier and Vertex Density -Always check your terrain vertex density. In many cases, the terrain resolution can be reduced without any noticeable change. Also, try not to use terrain LOD multiplier for terrain nodes. Having more nodes and only using terrain LOD multiplier in nodes with detailed curvature will increase your scene's performance. Terrain LOD multiplier should be set accordingly, preferably **not over 3**. +##### 地形LOD倍增器与顶点密度 +请始终检查你的地形顶点密度。在很多情况下,地形分辨率可以在不产生明显变化的情况下降低。另外,尽量不要在地形节点中使用地形LOD倍增器。拥有更多节点,并仅在具有精细曲率的节点中使用地形LOD倍增器,将会提升场景的性能。地形LOD倍增器应设置得当,最好**不超过3**。 -##### Vertex / Meter Ratio -Vertex / Meter ratio should be **at most 1.8**. +##### 顶点/米 比率 +顶点/米比率应**最多为1.8**。 -##### Nodes & & Dimensions -There should be **at least 10 nodes** in each dimension for better LOD management by the engine. Each dimension should be **no more than 1.6 km wide** (total width of the scene). Beyond that, outer meshes can be used to give the feeling of a large landscape. +##### 节点与维度 +为了让引擎更好地管理LOD,每个维度应**至少有10个节点**。每个维度(场景总宽度)应**不超过1.6公里宽**。超出此范围时,可以使用外部网格来营造广阔地貌的感觉。 -##### Outer Terrain Nodes -Outer terrain nodes that the player can't access, with respect to their complexity, should have a lower vertex density than the center ones. +##### 外围地形节点 +玩家无法到达的外围地形节点,根据其复杂程度,应比中心区域的节点具有更低的顶点密度。 -##### Terrain Flora Density -Terrain flora density should in general **not exceed 60** apart from certain cases (low polycount flora, for example, flora_reed_X or flora_dry_plant_f). That value is recommended when no colony setting is used(radius=0, threshold=0). Colony system works by removing flora which reduces visible density. \ No newline at end of file +##### 地形植被密度 +除某些特殊情况外(低多边形数量的植被,例如flora_reed_X或flora_dry_plant_f),地形植被密度通常**不应超过60**。该数值是在未使用群落(colony)设置时(radius=0, threshold=0)的推荐值。群落系统通过移除植被来降低可见密度。 diff --git a/docs/content/schinese/BestPractices/sealed_class_extension.md b/docs/content/schinese/BestPractices/sealed_class_extension.md index e8822ef1..319954bc 100644 --- a/docs/content/schinese/BestPractices/sealed_class_extension.md +++ b/docs/content/schinese/BestPractices/sealed_class_extension.md @@ -1,5 +1,6 @@ +++ -title = "Sealed Class Extension" +title = "密封类(Sealed Class)的扩展" +ai_translated = true [menu.main] identifier = "sealed_class_extension" @@ -7,17 +8,17 @@ parent = "bestpractices" +++ -It has been brought to our attention that a workaround to extend sealed classes is requested by some of our modders. In this article we will be exploring why there are sealed classes in the game codes and how to achieve extended behavior for them. +我们注意到,一些模组制作者希望找到一种变通方法来扩展密封类(sealed class)。在本文中,我们将探讨为什么游戏代码中存在密封类,以及如何为它们实现扩展行为。 -One of the main reasons we have made fundamental classes sealed is to allow the codebase to support a broad range of mods that can operate simultaneously as best as possible. In order to achieve this, and as software engineering principles dictate, we encourage mods to be built as self contained, modular extensions to the code such as Campaign Behaviors, Game Models and custom classes or components, that can be added or removed without any complications. Inheriting from core campaign classes increases the likelihood of conflicts with other mods and future official updates by changing class hierarchies and may lead to custom tailored alterations to fundamental game logic. Although it is possible to write careful code that avoids these issues, we decided to adhere to these standards in our codebase and reduce the possibility of conflict from either internal or external sources altogether. +我们将基础类设为密封类的主要原因之一,是为了让代码库能够尽可能好地支持可以同时运行的广泛模组。为了实现这一点,并且按照软件工程原则的要求,我们鼓励将模组构建为独立的、模块化的代码扩展,例如 Campaign Behaviors(战役行为)、Game Models(游戏模型)或自定义类/组件,这些扩展可以在不产生任何复杂问题的情况下添加或移除。从核心战役类继承会通过改变类层次结构增加与其他模组及未来官方更新发生冲突的可能性,并可能导致对基础游戏逻辑进行定制化的改动。尽管编写谨慎的代码是可以避免这些问题的,但我们仍决定在我们的代码库中坚持这些标准,从而从根本上降低来自内部或外部来源的冲突可能性。 -When it comes to achieving extended behavior for sealed classes without inheritance, although various workarounds might be explored, one possible solution is discussed below. +说到在不使用继承的情况下为密封类实现扩展行为,虽然可以探索多种变通方法,但下面将讨论其中一种可能的解决方案。 -In essence, when the problem of extending sealed classes is broken-down, there are two main requirements to address, namely adding new behavior and adding new properties. +从本质上讲,当我们拆解扩展密封类这一问题时,有两个主要需求需要解决,即添加新行为和添加新属性。 -In order to add new behavior to sealed classes, a C# feature called “extension methods” can be utilized. In a nutshell, it enables you to add new methods to any class without deriving a new type or modifying the original one. For more information on extension methods, you can visit [here](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods). +为了给密封类添加新行为,可以利用一个名为"扩展方法(extension methods)"的 C# 特性。简而言之,它使你能够在不派生新类型或修改原始类型的情况下,为任意类添加新方法。有关扩展方法的更多信息,你可以访问[此处](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods)。 -Adding a new property can be achieved by associating a sealed class instance with a corresponding property value using a dictionary. When combined with extension methods, the sealed class can provide the interface to the new property as if it was added directly to the class. +添加新属性可以通过使用字典(dictionary)将密封类的实例与对应的属性值关联起来实现。当与扩展方法结合使用时,密封类就可以提供一个接口,使新属性看起来就像是直接添加到该类中一样。 ```C# public class HeroManaExtensionCampaignBehavior : CampaignBehaviorBase @@ -64,4 +65,5 @@ Adding a new property can be achieved by associating a sealed class instance wit ``` -While this solution is a viable workaround to extend sealed classes, it is important to remember that each project has different requirements and consequently you should explore what approach works best for your code. +虽然这种解决方案是扩展密封类的一种可行的变通方法,但重要的是要记住,每个项目的需求都不尽相同,因此你应该探索哪种方法最适合你的代码。 + diff --git a/docs/content/schinese/BestPractices/xml_editor.md b/docs/content/schinese/BestPractices/xml_editor.md index 133a90a1..d2b636a5 100644 --- a/docs/content/schinese/BestPractices/xml_editor.md +++ b/docs/content/schinese/BestPractices/xml_editor.md @@ -1,124 +1,126 @@ +++ -title = "Getting Started with XML Editor" +title = "XML 编辑器入门" +ai_translated = true [menu.main] identifier = "xml_editor" parent = "bestpractices" +++ -#### Module -Bannerlord consists of different modules, which give it different functionality. You can think of them as game mods. This approach allows players to easily mod the game. The modules are inside the Mount & Blade II Bannerlord installation folder, called `Modules`. +#### 模组(Module) +Bannerlord 由多个不同的模块(Module)组成,它们赋予了游戏不同的功能。你可以把它们看作是游戏的模组(mod)。这种方式让玩家可以轻松地对游戏进行修改。这些模块位于 Mount & Blade II Bannerlord 安装目录下的 `Modules` 文件夹中。 #### XML -XML stands for E**x**tensible **M**arkup **L**anguage, which allows the storage of data related to the game. If we want to add some data to a Module, we would create an XML document within it, or add it to an existing XML document. -#### XSD (Schema files) -XSD stands for **X**ML **S**chema **D**efinition. It allows for a validation layer for data that is provided through XML files. Each XML file in Bannerlord has a related schema file. For example, schema files provide a schema for a culture object, and it looks something like this: +XML 的全称是 E**x**tensible **M**arkup **L**anguage(可扩展标记语言),用于存储与游戏相关的数据。如果我们想向某个模块添加数据,就需要在其中创建一个 XML 文档,或者将数据添加到已有的 XML 文档中。 +#### XSD(架构文件) +XSD 的全称是 **X**ML **S**chema **D**efinition(XML 架构定义)。它为通过 XML 文件提供的数据提供了一层验证机制。Bannerlord 中的每个 XML 文件都有一个相关联的架构(schema)文件。例如,架构文件为文化(culture)对象提供了一个架构,大致如下所示: -- Culture - - Name - - Id - - Description - - … +- Culture(文化) + - Name(名称) + - Id(标识符) + - Description(描述) + - …… -As you can see, these files are schema for how we are going to structure our XML files. 99% of the time, the XML editor prevents you from making a change that is not allowed in the schema files. If, by any chance, you make a change that makes the XML file not fit the schema file, you are going to get an error while saving the file, thus allowing you to fix your mistake. +正如你所看到的,这些文件规定了我们应该如何构建 XML 文件的结构。在 99% 的情况下,XML 编辑器会阻止你进行架构文件中不允许的更改。如果你碰巧做出了与架构文件不匹配的更改,那么在保存文件时会出现错误提示,从而让你能够修正错误。 #### XSLT -XSLT stands for E**x**tensible **S**tylesheet **L**anguage **T**ransformations. It allows for the transformation of existing XML files into new ones, based on the defined rules. These rules get applied to the XML files when they are being loaded into the game. +XSLT 的全称是 E**x**tensible **S**tylesheet **L**anguage **T**ransformations(可扩展样式表语言转换)。它允许根据定义的规则,将现有的 XML 文件转换为新的 XML 文件。这些规则会在 XML 文件被加载进游戏时应用。 -Example use case: Assume that we would like to make changes for some culture in the game, but they are defined in one of the official modules. We cannot directly open and edit the official module, as that change will no longer be part of our own module. +示例用例:假设我们想对游戏中的某个文化进行修改,但它是在某个官方模块中定义的。我们不能直接打开并编辑官方模块,因为那样的更改将不再属于我们自己的模块。 -Therefore, instead of changing the XML file, we create rules with XSLT inside our own module, which transform the existing XML file in the related official module. +因此,我们不直接修改该 XML 文件,而是在我们自己的模块中使用 XSLT 创建规则,以转换相关官方模块中现有的 XML 文件。 -#### Getting Started with XML Editor -The XML Editor is a program that allows you to: +#### XML 编辑器入门 +XML 编辑器是一款可以让你执行以下操作的程序: -- Edit your module’s XML files with schema-aware validation that prevents invalid changes. -- Safely modify official and other module data via XSLT, generating non-destructive transformation rules. - - Accomplish the above two steps through UI rather than text editors. +- 通过具有架构感知能力的验证来编辑你模块的 XML 文件,防止无效的更改。 +- 通过 XSLT 安全地修改官方模块和其他模块的数据,生成非破坏性的转换规则。 + - 通过界面(UI)而非文本编辑器来完成上述两个步骤。 -You can access the XML Editor through the `Mount & Blade II: Bannerlord Modding Kit` on Steam. After installing the Kit, you’ll find the XML Editor inside the `XMLEditor` folder in the game’s root directory. +你可以通过 Steam 上的 `Mount & Blade II: Bannerlord Modding Kit` 访问 XML 编辑器。安装 Kit 后,你会在游戏根目录下的 `XMLEditor` 文件夹中找到 XML 编辑器。 -Starting the XML editor for the first time, you will be asked to adjust the settings for the editor. Choose yes, and you will see the settings window. +首次启动 XML 编辑器时,系统会要求你调整编辑器的设置。选择「是」,你将看到设置窗口。 -First, you need to select your game folder. It defaults to the Steam version of the game. Other settings are optional, and you can leave them as they are. +首先,你需要选择你的游戏文件夹。它默认指向 Steam 版本的游戏。其他设置是可选的,你可以保持默认不变。 -- **Game Folder**: The folder where your game is installed. If the path is not valid, you’ll get a red warning. The editor cannot function without the correct folder setup. -- **Editor Theme**: Changes the overall color for the editor and editor windows. -- **Use accent colors for windows**: Changes the window and title colors based on the accent color. -- **Disable warnings showing in the inspector**: Disables any warnings that might be shown in the inspector. Generally not recommended unless you know what you are doing. -- **Enable XSLT editing (experimental)**: Enables the XSLT editing functionality for the editor. XSLT editing works but is experimental and may not be very stable. Some features that exist on direct XML editing may not be available in the XSLT mode. +- **游戏文件夹(Game Folder)**:你安装游戏的文件夹。如果路径无效,你会看到一个红色警告。编辑器在没有正确文件夹设置的情况下无法正常工作。 +- **编辑器主题(Editor Theme)**:更改编辑器及其窗口的整体配色。 +- **为窗口使用强调色(Use accent colors for windows)**:根据强调色更改窗口和标题栏的颜色。 +- **禁用检查器中显示的警告(Disable warnings showing in the inspector)**:禁用检查器(inspector)中可能显示的任何警告。除非你清楚自己在做什么,否则通常不建议启用此选项。 +- **启用 XSLT 编辑(实验性)(Enable XSLT editing (experimental))**:为编辑器启用 XSLT 编辑功能。XSLT 编辑功能可用,但仍处于实验阶段,可能不太稳定。在直接 XML 编辑中存在的一些功能在 XSLT 模式下可能不可用。 -The editor configuration file is saved directly next to the Bannerlord configuration file folder - `Documents\Mount and Blade II Bannerlord\Configs\xml_editor_config.json`. If any problem occurs with your settings, you can always delete the configuration file and restart the editor, which will recreate the settings file. +编辑器的配置文件直接保存在 Bannerlord 配置文件所在文件夹旁边——`Documents\Mount and Blade II Bannerlord\Configs\xml_editor_config.json`。如果你的设置出现任何问题,可以随时删除该配置文件并重新启动编辑器,系统会重新创建设置文件。 -You can access settings from the main window toolbar, `File` -> `Settings`, or by choosing the `Change Settings` option inside the Module Selection Window. +你可以从主窗口工具栏的 `File` -> `Settings` 访问设置,或者在模块选择窗口(Module Selection Window)中选择 `Change Settings` 选项。 -After confirming your settings, click the `Save and Close` button. You’ll be navigated to the Module Selection window. -##### What is an Active Module? -An active module is used to describe your intent to the editor. It allows the editor to choose between directly editing the XML file or creating a rule by creating an XSLT file. +确认设置后,点击 `Save and Close` 按钮。你将被导航到模块选择窗口。 +##### 什么是活动模块(Active Module)? +活动模块用于向编辑器描述你的工作意图。它使编辑器能够在直接编辑 XML 文件和创建 XSLT 文件生成规则这两种方式之间做出选择。 -In the module selection window, you are going to see modules that are located in the game folder that you have chosen. From here, you want to select the module that you want your work to be part of. XML Editor only supports direct editing of your or third-party modules. If you want to modify the values of the official modules, you’ll need to select your mod as active and use XSLT editing to edit official modules. -#### Editor Interface and Editing XML Files -After choosing the module that you want to work on, you are going to be greeted with the XML editor. In our case, we’ve chosen an empty mod that only has an `items.xml` file related to it. +在模块选择窗口中,你将看到位于你所选择的游戏文件夹中的模块。在这里,你需要选择希望你的工作所属的模块。XML 编辑器只支持直接编辑你自己的模块或第三方模块。如果你想修改官方模块的值,你需要将你的模组(mod)设置为活动模块,并使用 XSLT 编辑来编辑官方模块。 +#### 编辑器界面与编辑 XML 文件 +选择好你要操作的模块之后,你将看到 XML 编辑器的界面。在我们的例子中,我们选择了一个仅包含一个 `items.xml` 文件的空模组。 -To quickly go over the starting interface; +快速浏览一下初始界面: -- At the top, you can see the editor toolbar. You can access some quick operations from here, like reloading the editor or opening some additional editor windows, like the dependency editor. -- The center part is your main editor. Currently, it is displaying the schema files that are related to the game. Selecting any of the schemas will show you related XML files to that schema. -- At the bottom, there is an active module selection button. It shows you which module is currently active, and if you want, you can click on it to change your active module. Changing the active module will reload the editor. +- 顶部是编辑器工具栏。你可以从这里访问一些快捷操作,例如重新加载编辑器或打开一些附加的编辑器窗口,比如依赖关系编辑器(dependency editor)。 +- 中间部分是你的主编辑器区域。目前它显示的是与游戏相关的架构文件。选择任意一个架构文件将显示与该架构相关联的 XML 文件。 +- 底部有一个活动模块选择按钮。它显示当前处于活动状态的模块,如果需要,你可以点击它来更改你的活动模块。更改活动模块会重新加载编辑器。 -Since our example mod only has an `items.xml` which is related to the Items schema, we will continue our guide by selecting the Items schema. +由于我们的示例模组只有一个与 Items 架构相关联的 `items.xml` 文件,我们将通过选择 Items 架构继续本指南。 -Selecting a schema opens us to the document explorer window. The document explorer shows us every XML file that is related to the selected schema. You can also create a new XML document for the selected module and schema. The names of these files are shown as `[Module Name].[Xml Name]`. Let’s continue with selecting the Example Mod.items file. +选择一个架构会打开文档浏览器(document explorer)窗口。文档浏览器向我们展示与所选架构相关联的每个 XML 文件。你也可以为所选的模块和架构创建新的 XML 文档。这些文件的名称以 `[模块名称].[Xml 名称]` 的形式显示。让我们继续选择 Example Mod.items 文件。 -Once we select the target document, we are greeted with the `Element Explorer` window, which shows us the top-level elements in our XML file. You can compare the Element Explorer with the exact same document screenshot we’ve added below to help you understand exactly what you are seeing. On the bottom, you can see a button to create new top-level elements and the save button for the file to save your changes. +选中目标文档后,我们将进入 `元素浏览器(Element Explorer)` 窗口,它向我们展示 XML 文件中的顶级元素。你可以将元素浏览器与我们下面添加的完全相同的文档截图进行比较,以帮助你准确理解自己所看到的内容。在底部,你可以看到一个用于创建新顶级元素的按钮,以及用于保存文件更改的保存按钮。 -To edit one of these elements, you can click on the element in the Element Explorer window. This will open us to our final window, the `Inspector Window`. Inspector Window allows you to see all the attributes and child elements that are related to the selection in the Element Explorer window. +要编辑这些元素之一,你可以点击元素浏览器窗口中的该元素。这将打开我们的最后一个窗口——`检查器窗口(Inspector Window)`。检查器窗口让你能够查看与元素浏览器窗口中所选内容相关联的所有属性和子元素。 -In the Inspector Window, every dropdown represents an XML element. You can do element-related changes by clicking on the cogwheel icon next to the element that you want to apply changes to. You can make changes like creating a child element or deleting the selected element. +在检查器窗口中,每个下拉菜单代表一个 XML 元素。你可以通过点击想要应用更改的元素旁边的齿轮图标来进行与元素相关的更改。你可以进行诸如创建子元素或删除所选元素之类的更改。 -Under each dropdown, you can see fields being displayed. These fields are attributes of the XML element. `Undefined` means that the attribute does not exist. It’s marked this way to make sure we can differentiate between empty values and attributes that don’t have a value. Right-clicking on fields will also show you some options, like removing attributes from the element. +在每个下拉菜单下方,你可以看到显示的字段。这些字段是 XML 元素的属性。`Undefined`(未定义)表示该属性不存在。之所以这样标注,是为了确保我们能够区分空值和没有值的属性。右键点击字段还会显示一些选项,比如从元素中移除属性。 -The fields in the XML editor are smart. They try to show appropriate fields, like a checkbox for a boolean field, and fall back to a text field. They also check the requirements from the schema file and warn you if there are any problems. Fields with `Required` marked next to them are required by the schema file. If the new file is not compatible with the schema file, or a required field is missing, it will prevent you from saving the file. You’ll be displayed with appropriate errors so that you can fix them. +XML 编辑器中的字段是智能的。它们会尝试显示合适的字段类型,例如为布尔字段显示复选框,否则回退为文本字段。它们还会检查架构文件中的要求,并在出现任何问题时向你发出警告。标有 `Required`(必需)的字段是架构文件所要求的。如果新文件与架构文件不兼容,或者缺少必需字段,系统将阻止你保存文件。系统会向你显示相应的错误信息,以便你进行修正。 -After making changes, make sure to click the save button. It’s also important to note that there is no element-level save feature. Once you make changes, you need to save the entire document. +进行更改后,请务必点击保存按钮。还需要注意的是,没有针对单个元素级别的保存功能。一旦你做出更改,就需要保存整个文档。 -#### Editing Official Modules using XSLT -To edit official modules, you need to enable the XSLT editing mode. Open the settings window from `File` -> `Settings`, and make sure the `Enable XSLT editing` box is checked. Once that is done, if we click on any schema file, we are also going to see related XML files from other modules. We can differentiate the XSLT editing by the yellow warning icon on the right side of the XML file. +#### 使用 XSLT 编辑官方模块 +要编辑官方模块,你需要启用 XSLT 编辑模式。通过 `File` -> `Settings` 打开设置窗口,确保勾选了 `Enable XSLT editing` 复选框。完成之后,如果我们点击任意架构文件,我们还会看到来自其他模块的相关 XML 文件。我们可以通过 XML 文件右侧的黄色警告图标来区分 XSLT 编辑模式。 -For demo purposes, we will continue by selecting the `mpitems` file, which is part of the Native module of the game. +出于演示目的,我们将继续选择属于游戏 Native 模块的一部分的 `mpitems` 文件。 -We can now see the elements that are part of the `Native.mpitems` file. One thing to note here is that XSLT editing does not support deleting an element. Instead, we can replace the element with an empty one. Let’s continue by choosing an element to edit. +现在我们可以看到属于 `Native.mpitems` 文件的元素。这里需要注意的一点是,XSLT 编辑不支持删除元素。相反,我们可以用一个空元素来替换该元素。让我们继续选择一个要编辑的元素。 -We’ve chosen the `mp_pointed_skullcap_over_cloth_headwrap` item. You can see that there is an error in the inspector preventing us from making any edits. That is because to make XSLT edits, our module needs to be dependent on the target module, Native, in this case. We can quickly fix this error by heading over to the `Window` -> `Dependency Editor`. +我们选择了 `mp_pointed_skullcap_over_cloth_headwrap` 这个物品。你可以看到检查器中出现了一个错误,阻止我们进行任何编辑。这是因为要进行 XSLT 编辑,我们的模块需要依赖于目标模块——在本例中是 Native 模块。我们可以通过前往 `Window` -> `Dependency Editor`(依赖关系编辑器)来快速修复此错误。 -`Dependency Editor` allows us to edit the dependencies of our module. On the left side, we see modules that we are not dependent upon. We can click on a module on the left and add it as a dependency. We will choose Native, since mpitems is part of the Native, and then choose `Add Dependency`. In the end, it will look like this: +`Dependency Editor`(依赖关系编辑器)让我们能够编辑模块的依赖关系。在左侧,我们可以看到我们尚未依赖的模块。我们可以点击左侧的模块,将其添加为依赖项。由于 mpitems 属于 Native 模块的一部分,我们将选择 Native,然后选择 `Add Dependency`(添加依赖)。最终,效果将如下所示: -We can now close the Dependency Editor and return to the Inspector. You’ll see that the error is gone, and there is only a warning, telling us that we are using XSLT and not direct XML editing. We can ignore this warning. +现在我们可以关闭依赖关系编辑器,返回检查器界面。你会看到错误已经消失,只剩下一个警告,提示我们正在使用 XSLT 编辑而非直接 XML 编辑。我们可以忽略这个警告。 -Our setup is done, and we can continue editing the element just like we are editing some other XML element. On the backend, the editor will be translating these changes to XSLT. You can find the resulting XSLT files directly under your module’s `ModuleData` folder, in a folder called `XSLT`. Note that some functionality in the XML editing may not be available in the XSLT editing mode. \ No newline at end of file +我们的设置已经完成,现在可以像编辑其他 XML 元素一样继续编辑该元素了。在后台,编辑器会将这些更改转换为 XSLT。你可以在模块的 `ModuleData` 文件夹下一个名为 `XSLT` 的文件夹中找到生成的 XSLT 文件。请注意,直接 XML 编辑中的某些功能在 XSLT 编辑模式下可能不可用。 + diff --git a/docs/content/schinese/Editor/Resource Editors/decals.md b/docs/content/schinese/Editor/Resource Editors/decals.md new file mode 100644 index 00000000..dfc74aa2 --- /dev/null +++ b/docs/content/schinese/Editor/Resource Editors/decals.md @@ -0,0 +1,32 @@ ++++ +title = "贴花(Decals)" +ai_translated = true + +[menu.main] +identifier = "decal" +parent = "core_components" ++++ + +## 什么是贴花(Decal)? + +贴花(Decal)是一种将材质投影到其他几何体上的方法。它们可以影响 PBR 着色管线的以下通道:Albedo(反照率)、Normal(法线)、Specular(高光)、Gloss(光泽度)和 Occlusion(遮蔽)。因此,它们会改变其他网格体和材质的最终外观。它们可用于为场景增添变化,例如污垢、泥土、苔藓。此外,它们也是打破网格体上纹理平铺感的实用工具。其投影几何体为立方体,并沿 Z 方向进行投影。 + +## 如何设置贴花材质? + +首先,材质的着色器(shader)应设置为“Decal”。Diffuse(漫反射)、NormalMap(法线贴图)和 SpecularMap(高光贴图)可以设置为任意纹理。其着色模型(shading model)将与“pbr_metallic”相同。 + + +#### 材质着色器标志(Material Shader Flags) + +材质着色器标志决定了将使用哪些着色属性,以及贴花将在哪些类型的对象上可见。注意:“use_albedo”是必须启用的。以下是一个典型示例,展示了一个将在所有材质上可见的贴花材质。 + + +#### “Others”标签页中的必要设置 + +为了使贴花正确渲染,应启用“Cull Front Faces”(剔除正面)和“Don't Modify Depth Buffer”(不修改深度缓冲区)标志。 + + +## 如何设置贴花预制件(Decal Prefab)? + +要创建贴花实体/预制件,需要将特定的网格体(贴花网格体,Decal Mesh)添加到一个空实体中。然后,应将该网格体的材质更改为我们在第一节中准备的材质。最后,在 Components/Meta Mesh/Custom Mesh Parameters 下,应相应地设置 UV Scale X/Y 数值。对于普通纹理,这些数值应均为 1。对于图集(atlas)类型的纹理,应设置 UV Scale 和 UV Offset 数值,以聚焦到图集内所需的纹理位置。 + diff --git a/docs/content/schinese/Editor/_index.md b/docs/content/schinese/Editor/_index.md index 0909fc90..f4766ec3 100644 --- a/docs/content/schinese/Editor/_index.md +++ b/docs/content/schinese/Editor/_index.md @@ -1,6 +1,6 @@ +++ title = "编辑器" -description = "editor" +description = "编辑器" weight = 1 +++ diff --git a/docs/content/schinese/Multiplayer/hosting_server.md b/docs/content/schinese/Multiplayer/hosting_server.md index 9023fee8..a406ae28 100644 --- a/docs/content/schinese/Multiplayer/hosting_server.md +++ b/docs/content/schinese/Multiplayer/hosting_server.md @@ -1,228 +1,229 @@ +++ -title = "Hosting a Custom Server" +title = "托管自定义服务器" description = "" weight = 5 +ai_translated = true +++ -## Installing -Enable Tools within your Steam Library. `Mount & Blade II: Dedicated Server` should appear on your list. Download and install it. +## 安装 +在 Steam 库中启用工具(Tools)。`Mount & Blade II: Dedicated Server` 应该会出现在你的列表中。下载并安装它。 -## Hosting -By default, dedicated servers use UDP port 7210. You must have a visible (public) IP address on the internet as well as the aforementioned port being accessible. +## 托管 +默认情况下,专用服务器使用 UDP 端口 7210。你必须拥有一个可见的(公共)互联网 IP 地址,并且上述端口必须可被访问。 -Anonymous hosting is not supported. You will have to create a server token by going in-game first. +不支持匿名托管。你必须先进入游戏来创建一个服务器令牌(token)。 -### Generating a Token -Launch `Mount & Blade II: Bannerlord` multiplayer and log into the game lobby: +### 生成令牌 +启动 `Mount & Blade II: Bannerlord` 多人游戏并登录游戏大厅: -Open the game console by pressing `ALT` + `tilde key (~)`: +按下 `ALT` + `波浪号键 (~)` 打开游戏控制台: -Type `customserver.gettoken` in the textbox and press enter: +在文本框中输入 `customserver.gettoken` 并按回车: -Your token has been generated and saved under your `Documents\Mount & Blade II Bannerlord\Tokens` folder: +你的令牌已生成,并保存在你的 `Documents\Mount & Blade II Bannerlord\Tokens` 文件夹下: -If you are planning to host the dedicated server on the same computer where you installed Bannerlord, this is all you have to do. But if you are planning to host using a different computer, please copy this token file to the target computer’s `Documents\Mount & Blade II Bannerlord\Tokens` folder. There is also one other alternative method shown in the Launch Arguments section below. +如果你打算在安装了 Bannerlord 的同一台电脑上托管专用服务器,那么这就是你需要做的全部工作。但如果你打算使用另一台电脑进行托管,请将此令牌文件复制到目标电脑的 `Documents\Mount & Blade II Bannerlord\Tokens` 文件夹中。下面的启动参数(Launch Arguments)部分还展示了另一种替代方法。 -Beware that the generated token is tied to your Bannerlord account. Any abuse would be traced back to the user who originally generated the token. **We recommend keeping it private**, and not sharing it with other people. +请注意,生成的令牌与你的 Bannerlord 账户绑定。任何滥用行为都将被追溯到最初生成该令牌的用户。**我们建议将其保密**,不要与他人分享。 -Also remember that **your token expires after 3 months** due to security reasons at which point you can replace it by generating a new one. +还要记住,出于安全原因,**你的令牌会在 3 个月后过期**,届时你可以通过生成一个新令牌来替换它。 -### Server Administration -You can administrate your server by typing commands in your server’s console (that opens up when launching the server). +### 服务器管理 +你可以通过在服务器控制台(启动服务器时会打开)中输入命令来管理你的服务器。 -By typing `list` and pressing `enter`, you will get all the available commands in the dedicated server: +输入 `list` 并按下 `enter`,你将获得专用服务器中所有可用的命令: -For example, to get a simple server running, you can type the following commands into your console: +例如,要运行一个简单的服务器,你可以在控制台中输入以下命令: * `ServerName Custom Dedicated Beta Test` * `GameType TeamDeathmatch` * `start_game` * `start_mission` -By executing these commands, you will make your custom server visible and accessible to all players. +执行这些命令后,你的自定义服务器将对所有玩家可见并可访问。 -With the `ServerName` and `GameType` commands, you are simply setting the name of your server and setting your game mode. +通过 `ServerName` 和 `GameType` 命令,你只是简单地设置服务器的名称和游戏模式。 -With the `start_game` command, you are starting to host your server. Your server becomes visible to all players. Any player who enters your server will wait in the intermission state. +通过 `start_game` 命令,你开始托管你的服务器。你的服务器将对所有玩家可见。任何进入你服务器的玩家都将在中场(intermission)状态等待。 -With the `start_mission` command, your server will switch into mission mode and players will be able to play the game. +通过 `start_mission` 命令,你的服务器将切换到任务(mission)模式,玩家将能够开始游戏。 -You can also use the shorthand `start_game_and_mission` instead of the two commands. +你也可以使用简写命令 `start_game_and_mission` 来代替这两个命令。 -#### Tips & Tricks +#### 技巧与窍门 -##### Configuration Files -Instead of executing commands one at a time with the server console, you can specify a configuration file to run on initialization, which will have its contents executed line by line. +##### 配置文件 +除了在服务器控制台中逐条执行命令外,你还可以指定一个在初始化时运行的配置文件,该文件的内容将被逐行执行。 -You can find sample configuration files within the Native module directory (`Modules\Native\ds_config_*.txt`). Note that currently, your own configuration files must also reside within this same directory to be found by the server. See the launch arguments section below for how you can specify a configuration file to be run. +你可以在 Native 模组目录下找到示例配置文件(`Modules\Native\ds_config_*.txt`)。请注意,目前你自己的配置文件也必须位于同一目录中才能被服务器找到。有关如何指定要运行的配置文件,请参阅下面的启动参数部分。 -##### Launch Arguments -There are a few particularly useful launch arguments at the moment: +##### 启动参数 +目前有几个特别有用的启动参数: `/dedicatedcustomserverconfigfile [configuration_file_name]` -Specify a configuration file to be run as seen in the Configuration Files section above. +指定一个要运行的配置文件,如上面配置文件部分所述。 `/dedicatedcustomserverauthtoken [authentication_token_contents]` -When the token is passed through the launch argument, a local file containing the token is not required. +当令牌通过启动参数传递时,就不需要包含令牌的本地文件了。 `/DisableErrorReporting` -Disables the Crash Uploader popup and automatic error reporting. +禁用崩溃上传器弹窗和自动错误报告。 `/LogOutputPath [output_path]` -Sets the log output directory of the server. Path should be in double quotes. +设置服务器的日志输出目录。路径应放在双引号中。 -`/port [number]` Optionally specify a port number to run the server from, useful for using ports other than the default. +`/port [number]` 可选地指定一个端口号来运行服务器,适用于使用非默认端口的情况。 -##### Log Files -By default, log files for the custom server can be found in your ProgramData directory on Windows (`%programdata%\Mount and Blade II Bannerlord\logs`). +##### 日志文件 +默认情况下,自定义服务器的日志文件可以在 Windows 的 ProgramData 目录下找到(`%programdata%\Mount and Blade II Bannerlord\logs`)。 -##### Automated Battle Count -By using the command `set_automated_battle_count` before `enable_automated_battle_switching`, you can set the number of missions to be played before the server shuts down. +##### 自动战斗计数 +在 `enable_automated_battle_switching` 之前使用命令 `set_automated_battle_count`,你可以设置服务器关闭前要进行的任务数量。 -For example, `set_automated_battle_count 10` will have the server play 10 missions and shut down. If you would like to have an unlimited number of missions, set it to `-1`. +例如,`set_automated_battle_count 10` 将使服务器进行 10 场任务后关闭。如果你想要无限数量的任务,请将其设置为 `-1`。 -#### Additional Features -With patch v1.2.x the below striken through text is no longer relevant. The `DedicatedCustomServerHelper` module and its functionality has been merged into the base game. +#### 附加功能 +从 v1.2.x 补丁开始,下面带删除线的文本不再适用。`DedicatedCustomServerHelper` 模组及其功能已合并到基础游戏中。 -~~We supply the optional `DedicatedCustomServerHelper` module to help server hosts. There are several submodules within for distinct purposes.~~ For the server side modules to be usable from the outside, you will need to make TCP port 7210 accessible as well. +~~我们提供了可选的 `DedicatedCustomServerHelper` 模组来帮助服务器主机。其中有几个子模组用于不同的目的。~~ 要让服务器端模组能够从外部被使用,你还需要使 TCP 端口 7210 可被访问。 -~~Note that although the module is optional for server hosts, if you as the host do load the module, the players will also need to have it loaded. Otherwise, a mismatch in modules will prevent players from joining.~~ +~~请注意,虽然该模组对服务器主机来说是可选的,但如果你作为主机加载了该模组,玩家也需要加载它。否则,模组不匹配将导致玩家无法加入。~~ -##### Administration Web Panel -This module launches a web panel to interact with your custom server, through a general management page and a terminal page: +##### 管理 Web 面板 +该模组会启动一个 Web 面板,通过一个常规管理页面和一个终端页面与你的自定义服务器进行交互: -You can access the web panel with your server's IP address and port once it has been initialized. +一旦服务器初始化完成,你可以通过服务器的 IP 地址和端口访问该 Web 面板。 -The web panel is password protected by the server’s configured `AdminPassword` option. **By default, this option is left blank, so be sure to change it to a secure password**. +该 Web 面板受服务器配置的 `AdminPassword` 选项密码保护。**默认情况下,此选项为空,因此请务必将其更改为一个安全的密码**。 -If you do not want the web panel to be accessible from outside the local network or machine, and also do not need the map download feature below, you are free to block TCP port 7210 from external access. +如果你不希望该 Web 面板可从本地网络或本机以外被访问,并且也不需要下面的地图下载功能,你可以自由地阻止 TCP 端口 7210 的外部访问。 -##### In-Game Map Downloads [Map Downloader] -We also present a way to allow players to download your server's map files through an in-game panel. As the server host, there are some conditions you must ensure to get this functioning: +##### 游戏内地图下载 [地图下载器] +我们还提供了一种方式,允许玩家通过游戏内面板下载你服务器的地图文件。作为服务器主机,有一些条件你必须确保才能使此功能正常工作: -* The maps to be served must be located within ONLY the Multiplayer module's `SceneObj` directory, in the same way a typical module contains scenes. You can create the directory by hand if it is missing. -* The maps to be served must be "registered" through either the `Map` configuration option, the `add_map_to_automated_battle_pool` or `add_map_to_usable_maps` commands. In other words, only maps playable on the server are served. +* 要提供的地图必须且只能位于 Multiplayer 模组的 `SceneObj` 目录中,方式与典型模组包含场景的方式相同。如果该目录缺失,你可以手动创建它。 +* 要提供的地图必须通过 `Map` 配置选项、`add_map_to_automated_battle_pool` 或 `add_map_to_usable_maps` 命令进行"注册"。换句话说,只有在服务器上可玩的地图才会被提供。 -Note that having the scene loaded in multiple modules will cause issues such as the scene not being shown on the download panel. +请注意,如果场景被加载到多个模组中,会导致诸如场景不显示在下载面板上等问题。 -Players will then get prompted to download all of the missing maps as they try to join the server or they can right click on the custom server list entry, which will open a context menu with the option to open the download panel for the server. Once all missing maps are successfully downloaded, there is no need to restart the game, they should be able to join your server as is. +玩家在尝试加入服务器时将收到下载所有缺失地图的提示,或者他们可以在自定义服务器列表条目上点击右键,这将打开一个上下文菜单,其中包含打开该服务器下载面板的选项。一旦所有缺失的地图成功下载完成,就无需重启游戏,他们应该能够直接加入你的服务器。 -Note that this feature is intended to support simple use cases. This is not a module manager feature, and will not be able to support maps that require other assets (ModuleData, Prefabs, etc.) spread throughout a given module. Only the `SceneObj` directory contents are transferred between the server and the client. +请注意,此功能旨在支持简单的使用场景。这不是一个模组管理器功能,无法支持需要分散在给定模组中其他资源(ModuleData、Prefabs 等)的地图。只有 `SceneObj` 目录的内容会在服务器和客户端之间传输。 -If the lack of prefab support is a concern, you may be able to make the scene usable through the Map Downloader by breaking the prefabs. Open the scene in the editor, select all entity objects, right click and select *Break Prefab*. +如果缺乏预制件(prefab)支持是个问题,你或许可以通过打破预制件,使该场景可以通过地图下载器使用。在编辑器中打开场景,选中所有实体对象,右键单击并选择 *Break Prefab*(打破预制件)。 -##### In-game admin panel & admin features -The in-game admin panel provides an easy way to organize and moderate events. +##### 游戏内管理面板与管理功能 +游戏内管理面板提供了一种组织和管理活动的简便方式。 -The admin features are only available to those that enter the server as an admin by providing the admin password (right-click on the server and then `Join as Admin`). You can then access the admin panel via the Escape menu. The `AdminPassword` can be set from the server config. +管理功能仅对那些通过提供管理员密码(在服务器上右键单击,然后选择 `Join as Admin`)以管理员身份进入服务器的人开放。然后你可以通过 Escape 菜单访问管理面板。`AdminPassword` 可以从服务器配置中设置。 | | | | ------ | ----------- | | | | -The in-game panel has two main operational buttons: +游戏内面板有两个主要的操作按钮: -* `Apply and Start Mission` -> This will apply all of the changes made and start a new mission immediately. -* `Apply Changes` -> This will apply all of the changes made. The ones that are listed under Immediate Effects will go into effect right away. Those that are listed under Mission Options will be applied on the next mission. +* `Apply and Start Mission`(应用并开始任务)-> 这将应用所做的所有更改并立即开始一场新任务。 +* `Apply Changes`(应用更改)-> 这将应用所做的所有更改。列在"立即生效"(Immediate Effects)下的更改将立即生效。列在"任务选项"(Mission Options)下的更改将在下一场任务中应用。 -The in-game admin panel comes with the following options: +游戏内管理面板带有以下选项: -###### Mission Options (require mission restart) +###### 任务选项(需要任务重启) -Please note that if you wish to change "Mission Options" that require a mission restart using the in-game Admin Panel - you must use the map intermission system. This means you must use the `start_game_and_mission` (or `start_game`) and `enable_automated_battle_switching` commands in your server config. Not using these will automatically disable all Mission Options on the Admin Panel. +请注意,如果你希望使用游戏内管理面板更改需要任务重启的"任务选项",你必须使用地图中场系统。这意味着你必须在服务器配置中使用 `start_game_and_mission`(或 `start_game`)和 `enable_automated_battle_switching` 命令。不使用这些命令将自动禁用管理面板上的所有任务选项。 -Additionally, options open up based on the selected Game Type. For example, the Warmup Time Limit option is not available when selecting TeamDeathMatch - as there's no warmup in TDM. +此外,选项会根据所选的游戏类型而开放。例如,选择 TeamDeathMatch 时,预热时间限制(Warmup Time Limit)选项不可用——因为 TDM 中没有预热环节。 -* Game Type - * Lists all available game types (Siege, TeamDeathmatch, Captain, Skirmish, Duel, Battle) -* Map - * Lists all the maps that have been passed to the server inside the config with the `add_map_to_usable_maps [MapName] [GameType],[GameType]` command - * For example: `add_map_to_usable_maps mymap Siege,Skirmish` (please note that the GameType must be correctly capitalized) -* Attacker & Defender Cultures -* Minimum Score to Win Duel -* Number of Rounds -* Map Time Limit -* Round Time Limit -* Warmup Time Limit -* Maximum Number of Players +* Game Type(游戏类型) + * 列出所有可用的游戏类型(Siege、TeamDeathmatch、Captain、Skirmish、Duel、Battle) +* Map(地图) + * 列出所有通过 `add_map_to_usable_maps [MapName] [GameType],[GameType]` 命令传递给服务器配置的地图 + * 例如:`add_map_to_usable_maps mymap Siege,Skirmish`(请注意,GameType 必须正确大写) +* Attacker & Defender Cultures(攻方与守方文化) +* Minimum Score to Win Duel(赢得决斗所需的最低分数) +* Number of Rounds(回合数) +* Map Time Limit(地图时间限制) +* Round Time Limit(回合时间限制) +* Warmup Time Limit(预热时间限制) +* Maximum Number of Players(最大玩家数) -###### Immediate Effects -* Welcome Message -* Team Balance Threshold -* Friendly Damages -* Class Limits (Allow, Disallow) +###### 立即生效 +* Welcome Message(欢迎消息) +* Team Balance Threshold(队伍平衡阈值) +* Friendly Damages(友军伤害) +* Class Limits(职业限制,Allow、Disallow) -###### Others -* End Warmup - * Overrides the warmup timer and ends the warmup in 30 seconds. -* Mute/Unmute Player - * Mutes a player, preventing them from using chat. -* Kick Player - * Kicks a player from the server. Kicked players are able to immediately rejoin the server. -* Ban Player - * Bans a player from the server. Banned players are not able to rejoin the server until it restarts. +###### 其他 +* End Warmup(结束预热) + * 覆盖预热计时器,在 30 秒内结束预热。 +* Mute/Unmute Player(静音/取消静音玩家) + * 使玩家静音,阻止其使用聊天功能。 +* Kick Player(踢出玩家) + * 将玩家踢出服务器。被踢出的玩家可以立即重新加入服务器。 +* Ban Player(封禁玩家) + * 将玩家从服务器中封禁。被封禁的玩家在服务器重启之前无法重新加入。 -Here are some behaviours you should expect while changing Game Types, Maps and Cultures: +以下是在更改游戏类型、地图和文化时你应该预期的一些行为: -* If you leave Game Type, Map and Cultures UNSELECTED -> The game will run the current Game Type being played and give the players the option to vote on the available maps (those passed with `add_map_to_automated_battle_pool`) and cultures. -* If you leave Game Type, Map and Cultures UNSELECTED AND the Game Type isn't the one that the server initially launched with -> The game will run the current Game Type being played and use a random map from the available maps (those passed with `add_map_to_usable_maps`) and give the players the option to vote on cultures. -* If you select a Game Type but leave Map and Cultures UNSELECTED AND the selected Game Type isn't the one that the server initially launched with -> The game will run the current Game Type being played and use a random map from the available maps (those passed with `add_map_to_usable_maps`) and give the players the option to vote on cultures. -* If you select a Game Type and Map but leave Cultures UNSELECTED -> The game will run the selected Game Type with the selected Map and give the players the option to vote on cultures. -* If you select a Game Type, Map and Cultures -> The game will run the selected Game Type, Map and Cultures with no voting screen. -* If you provide no maps for a specific Game Type using the `add_map_to_usable_maps` parameter, that specific Game Type will be disabled in the admin panel. -* Official maps will only work with the intended Game Types. Trying to use them with another Game Type with `add_map_to_usable_maps` will not display them in the admin panel. +* 如果你将游戏类型、地图和文化保持未选择状态 -> 游戏将运行当前正在进行的游戏类型,并让玩家对可用地图(通过 `add_map_to_automated_battle_pool` 传递的那些)和文化进行投票。 +* 如果你将游戏类型、地图和文化保持未选择状态,并且该游戏类型不是服务器最初启动时的类型 -> 游戏将运行当前正在进行的游戏类型,并从可用地图(通过 `add_map_to_usable_maps` 传递的那些)中随机使用一张地图,并让玩家对文化进行投票。 +* 如果你选择了游戏类型但将地图和文化保持未选择状态,并且所选游戏类型不是服务器最初启动时的类型 -> 游戏将运行当前正在进行的游戏类型,并从可用地图(通过 `add_map_to_usable_maps` 传递的那些)中随机使用一张地图,并让玩家对文化进行投票。 +* 如果你选择了游戏类型和地图,但将文化保持未选择状态 -> 游戏将使用所选的游戏类型和所选地图运行,并让玩家对文化进行投票。 +* 如果你选择了游戏类型、地图和文化 -> 游戏将使用所选的游戏类型、地图和文化运行,不会出现投票画面。 +* 如果你没有通过 `add_map_to_usable_maps` 参数为特定游戏类型提供任何地图,该特定游戏类型将在管理面板中被禁用。 +* 官方地图只能与预定的游戏类型配合使用。尝试通过 `add_map_to_usable_maps` 将它们用于其他游戏类型,将不会在管理面板中显示它们。 -###### Admin Announcements -You can also make use of the admin announcements system which pushes out text to everyone on the server by typing the following into chat: +###### 管理员公告 +你还可以利用管理员公告系统,通过在聊天中输入以下内容向服务器上的所有人推送文本: -* `/ab [text]` - Admin Broadcast - Displays the announcement in the middle of the screen as well as in chat alongside a sound notification. -* `/ac [text]` - Admin Chat - Displays the announcement in chat. +* `/ab [text]` - 管理员广播(Admin Broadcast)- 在屏幕中央以及聊天中显示公告,并伴有提示音。 +* `/ac [text]` - 管理员聊天(Admin Chat)- 在聊天中显示公告。 -## FAQ -##### Does Steam need to stay open for hosting? -No. You only need Steam for keeping your server files up to date. You are free to copy your server files to some other computer to host it. But we strongly recommend you to use it with Steam in order to keep it up to date. Unlike Warband, currently, any older versions of the server files will be incompatible with our system. +## 常见问题 +##### 托管时 Steam 需要保持打开吗? +不需要。你只需要 Steam 来保持服务器文件的更新。你可以自由地将服务器文件复制到其他电脑进行托管。但我们强烈建议你配合 Steam 使用,以保持其更新。与 Warband 不同,目前任何旧版本的服务器文件都将与我们的系统不兼容。 -##### Are you planning to add support for other game platforms? -Yes. +##### 你们是否计划添加对其他游戏平台的支持? +是的。 -##### What if I don’t want to use any game platform to retrieve the server files, will there be any other option? -Right now, Steam is the only way to download it. We are planning to add it to other game platforms and are also discussing using a Docker host for distributing the server files in the future. +##### 如果我不想使用任何游戏平台来获取服务器文件,还有其他选择吗? +目前,Steam 是唯一的下载方式。我们计划将其添加到其他游戏平台,也正在讨论在未来使用 Docker 主机来分发服务器文件。 -##### Will you provide Linux support? -Linux server files are already available! +##### 你们会提供 Linux 支持吗? +Linux 服务器文件已经可用! -##### Will my server be accessible by everyone? -Yes, your server will be accessible by everyone unless you make it password protected. +##### 我的服务器是否对所有人可见? +是的,除非你设置密码保护,否则你的服务器将对所有人可见。 -##### How many servers can I host? -There is a limit to the number of servers you can host simultaneously. Currently, you can host up to 50 servers. +##### 我可以托管多少个服务器? +你可以同时托管的服务器数量是有限制的。目前,你最多可以托管 50 个服务器。 -##### What are the hardware requirements? -It depends on the game mode and the player count. With the default configurations, we are hosting our games: +##### 硬件要求是什么? +这取决于游戏模式和玩家数量。在默认配置下,我们托管我们的游戏: -* For smaller battles (Skirmish and Duel): 2 core CPUs (2GHz to 3GHz) with 4GB Memory -* For bigger battles (Siege, Team Deathmatch and Captain): 4 core CPUs (2GHz to 3GHz) with 8GB Memory +* 对于较小规模的战斗(Skirmish 和 Duel):2 核 CPU(2GHz 至 3GHz),4GB 内存 +* 对于较大规模的战斗(Siege、Team Deathmatch 和 Captain):4 核 CPU(2GHz 至 3GHz),8GB 内存 -But, for instance, you can always host a siege mode with less players on a 2 core machine as well. +但是,举例来说,你也始终可以在 2 核机器上以较少玩家数托管攻城模式。 -You can also try to host a very small game with a single core machine as well but you might get some spikes during the game. +你也可以尝试用单核机器托管一个非常小的游戏,但你在游戏过程中可能会遇到一些性能峰值。 -##### What are the bandwidth requirements? -It depends on the player count. By default, we are sending 60 packets to each player and each packet is less than 1.5 kilobytes. For most configurations, any dedicated server provider should be able to provide a sufficient network connection. +##### 带宽要求是什么? +这取决于玩家数量。默认情况下,我们向每个玩家发送 60 个数据包,每个数据包小于 1.5 千字节。对于大多数配置,任何专用服务器提供商都应该能够提供足够的网络连接。 -##### Is there any modification support? -Yes! Go to https://moddocs.bannerlord.com/multiplayer/custom_game_mode/ to learn more. +##### 是否支持修改(Modification)? +是的!前往 https://moddocs.bannerlord.com/multiplayer/custom_game_mode/ 了解更多信息。 diff --git a/docs/content/schinese/War Sails/_index.md b/docs/content/schinese/War Sails/_index.md index a08165c2..3465a087 100644 --- a/docs/content/schinese/War Sails/_index.md +++ b/docs/content/schinese/War Sails/_index.md @@ -1,5 +1,5 @@ +++ -title="War Sails" +title="War Sails(海战)" weight = 100 +++ diff --git a/docs/content/schinese/War Sails/ship_creation.md b/docs/content/schinese/War Sails/ship_creation.md index e0d14796..ca9e216c 100644 --- a/docs/content/schinese/War Sails/ship_creation.md +++ b/docs/content/schinese/War Sails/ship_creation.md @@ -1,684 +1,685 @@ +++ -title = "Ship Creation" +title = "船只创建" description = "" weight = 1 +ai_translated = true +++ -## **1. Introduction** +## **1. 简介** -### **1.1. Purpose of the Documentation** +### **1.1. 文档目的** -This documentation is a comprehensive, end-to-end guide for creating and integrating custom ships into the game. It is written for mod authors who want to add fully functional ships to Bannerlord's naval system. You do not need to be a programmer to follow this guide, but you should be comfortable working inside the Bannerlord editor and understand the basic concepts of entities, prefabs, and scripts. +本文档是一份全面、端到端的指南,用于在游戏中创建并集成自定义船只。它是为想要向 Bannerlord 的海战系统添加完全可用船只的模组作者而编写的。你不需要是程序员也能跟随本指南,但你应当熟悉在 Bannerlord 编辑器中进行操作,并理解实体(entity)、预制体(prefab)和脚本的基本概念。 -The goal is to walk you through the entire technical pipeline — from setting up the initial Nested Prefab hierarchy all the way to final in-game implementation. By following the workflows outlined here, you will produce a ship that is fully compatible with the game's physics, AI navigation, boarding, crew interaction, and upgrade systems. +本指南的目标是带你走完整个技术流程——从建立最初的嵌套预制体(Nested Prefab)层级结构,一直到最终的游戏内实现。按照这里概述的工作流程操作后,你将制作出一艘与游戏的物理系统、AI 导航、登船、船员交互和升级系统完全兼容的船只。 -### **1.2. Overview of the Ship Creation Pipeline** +### **1.2. 船只创建流程概览** -The ship creation process follows a structured, layered workflow. Each layer depends on the one before it, so it is important not to skip steps. The pipeline begins with establishing the correct Nested Prefab hierarchy — this is the backbone that every other system relies on. +船只创建过程遵循一个结构化、分层的工作流程。每一层都依赖于前一层,因此不要跳过步骤非常重要。整个流程从建立正确的嵌套预制体层级结构开始——这是其他所有系统所依赖的骨架。 -The workflow is divided into three main stages: +工作流程分为三个主要阶段: -> * **Core Setup (Essential):** Establishing the root entity, importing hull meshes, and configuring physics volumes (collision and buoyancy) to ensure the ship exists and floats correctly in the physics engine. Nothing else will work until this stage is complete. -> * **Gameplay Integration (Upgrades):** Implementing navigation systems (rudders, sails, oars), boarding mechanics, ballistas, and interaction points required for player control and combat. These components define how players and AI interact with the ship. -> * **Detailing & Polish (Cosmetic):** Finalizing the ship with visual upgrades, particle effects, water interactions, and decorative elements to enhance the atmosphere. These components are purely visual — removing them will not break the ship's functionality. +> * **核心设置(必需):** 建立根实体、导入船体网格,并配置物理体积(碰撞体和浮力体),以确保船只能够存在并在物理引擎中正确漂浮。在完成此阶段之前,其他任何内容都无法正常工作。 +> * **玩法集成(升级):** 实现导航系统(舵、帆、桨)、登船机制、弩炮以及玩家控制和战斗所需的交互点。这些组件定义了玩家和 AI 与船只的交互方式。 +> * **细节与润色(装饰性):** 通过视觉升级、粒子效果、水面交互和装饰元素来完善船只,以增强氛围感。这些组件纯属视觉效果——移除它们不会破坏船只的功能。 -## **2. Ship Hierarchy & Component Breakdown** +## **2. 船只层级结构与组件分解** -In this section, ship components are categorized into three main groups: Essential (Critical for gameplay), Upgrades (Gameplay features), and Cosmetics (Visual details). +在本节中,船只组件被分为三个主要组:必需组件(对玩法至关重要)、升级组件(玩法功能)和装饰组件(视觉细节)。 -When building your ship, the full entity hierarchy should follow this general structure: +在构建船只时,完整的实体层级结构应遵循以下通用结构: -\[ShipName\]\_ship\_nested (Root Entity) -├── 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 (visual only) -├── ship\_burning\_system -└── \[other cosmetic holders\] +\[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 +└── \[其他装饰性容器\] -Each of these children is described in detail in the sections below. Keep this hierarchy in mind as you work — placing a component under the wrong parent is one of the most common sources of errors. +下面各节将详细描述每个子项。在工作过程中请牢记这个层级结构——将组件放在错误的父节点下是最常见的错误来源之一。 -### **2.1. Essential Components (Critical)** +### **2.1. 必需组件(关键)** -The objects in this group represent the **bare minimum** configuration required for the ship to exist in the game world, for physics to function correctly, and for basic operations to be performed. If any of these components are missing or misconfigured, the ship will either not load, not float, or behave incorrectly in-game. +该组中的对象代表了船只存在于游戏世界、物理功能正常运行以及执行基本操作所需的**最低限度**配置。如果缺少或错误配置了其中任何一个组件,船只要么无法加载,要么无法漂浮,要么在游戏中行为异常。 -#### **2.1.1. Root Entity Setup (dromon\_ship\_nested)** +#### **2.1.1. 根实体设置(dromon\_ship\_nested)** -This entity is the parent container for the entire ship prefab. Every other component in this guide is placed as a child or descendant of this entity. Throughout this documentation, we will use the "Dromon" ship as the reference example. +此实体是整个船只预制体的父容器。本指南中的所有其他组件都作为此实体的子项或后代放置。在本文档中,我们将使用"Dromon"船作为参考示例。 -> * **Naming Convention:** We recommend using the format \[ShipName\]\_ship\_nested (e.g., dromon\_ship\_nested). While not strictly enforced by the engine, following this convention ensures your ship is easy to identify and consistent with the existing ship assets in the game. +> * **命名约定:** 我们建议使用 \[ShipName\]\_ship\_nested 格式(例如 dromon\_ship\_nested)。虽然引擎并未严格强制执行此约定,但遵循它可以确保你的船只易于识别,并与游戏中现有的船只资产保持一致。 -**Required Setup & Attributes:** +**所需设置与属性:** -**Prefab Settings:** +**预制体设置:** -> * **Enable Nested Prefab:** \[Checked\] - * *Reason:* This is critical for pipeline management. Enabling Nested Prefab allows the child prefabs within the hierarchy (sails, boarding machines, oars, etc.) to be opened and edited independently without having to open the entire ship. Without this, editing any sub-component will modify the whole ship file, making iterative work slow and error-prone. -> * **Enable Write Children to Separate XMLs:** \[Checked\] - * *Reason:* This ensures each child prefab saves its data into its own XML file rather than embedding everything into a single large file. This is important for version control and for keeping the ship modular — changes to one component do not risk corrupting the rest of the ship's data. +> * **启用嵌套预制体(Enable Nested Prefab):** \[已勾选\] + * *原因:* 这对于流程管理至关重要。启用嵌套预制体允许层级结构中的子预制体(帆、登船机、桨等)独立打开和编辑,而无需打开整艘船。如果不这样做,编辑任何子组件都会修改整个船只文件,使迭代工作变得缓慢且容易出错。 +> * **启用将子项写入单独的 XML(Enable Write Children to Separate XMLs):** \[已勾选\] + * *原因:* 这确保每个子预制体将其数据保存到自己的 XML 文件中,而不是将所有内容嵌入到一个大文件中。这对于版本控制以及保持船只模块化非常重要——对一个组件的更改不会有损坏船只其余数据的风险。 -**Transform & Workspace:** +**变换(Transform)与工作空间:** -> * **Identity Transform:** Ensure the root entity is created at the generic identity coordinates (**Pos:** 0,0,0 | **Rot:** 0,0,0 | **Scale:** 1,1,1). - * *Reason:* The entire ship is positioned and rotated at runtime by the game's naval physics system. If the root entity has any offset or rotation baked into it, the ship will appear misaligned in-game and all child components will be offset as well. -> * **Local Space:** For all subsequent child components, perform all positioning and rotation operations using **Local Transform**. - * *Reason:* Child entities inherit the world transform of their parent. Working in local space ensures that when the root entity moves (as it will constantly during gameplay), all children move with it correctly. Working in world space will cause children to appear in the correct editor position but drift to incorrect positions in-game. +> * **恒等变换(Identity Transform):** 确保根实体是在通用的恒等坐标下创建的(**位置(Pos):** 0,0,0 | **旋转(Rot):** 0,0,0 | **缩放(Scale):** 1,1,1)。 + * *原因:* 整艘船在运行时由游戏的海战物理系统进行定位和旋转。如果根实体内置了任何偏移或旋转,船只在游戏中将显得错位,所有子组件也会随之偏移。 +> * **局部空间(Local Space):** 对于所有后续的子组件,使用**局部变换(Local Transform)**执行所有定位和旋转操作。 + * *原因:* 子实体继承其父级的世界变换。使用局部空间可以确保当根实体移动时(在游戏过程中会持续移动),所有子项都能随之正确移动。使用世界空间会导致子项在编辑器中的位置正确,但在游戏中漂移到不正确的位置。 -**Physics Configuration:** +**物理配置:** -> * **Physics Shape:** Assign a **Convex** physics shape that roughly encompasses the entire hull. - * *Reason:* This convex shape serves two critical purposes. First, it is the primary collision body of the ship — it determines what the ship physically bumps into in the world. Second, and more importantly for ships, it is the primary driver for the buoyancy system. The game engine calculates how much of this convex volume is submerged to determine the upward buoyancy force. If this shape is too large, the ship will float too high. If it is too small, the ship will sit too low or sink. Always use a mesh that closely follows the outer hull below the waterline. - * *Note:* If the provided mesh is not convex, the engine will attempt to approximate a convex hull automatically, but this approximation may not match the hull well. Providing a proper convex mesh is strongly recommended. -> * **Material:** Assign the wood\_ship physics material. - * *Reason:* The wood\_ship material defines how the ship's physics body responds to collisions — its friction, restitution (bounciness), and damage thresholds. Using the wrong material (or none at all) will cause the ship to behave incorrectly when colliding with terrain, other ships, or projectiles. -> * **Mass:** Input the correct physical weight of the ship. - * *Warning:* This value directly affects how the ship floats and reacts to water physics. A ship that is too light will bounce erratically on waves. A ship that is too heavy will sit too low in the water or sink entirely. Use the existing ships as reference points for appropriate mass values relative to their size. -> * **Body Flags:** Ensure the following flags are CHECKED: - * ✅ **Dynamic** — Allows the physics engine to move this body in response to forces. - * ✅ **Movable** — Required for the kinematic system that synchronizes ship movement with passengers and mounted objects. - * ✅ **Use Convex Hull** — Tells the physics engine to use the convex shape for collision. - * ✅ **Do Not Collide with Camera** — Prevents the camera from being blocked by the ship's physics body. - * ✅ **Do Not Collide with Ray Cast** — Prevents gameplay raycasts (such as targeting) from being blocked by the hull physics body. +> * **物理形状(Physics Shape):** 分配一个大致包裹整个船体的**凸形(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)** —— 防止游戏玩法射线检测(例如瞄准)被船体物理体阻挡。 - - -**Important:** Any physics body added to child entities of this root must also be marked as **Movable** in its flags. This is required because the root uses a kinematic physics system — child physics bodies that are not marked Movable will not move with the ship and will detach into incorrect world positions. + -#### **2.1.2. Scripts** +**重要:** 添加到此根实体的子实体上的任何物理体也必须在其标志中标记为**可移动(Movable)**。这是必需的,因为根实体使用的是运动学物理系统——未标记为可移动的子物理体不会随船只移动,而会脱离到错误的世界位置。 -The following scripts must be added directly to the root entity. The order in which you add them does not matter, but all of them must be present for the ship to function correctly. +#### **2.1.2. 脚本** -> * **MissionShip:** The core script that registers this entity as a ship within the game's mission system. Without this script, the game will not recognize the entity as a ship and none of the naval gameplay systems will activate. - * **Important:** You must assign the NavMesh name to the NavMeshPrefabName field. The NavMesh is a separate asset that defines where AI agents can walk on your ship's deck. NavMesh baking is covered in detail in the attachment\_machine\_holder section (2.1.7). -> * **Volume\_generator:** Handles the generation of floating volume objects that the buoyancy system uses to keep the ship upright and stable on the water surface. - * *Best Practice:* Perform this step after adding the hull mesh in mesh\_holder, since the generator needs the mesh to estimate correct volume placement. - * Enable **Mock Generation** to preview where floaters will be placed before committing. - * *Goal:* Keep the number of floatable objects to a minimum by adjusting **Current Volume Count** or **Floater Volume Width**. More volumes give more stable floating but cost more performance. - * Ensure generated volumes match the ship's hull shape as closely as possible. - * Click **Generate Volumes** to create the volume children under floater\_volume\_holder. -> * **ShipFloatsamManager:** Handles the spawning and behavior of debris and flotsam when the ship is destroyed. Ensures that broken planks, barrels, and other objects appear on the water surface after the ship sinks. -> * **ShipClothFixer:** Manages the cloth simulation systems on the ship (primarily sails and banners). Without this script, cloth objects on the ship may behave erratically or not simulate at all when the ship moves. -> * **ShipColorAssigner:** Controls faction-based color tinting across the ship. - * Factor Color: Applied to Upgrade Pieces such as seats and oars, tinting them to match the owning faction's colors. - * Ram Debris Color: Applied to collision damage decals that appear when the ship rams another vessel. -> * **EditorShipPhysics:** A utility script used only inside the editor. It lets you simulate and preview the ship's floating physics without having to launch the game, saving significant iteration time. -> * **NavalPhysics:** Handles the core swimming and buoyancy logic at runtime. This script works in conjunction with the floater volumes to keep the ship correctly oriented and moving on the water surface. -> * **EditorShipUpgradeViewer:** An editor utility that lets you preview how different upgrade pieces (sails, shields, figureheads, etc.) will appear on the ship without launching the game. -> * **ShipAttachmentMachineConnectionLogic:** Handles the connection logic between ships during boarding. It manages the state of boarding bridges — detecting when two ships are close enough, triggering the bridge deployment animation, and linking the two ships' NavMeshes. +以下脚本必须直接添加到根实体上。添加它们的顺序无关紧要,但所有脚本都必须存在,船只才能正常运作。 + +> * **MissionShip:** 核心脚本,将此实体注册为游戏任务系统中的一艘船。没有这个脚本,游戏将无法识别该实体是一艘船,所有海战玩法系统都不会被激活。 + * **重要:** 你必须将 NavMesh 名称分配给 NavMeshPrefabName 字段。NavMesh 是一个单独的资产,定义了 AI 代理可以在你的船只甲板上行走的位置。NavMesh 烘焙(baking)将在 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** -This entity contains the ship's main visual mesh and all static physics objects that are part of the ship's structure — platforms, stairs, interior decoration, and any other geometry that does not change based on upgrades. +该实体包含船只的主要视觉网格以及所有属于船只结构一部分的静态物理对象——平台、楼梯、内部装饰以及任何不会根据升级而变化的其他几何体。 -> * **Transform:** Must be kept at Identity (0,0,0 | 0,0,0 | 1,1,1). The mesh\_holder should never have any offset from the root entity. All positioning of individual meshes should be done on the child entities within this holder. -> * **Physics:** Any physics body added to a child of mesh\_holder must have the **Movable** flag enabled. See the note in section 2.1.1 for the reason. +> * **变换:** 必须保持为恒等状态(0,0,0 | 0,0,0 | 1,1,1)。mesh\_holder 不应相对于根实体有任何偏移。单个网格的所有定位都应在该容器内的子实体上完成。 +> * **物理:** 添加到 mesh\_holder 子项的任何物理体都必须启用**可移动(Movable)**标志。原因见 2.1.1 节中的说明。 - + -**Required Tags on the Main Hull Mesh:** +**主船体网格所需的标签:** -> * rope\_physics\_body — Marks this entity as the physics anchor point for dynamic rope simulations on the ship (rigging, tying lines, etc.). Ropes attached to the ship use this tagged entity as their root attachment. -> * body\_mesh — Identifies this entity as the primary visual hull. Multiple engine systems (including ShipWaterEffects) use this tag to perform raycasts against the hull to automatically compute particle positions, waterline height, and other visual parameters. This tag must exist and the entity must have a valid MetaMesh with an accurate bounding box. -> * hull\_water\_mesh — Marks the mesh used specifically by the in-hull water simulation system. This mesh defines the visual interior surface on which the simulated deck water is rendered. +> * rope\_physics\_body —— 将此实体标记为船上动态绳索模拟(索具、系绳等)的物理锚点。附着在船上的绳索使用该标记实体作为其根附着点。 +> * body\_mesh —— 将此实体标识为主要的视觉船体。多个引擎系统(包括 ShipWaterEffects)使用此标签对船体执行射线检测,以自动计算粒子位置、水线高度和其他视觉参数。此标签必须存在,且该实体必须具有带有准确包围盒的有效 MetaMesh。 +> * hull\_water\_mesh —— 标记专门用于船体内部水体模拟系统的网格。该网格定义了模拟甲板积水所渲染的视觉内部表面。 -**Deckwater Setup:** Create a child object named deckwater inside mesh\_holder and assign it the tag render\_to\_depth. +**甲板积水(Deckwater)设置:** 在 mesh\_holder 内创建一个名为 deckwater 的子对象,并为其分配 render\_to\_depth 标签。 -> * *Reason:* The render\_to\_depth tag tells the ship water effects system to include this mesh in the top-down depth render used to define where simulated water can accumulate on the deck. Any mesh with this tag (including oar seats and other deck furniture) contributes to the depth texture. After adding or modifying render\_to\_depth meshes, press **Re-render Depth Texture** in the ShipWaterEffects script to update the simulation. +> * *原因:* render\_to\_depth 标签告诉船只水效果系统将此网格包含在用于定义甲板上模拟水体可以积聚位置的俯视深度渲染中。任何带有此标签的网格(包括桨座和其他甲板家具)都会对深度纹理做出贡献。添加或修改 render\_to\_depth 网格后,请在 ShipWaterEffects 脚本中点击 **Re-render Depth Texture(重新渲染深度纹理)** 以更新模拟。 #### **2.1.4. floater\_volume\_holder** -This entity is the container for the buoyancy volume objects automatically created by the Volume\_generator script on the root entity. You should not manually create or modify children here — always use the generator. +该实体是根实体上 Volume\_generator 脚本自动创建的浮力体积对象的容器。你不应在此手动创建或修改子项——始终使用生成器。 -> * **Verification:** After generating volumes, visually inspect them in the editor to confirm they cover the submerged portion of the hull correctly. Volumes that extend too far above the waterline will make the ship sit unnaturally high. Volumes that do not reach far enough into the hull will cause instability. +> * **验证:** 生成体积后,在编辑器中直观检查它们,以确认它们正确覆盖了船体的淹没部分。延伸到水线以上太远的体积会使船只显得异常地高。没有深入船体足够远的体积会导致不稳定。 - + -> * **Visibility:** Disable the visibility of this entity in the Entity Inspector once you have verified the volumes. The volume objects are purely functional and should not be visible during normal editing, as they clutter the viewport. +> * **可见性:** 一旦验证了体积,就在实体检查器(Entity Inspector)中禁用此实体的可见性。这些体积对象纯粹是功能性的,在正常编辑期间不应可见,因为它们会使视口变得杂乱。 #### **2.1.5. control\_point\_holder** -This entity contains the ship's steering mechanism. The type of steering prefab you use here depends on the physical design of the ship. +该实体包含船只的转向机制。此处使用的转向预制体类型取决于船只的物理设计。 -> * **ShipControl\_nested:** Use this prefab for tall ships or any ship where the rudder does not physically reach the water surface, or where steering is not performed by a visible in-world rudder (e.g., the steering is abstracted). This prefab handles steering logic without requiring a physical rudder mesh interaction. -> * **ShipControlRudder\_nested:** Use this prefab for lower ships where the rudder physically extends into the water and is operated manually by an agent. This is the more physically immersive option. - * *Config:* Assign the rudder mesh and physics body to the controller's child entity as a metamesh. The physics shape of the rudder should match its visual mesh closely, as agents will physically interact with it. +> * **ShipControl\_nested:** 用于高大的船只,或者舵在物理上无法触及水面的船只,或者转向不是由可见的世界内舵来执行的船只(即转向是抽象的)。此预制体处理转向逻辑,而不需要物理舵网格交互。 +> * **ShipControlRudder\_nested:** 用于较低矮的船只,其舵在物理上延伸入水中,并由一个代理手动操作。这是更具物理沉浸感的选项。 + * *配置:* 将舵网格和物理体作为 metamesh 分配给控制器的子实体。舵的物理形状应紧密匹配其视觉网格,因为代理会与其进行物理交互。 #### **2.1.6. climbers\_holder** -This entity contains the prefabs that allow agents (both AI and players) to climb from the water surface onto the ship's deck. This is essential for boarding sequences where agents swim to the ship. +该实体包含允许代理(AI 和玩家均可)从水面爬上船只甲板的预制体。这对于代理游到船边的登船序列是必不可少的。 -Use the prefabs: longboat\_rope\_climber\_small\_nested, longboat\_rope\_climber\_medium\_nested, or longboat\_rope\_climber\_large\_nested depending on the height of the ship's railing above the water. +根据船只栏杆高出水面的高度,使用预制体:longboat\_rope\_climber\_small\_nested、longboat\_rope\_climber\_medium\_nested 或 longboat\_rope\_climber\_large\_nested。 -Each climber prefab contains three key child entities: +每个攀爬预制体包含三个关键子实体: -> * climb\_point — The position on the deck where the agent lands after completing the climb animation. Place this on the deck surface, inboard of the railing. -> * end\_position — The top of the climbing animation. This should be at or just above the railing height. -> * standing\_point — The bottom of the climbing animation, at water level. This is where the agent begins the climb. You can adjust the precise starting position via the script on this entity. +> * climb\_point —— 代理完成攀爬动画后落脚的甲板位置。将其放置在甲板表面,位于栏杆内侧。 +> * end\_position —— 攀爬动画的顶部。应位于栏杆高度处或略高于栏杆。 +> * standing\_point —— 攀爬动画的底部,位于水面处。这是代理开始攀爬的位置。你可以通过该实体上的脚本调整精确的起始位置。 -*Reason:* Without correctly placed climbers, agents that end up in the water near the ship will have no way to reboard, breaking the boarding gameplay loop. +*原因:* 如果没有正确放置攀爬点,最终落水在船附近的代理将无法重新登船,从而破坏登船玩法循环。 -#### **2.1.7. attachment\_machine\_holder (Boarding System)** +#### **2.1.7. attachment\_machine\_holder(登船系统)** -This section contains the prefabs required for the boarding mechanics. This is one of the more complex parts of the ship setup. There are two main prefab types: +本节包含登船机制所需的预制体。这是船只设置中较为复杂的部分之一。主要有两种预制体类型: -> * **attachment\_machine\_nested:** Contains all entities required for both incoming and outgoing boarding — i.e., this handles our ship boarding an enemy and an enemy boarding our ship. -> * **attachment\_point\_machine\_nested:** Contains entities required only for an enemy ship to board our ship (the receiving side of a boarding action). +> * **attachment\_machine\_nested:** 包含进出双向登船所需的所有实体——即处理我方船只登上敌船以及敌船登上我方船只两种情况。 +> * **attachment\_point\_machine\_nested:** 仅包含敌船登上我方船只(登船动作的接收方)所需的实体。 - + -**a) attachment\_machine\_nested Structure:** +**a) attachment\_machine\_nested 结构:** -> * distance\_helper: A visual entity in the editor that shows the minimum required distance between two ships before a boarding bridge can be deployed. This prevents bridges from overlapping each other or clipping through geometry. -> * **attachment\_machine (Parent):** - * hook: The visual representation of the grappling hook thrown by agents when initiating boarding. This should be a small mesh placed at the hook's resting position. - * pilot: A non-physics entity placed on the deck directly above where the boarding bridge's NavMesh connection should begin. The game uses the position of this entity to stitch the bridge's NavMesh to the ship's deck NavMesh. See the NavMesh configuration section below. - * focus\_object: The physics object that agents must hit with their hook throw for a successful boarding attempt. Place this at the ship's railing where the hook would realistically catch. - * pile\_holder: A parent entity containing the visual ropes and hanging elements of the boarding setup. These are purely visual — they have no physics or interaction. +> * distance\_helper: 编辑器中的一个可视化实体,显示在跳板可以展开之前两艘船之间所需的最小距离。这可以防止跳板相互重叠或穿透几何体。 +> * **attachment\_machine(父级):** + * hook: 代理发起登船时投掷的抓钩的视觉表现。这应该是一个放置在钩子静止位置的小网格。 + * pilot: 一个非物理实体,放置在甲板上,正位于登船跳板 NavMesh 连接应开始的位置之上。游戏使用该实体的位置将跳板的 NavMesh 与船只甲板的 NavMesh 缝合起来。参见下方的 NavMesh 配置部分。 + * focus\_object: 代理投掷抓钩时必须命中的物理对象,以使登船尝试成功。将其放置在船只栏杆上,钩子实际会钩住的位置。 + * pile\_holder: 包含登船设置中可视绳索和悬挂元素的父实体。这些纯粹是视觉性的——它们没有物理或交互功能。 -**b) attachment\_point\_machine\_nested Structure:** +**b) attachment\_point\_machine\_nested 结构:** -> * hook\_attach\_point: A non-physics entity indicating where an enemy's grappling hook lands on our railing after a successful hook throw. Place this on the railing surface. -> * pilot: A non-physics entity requiring a NavMesh face underneath it for bridge NavMesh connection. Functions identically to the pilot in attachment\_machine\_nested. -> * **visual (Parent):** - * bridge\_target\_point: Parent for the non-physics visual objects that appear on the railing and deck after the enemy sets up a bridge. Default visibility should be Off — the game activates these when a bridge is established. - * bridge\_connection\_point: Defines the start or end point of the boarding bridge. Must be placed precisely on the railing, ensuring it is not buried inside the railing's physics mesh. If this point is inside geometry, the bridge will clip incorrectly. - * bridge\_source\_point: Parent for non-physics visual objects that appear after the hook successfully catches and the bridge begins deploying. Default visibility should be Off. - * focus\_object: The physics object that must be hit for a successful hook shot from an enemy ship. - * capsule\_physics\_a: A physics capsule that allows agents to climb from the deck up to the railing height when a bridge is active. This object is inactive when no bridge is present — activating it when no bridge exists would let agents walk off the ship into the air. - * *Snap Requirement:* The top of this capsule must snap exactly to the bridge\_connection\_point. - * *Auto-Snap:* You can place it manually by enabling physics visuals, or use the **Auto Arrange Bridge Ramp Physics** button in the root entity's Volume\_generator script to automatically snap all capsule physics objects at once. +> * hook\_attach\_point: 一个非物理实体,指示敌方的抓钩成功投掷后落在我方栏杆上的位置。将其放置在栏杆表面上。 +> * pilot: 一个非物理实体,下方需要有一个 NavMesh 面以供跳板 NavMesh 连接。功能与 attachment\_machine\_nested 中的 pilot 相同。 +> * **visual(父级):** + * bridge\_target\_point: 敌方成功架设跳板后出现在栏杆和甲板上的非物理视觉对象的父节点。默认可见性应为关闭——游戏会在建立跳板时激活它们。 + * bridge\_connection\_point: 定义登船跳板的起点或终点。必须精确放置在栏杆上,确保它没有埋入栏杆的物理网格内部。如果该点位于几何体内部,跳板会发生错误的穿模。 + * bridge\_source\_point: 钩子成功钩中且跳板开始展开后出现的非物理视觉对象的父节点。默认可见性应为关闭。 + * focus\_object: 敌船成功投掷抓钩所必须命中的物理对象。 + * capsule\_physics\_a: 一个物理胶囊体,允许代理在跳板激活时从甲板爬到栏杆高度。当没有跳板时,该对象处于非激活状态——如果在没有跳板的情况下激活它,会让代理走出船只、悬空在空中。 + * *对齐要求:* 该胶囊体的顶部必须精确对齐到 bridge\_connection\_point。 + * *自动对齐:* 你可以通过启用物理可视化来手动放置它,或者使用根实体 Volume\_generator 脚本中的 **Auto Arrange Bridge Ramp Physics(自动排列跳板斜坡物理体)** 按钮一次性自动对齐所有胶囊物理对象。 - + -* \_barrier\_ai\_04x04m\_nested: An AI barrier that prevents agents from walking off the ship at the boarding connection point when no bridge is present. This barrier deactivates automatically when a bridge is established, allowing agents to cross. +* \_barrier\_ai\_04x04m\_nested: 一个 AI 屏障,当没有跳板时,防止代理在登船连接点处走出船外。当跳板建立后,该屏障会自动失效,允许代理通过。 -**c) NavMesh Configuration & Baking:** -The NavMesh defines where AI agents can walk on your ship's deck. It must be baked correctly for boarding bridges to function. The bridge system connects two ships' NavMeshes dynamically at runtime, and the IDs below are how it knows which face to connect to. +**c) NavMesh 配置与烘焙:** +NavMesh 定义了 AI 代理可以在船只甲板上行走的位置。必须正确烘焙它,登船跳板才能正常工作。跳板系统在运行时动态连接两艘船的 NavMesh,下面的 ID 就是它用来识别要连接哪个面的方式。 -> * **Unique IDs:** In the ShipAttachmentPointMachine script (found in both machine prefabs), locate the RelatedShipNavmeshOffset field. Enter a unique integer ID here for each machine. No two machines on the same ship should share an ID. -> * **Face IDs:** In the ship's NavMesh, the face located directly beneath the pilot entity of each machine must have the same ID as entered in RelatedShipNavmeshOffset. The game uses this matching ID to know which NavMesh face is the connection point for each bridge. -> * **General Deck:** All other NavMesh faces on the ship's deck that are not bridge connection points should be assigned ID 0\. +> * **唯一 ID:** 在 ShipAttachmentPointMachine 脚本中(两种机器预制体中均有),找到 RelatedShipNavmeshOffset 字段。为每台机器输入一个唯一的整数 ID。同一艘船上的两台机器不应共享相同的 ID。 +> * **面 ID:** 在船只的 NavMesh 中,位于每台机器 pilot 实体正下方的面必须具有与在 RelatedShipNavmeshOffset 中输入的相同 ID。游戏使用这个匹配的 ID 来识别哪个 NavMesh 面是每个跳板的连接点。 +> * **普通甲板:** 船只甲板上所有非跳板连接点的其他 NavMesh 面都应分配 ID 0。 -**Baking and Saving:** +**烘焙与保存:** -> 1. Select all NavMesh faces. -> 2. Go to the MissionShip script on the root entity. -> 3. Click **SaveNavMeshFromLocal**. -> 4. Enter a filename and save it to your mod's module folder. -> 5. Enter this filename into the NavMeshPrefabName field in the MissionShip script. +> 1. 选择所有 NavMesh 面。 +> 2. 转到根实体上的 MissionShip 脚本。 +> 3. 点击 **SaveNavMeshFromLocal**。 +> 4. 输入文件名,并将其保存到你的模组模块文件夹中。 +> 5. 将此文件名输入到 MissionShip 脚本的 NavMeshPrefabName 字段中。 - + #### **2.1.8. barrier\_holder** -This entity contains barrier physics objects that prevent AI agents from walking off the ship's edges or into areas they should not reach (below-deck openings, the end of a bowsprit, etc.). +该实体包含物理屏障对象,防止 AI 代理走出船只边缘或进入不应到达的区域(甲板下开口、船首斜桅末端等)。 + +使用预制体:\_barrier\_ai\_04x04m\_nested 或 \_barrier\_ai\_04x08m\_nested。它们在功能上是相同的——唯一的区别在于默认尺寸。根据需要缩放以覆盖该区域。 -Use prefabs: \_barrier\_ai\_04x04m\_nested or \_barrier\_ai\_04x08m\_nested. These are functionally identical — the only difference is their default size. Scale them as needed to cover the area. - -*Reason:* Without barriers, the AI NavMesh system may generate valid paths that lead agents off the edge of the ship. The barriers create invisible walls that the NavMesh system respects, keeping agents on the deck. +*原因:* 如果没有屏障,AI 的 NavMesh 系统可能会生成导致代理走出船只边缘的有效路径。屏障会创建 NavMesh 系统所遵守的无形墙壁,从而将代理保持在甲板上。 #### **2.1.9. ship\_target\_point** -This entity holds the ShipTargetMissionObject script and must be present on every ship. It registers the ship as a **targetable object** within the game's combat system — without it, ranged weapons such as ballistas cannot lock onto the ship. +该实体持有 ShipTargetMissionObject 脚本,必须存在于每艘船上。它将船只注册为游戏战斗系统中的**可被瞄准对象**——没有它,诸如弩炮之类的远程武器将无法锁定该船只。 -**What it does:** +**其功能:** -> * Marks the ship as a valid target for ranged weapons (TargetFlags.IsShip | TargetFlags.IsMoving). -> * Reports the ship's current velocity so projectiles can lead their aim correctly against a moving ship. -> * Provides a target priority value that scales with the ship's remaining crew count and hull health. A heavily damaged or nearly crewless ship becomes a lower-priority target automatically. -> * When the ship is sinking, it adds the NotAThreat flag so AI ranged units stop targeting it and redirect fire elsewhere. +> * 将船只标记为远程武器的有效目标(TargetFlags.IsShip | TargetFlags.IsMoving)。 +> * 报告船只当前的速度,以便抛射物能够正确地对移动中的船只进行提前量瞄准。 +> * 提供一个目标优先级数值,该数值根据船只剩余的船员数量和船体耐久度进行缩放。严重受损或几乎没有船员的船只会自动变为较低优先级的目标。 +> * 当船只正在下沉时,会添加 NotAThreat 标志,使 AI 远程单位停止瞄准它,并将火力转移到其他地方。 -**Setup:** Add the ship\_target\_point nested prefab as a direct child of the ship root. No additional configuration is required — the script reads the ship's state automatically at runtime via the MissionShip script on the root entity. +**设置:** 将 ship\_target\_point 嵌套预制体添加为船只根节点的直接子项。不需要额外配置——该脚本会通过根实体上的 MissionShip 脚本在运行时自动读取船只的状态。 #### **2.1.10. kinematic\_batch\_entity** -The kinematic\_batch\_entity system handles physics optimization for the ship. Without it, every child entity on the ship with a physics body would be simulated individually, which becomes expensive quickly. This system merges all those physics shapes into a single batched body that moves with the ship root — at a fraction of the cost. +kinematic\_batch\_entity 系统处理船只的物理优化。如果没有它,船上每个带有物理体的子实体都会被单独模拟,这很快就会变得昂贵。该系统将所有这些物理形状合并为一个随船只根节点移动的单一批处理体——而成本只是一小部分。 -**How it works:** The ship root owns the main physics body (the convex hull). All the detailed collision shapes on child entities — hull planks, deck surfaces, structural parts — need to move with the ship but do not need their own simulation. The kinematic\_batch\_entity collects all of these into two batching containers: +**工作原理:** 船只根节点拥有主要的物理体(凸包)。子实体上所有详细的碰撞形状——船体木板、甲板表面、结构部件——都需要随船只移动,但不需要各自进行模拟。kinematic\_batch\_entity 将这些全部收集到两个批处理容器中: -> * simulated — Batches shapes used for full physics interaction (collision response, agents walking on deck, etc.) -> * ray\_cast — Batches shapes used only for raycasts (targeting, line-of-sight, etc.) +> * simulated —— 批处理用于完整物理交互的形状(碰撞响应、代理在甲板上行走等) +> * ray\_cast —— 批处理仅用于射线检测的形状(瞄准、视线检测等) -**Required Setup:** -Add the kinematic\_batch\_entity as a nested prefab directly under the ship root. The prefab is located at: NavalDLC/NestedPrefabs/kinematic\_batch\_entity.xml +**所需设置:** +将 kinematic\_batch\_entity 作为嵌套预制体直接添加到船只根节点下。该预制体位于:NavalDLC/NestedPrefabs/kinematic\_batch\_entity.xml -After placing it, verify the following in the entity inspector: +放置后,在实体检查器中验证以下内容: -> * Its transform is identity (position 0,0,0 — no rotation, no scale offset). -> * Its body flag includes Moveable. -> * It carries the tag batched\_physics\_entity. -> * Both the simulated and ray\_cast children must be present. The engine will warn if either is missing. +> * 其变换为恒等状态(位置 0,0,0——无旋转,无缩放偏移)。 +> * 其刚体标志包含 Moveable。 +> * 它带有 batched\_physics\_entity 标签。 +> * simulated 和 ray\_cast 两个子项都必须存在。如果缺少任意一个,引擎将发出警告。 -**Marking entities for batching:** For each child entity whose physics shape should be merged into the batch, enable the **Move To Batched Kinematic** option in its physics properties. +**标记要批处理的实体:** 对于其物理形状应合并到批处理中的每个子实体,在其物理属性中启用 **Move To Batched Kinematic(移至批处理运动学)** 选项。 -In the entity's **Physics** panel: +在该实体的**物理(Physics)**面板中: -> 1. Assign a physics shape (a bo\_ body). -> 2. Enable the Moveable body flag. -> 3. Enable **Move To Batched Kinematic**. +> 1. 分配一个物理形状(一个 bo\_ 体)。 +> 2. 启用 Moveable 刚体标志。 +> 3. 启用 **Move To Batched Kinematic**。 -**What to batch:** Hull mesh, deck structures, mast holders, hull plating variants, fixed structural geometry. -**What NOT to batch:** The ship root itself, the kinematic\_batch\_entity and its children, AI barrier entities, rope/cloth physics, and any entities that animate or detach independently at runtime. -**Upgrade variants:** If your ship has multiple hull variants under an upgrade slot, each variant can have **Move To Batched Kinematic** enabled. The engine only includes shapes that are active when the ship is initialized — ensure exactly one variant per slot is active at startup. +**应批处理的内容:** 船体网格、甲板结构、桅杆座、船体铺板变体、固定的结构几何体。 +**不应批处理的内容:** 船只根节点本身、kinematic\_batch\_entity 及其子项、AI 屏障实体、绳索/布料物理,以及任何在运行时独立动画或脱离的实体。 +**升级变体:** 如果你的船只在某个升级槽下有多个船体变体,每个变体都可以启用 **Move To Batched Kinematic**。引擎只会包含船只初始化时处于激活状态的形状——确保每个槽位在启动时只有一个变体处于激活状态。 -**Common validation errors:** +**常见验证错误:** -> * No entity tagged batched\_physics\_entity found → *"Ship Prefab must contain a root batched physics entity\!"* -> * kinematic\_batch\_entity does not have identity transform → *"Batched physics entity should have identity matrix frame\!"* -> * Missing simulated or ray\_cast child → *"Ships should have a 'kinematics'/'raycast' batch entity\!"* +> * 未找到标记为 batched\_physics\_entity 的实体 → *"Ship Prefab must contain a root batched physics entity!"(船只预制体必须包含一个根批处理物理实体!)* +> * kinematic\_batch\_entity 没有恒等变换 → *"Batched physics entity should have identity matrix frame!"(批处理物理实体应具有恒等矩阵坐标系!)* +> * 缺少 simulated 或 ray\_cast 子项 → *"Ships should have a 'kinematics'/'raycast' batch entity!"(船只应具有一个 'kinematics'/'raycast' 批处理实体!)* -If any of these warnings appear, physics batching is not working and the ship may have performance issues or missing collision. +如果出现上述任何警告,则表示物理批处理未正常工作,船只可能存在性能问题或碰撞缺失。 #### **2.1.11. spawn\_point\_holder** -This entity defines all spawn locations for players and AI troops on the ship. The game's mission system reads these points to determine where to place agents at the start of a naval battle. +该实体定义了船只上玩家和 AI 部队的所有生成位置。游戏的任务系统会读取这些点,以确定在海战开始时将代理放置在何处。 -> * sp\_troop\_inner\_deck\_nested: Spawn points for inner deck troops — agents positioned away from the ship's edges, typically in the center or below decks. -> * sp\_troop\_outer\_deck\_nested: Spawn points for outer deck troops — agents positioned near the railings and edges, such as archers and sailors. -> * sp\_troop\_captain\_nested: The spawn point for the ship's captain. -> * sp\_troop\_crew\_spawn\_nested: Spawn points used for reinforcement troops arriving during battle. +> * sp\_troop\_inner\_deck\_nested: 内甲板部队的生成点——代理被放置在远离船只边缘的位置,通常位于中央或甲板下方。 +> * sp\_troop\_outer\_deck\_nested: 外甲板部队的生成点——代理被放置在靠近栏杆和边缘的位置,例如弓箭手和水手。 +> * sp\_troop\_captain\_nested: 船长的生成点。 +> * sp\_troop\_crew\_spawn\_nested: 用于战斗期间到达的增援部队的生成点。 -**rally\_point:** Create an empty entity and place it at the front of the ship, on the NavMesh surface. +**rally\_point(集合点):** 创建一个空实体,并将其放置在船首,位于 NavMesh 表面上。 -> * Assign the tag rally\_point to this entity. -> * Rename the entity to rally\_point for clarity. -> * *Reason:* This is the gathering point AI agents move toward when given a rally order. Without a rally point, AI agents will have no defined gathering location and may behave erratically when ordered to regroup. +> * 为该实体分配 rally\_point 标签。 +> * 将该实体重命名为 rally\_point 以便清晰识别。 +> * *原因:* 这是 AI 代理在收到集合命令时前往的集合点。如果没有集合点,AI 代理将没有明确的集合位置,在被命令重新集结时可能行为异常。 #### **2.1.12. rudders\_holder** -This entity defines the rudder's position for the swimming and buoyancy physics calculations — specifically, it tells the physics system where the ship's steering resistance is applied in the water. +该实体为游泳和浮力物理计算定义舵的位置——具体来说,它告诉物理系统船只的转向阻力在水中的施加位置。 -> * **Placement:** Place this entity at the very rear of the ship, as close to the water surface as possible. -> * **Setup:** Add an empty entity as a child, name it rudder\_stock, and assign the tag rudder\_stock to it. -> * *Reason:* The physics system uses the rudder\_stock tag to locate the steering point of the ship. Placing this incorrectly (too far forward or too high) will cause the ship to handle unrealistically — it may turn too quickly, too slowly, or pivot around the wrong point. +> * **放置:** 将此实体放置在船只的最尾部,尽可能靠近水面。 +> * **设置:** 添加一个空实体作为子项,将其命名为 rudder\_stock,并为其分配 rudder\_stock 标签。 +> * *原因:* 物理系统使用 rudder\_stock 标签来定位船只的转向点。如果放置不正确(太靠前或太高),会导致船只的操控表现不真实——它可能转向过快、过慢,或围绕错误的点旋转。 #### **2.1.13.oars\_holder** -*This holder contains the ship's oar systems. Oars are a gameplay upgrade — they determine the ship's speed when sailing without wind. The oar\_deck prefab handles both the visual oar meshes and the agent seating system for rowers.* +*该容器包含船只的桨系统。桨是一种玩法升级——它们决定了船只在无风情况下航行的速度。oar\_deck 预制体同时处理视觉上的桨网格和划桨手的坐姿系统。* -> * *Root Setup: Create an empty entity at Identity and name it oars\_holder.* -> * *Add the oar\_deck prefab as a child. Rename it based on its type:* - * *oar\_deck\_upper: Rowers are seated on the open deck, visible to the player.* - * *oar\_deck\_lower: Rowers are seated inside the hull, not directly visible.* +> * *根设置:在恒等位置创建一个空实体,并将其命名为 oars\_holder。* +> * *添加 oar\_deck 预制体作为子项。根据其类型重命名:* + * *oar\_deck\_upper: 划桨手坐在开放甲板上,玩家可见。* + * *oar\_deck\_lower: 划桨手坐在船体内部,不直接可见。* -**a) oar\_deck\_upper (Visible Oarsmen):** +**a) oar\_deck\_upper(可见划桨手):** - + -> * *Configuration:* Select the oar\_deck\_upper entity and click **ManageOarMachines** in the ShipOarDeck script. -> * *Initial Setup:* Do not check **Override Prefabs** when creating for the first time. -> * *Prefab Set:* Select the set that matches your ship's size (UpperDeck 4m, 6m, or 8m — the number refers to the spacing between oar positions). -> * *Positioning:* Use the **Count**, **Span**, and **Offset** values to align the oar positions with your hull. This requires iteration — adjust the values, click apply, and visually verify the positions. The oar tips should enter the water cleanly and the handles should sit naturally in the agents' hands. -> * *Seat Heights (Critical):* Use the **Adjust Seat Heights** feature after positioning. This is mandatory. The rowing animation is fixed, and the seats must be at the correct height for the animation to align with the benches. If seat heights are wrong, rowers will visually clip through or float above their seats. +> * *配置:* 选择 oar\_deck\_upper 实体,并在 ShipOarDeck 脚本中点击 **ManageOarMachines**。 +> * *初始设置:* 首次创建时不要勾选 **Override Prefabs(覆盖预制体)**。 +> * *预制体集:* 选择与你船只尺寸匹配的预制体集(UpperDeck 4m、6m 或 8m——该数字指的是桨位之间的间距)。 +> * *定位:* 使用 **Count(数量)**、**Span(跨距)** 和 **Offset(偏移)** 值将桨位与船体对齐。这需要反复迭代——调整数值,点击应用,然后直观地验证位置。桨尖应干净利落地入水,手柄应自然地握在代理的手中。 +> * *座椅高度(关键):* 在定位之后使用 **Adjust Seat Heights(调整座椅高度)** 功能。这是强制性的。划桨动画是固定的,座椅必须处于正确的高度才能与动画对齐长凳。如果座椅高度不对,划桨手在视觉上会穿模或悬浮在座椅上方。 -> * *Angles:* Adjust the active (in-water) and retracted (raised) angle of the oars to match your hull geometry. -> * *Mirroring:* Once one side is correctly configured, use the **Mirror** feature to copy all settings to the opposite side. +> * *角度:* 调整桨的激活(入水)和收起(抬起)角度,以匹配你的船体几何形状。 +> * *镜像:* 一旦一侧配置正确,使用 **Mirror(镜像)** 功能将所有设置复制到另一侧。 -**b) oar\_deck\_lower (Internal Rowers):** +**b) oar\_deck\_lower(内部划桨手):** -> * *Setup:* Follows the same process as oar\_deck\_upper, but select the **Lower Deck** prefab set. -> * *No seat height adjustment is required for lower deck rowers.* -> * *Ensure the oars align with and exit cleanly through the oar ports in the hull mesh. Misaligned oars will visually clip through the hull.* -> * *Retracted State:* Ensure the retracted oar angle places the oars completely inside the hull. Oars that stick out when retracted will clip through the hull and look incorrect. +> * *设置:* 遵循与 oar\_deck\_upper 相同的流程,但选择 **Lower Deck(下层甲板)** 预制体集。 +> * *下层甲板划桨手不需要调整座椅高度。* +> * *确保桨与船体网格上的桨口对齐,并干净利落地穿出。错位的桨会在视觉上穿透船体。* +> * *收起状态:* 确保收起的桨角度将桨完全置于船体内部。收起时伸出的桨会穿透船体,看起来不正确。* -**c) Upgrade System Integration:** +**c) 升级系统集成:** -> * *Oars are treated as upgrade pieces by the game's upgrade system.* -> * *Different oar sets (bronze-tipped, fire-hardened, etc.) can be created by editing the ship\_upgrade\_pieces.xml and ship\_slots.xml files, using existing oar entries as a reference.* -> * *When adding new oar types, verify the prefab hierarchy structure matches existing types, or the upgrade system will not recognize the new piece.* +> * *桨被游戏的升级系统视为升级部件。* +> * *可以通过编辑 ship\_upgrade\_pieces.xml 和 ship\_slots.xml 文件,参考现有的桨条目来创建不同的桨套装(铜制桨尖、火硬化桨等)。* +> * *添加新的桨类型时,请验证预制体层级结构是否与现有类型匹配,否则升级系统将无法识别新部件。* -#### **2.1.14. sail\_holder (War Sails System)** +#### **2.1.14. sail\_holder(War Sails 帆系统)** -Sails are one of the most technically complex components of the ship. They use a combination of skeletal animation, blend shape morphs, and real-time cloth simulation to achieve realistic behavior in wind. Read this section carefully before beginning sail setup. +帆是船只中技术上最复杂的组件之一。它们结合使用骨骼动画、混合形变(blend shape)和实时布料模拟,以实现在风中逼真的表现。开始帆的设置之前,请仔细阅读本节。 -There are two sail types: **Square** (rectangular sails hung from a yard) and **Lateen** (triangular sails on an angled boom). Each type comes in three size variants (small, medium, large), giving six total sail prefabs. +有两种帆类型:**方形帆(Square)**(悬挂在帆桁上的矩形帆)和**三角帆(Lateen)**(安装在倾斜桁杆上的三角形帆)。每种类型都有三种尺寸变体(小、中、大),总共形成六种帆预制体。 -**a) Asset Preparation:** +**a) 资产准备:** -> * **Cloth Simulation Mesh:** The sail mesh used for cloth simulation must fit within **15m × 15m × 15m** dimensions in its default (fully open) state. The prefab entity can be scaled in-game, but the source mesh must stay within this limit. -> * **Topology:** The mesh's polygon density and edge flow control how the cloth deforms. Denser topology in areas that should billow will produce more detailed cloth movement. +> * **布料模拟网格:** 用于布料模拟的帆网格在其默认(完全展开)状态下必须符合 **15m × 15m × 15m** 的尺寸限制。预制体实体可以在游戏中进行缩放,但源网格必须保持在此限制范围内。 +> * **拓扑结构:** 网格的多边形密度和边缘流向控制着布料的变形方式。在应该鼓起的区域使用更密集的拓扑结构,将产生更精细的布料运动效果。 -**Vertex Constraints (Critical — using Vertex Color channels):** +**顶点约束(关键——使用顶点颜色通道):** -> * **Alpha channel \= 0:** Vertices that must not move (attached to the mast or boom). Without this, the sail will detach from its mount during simulation. -> * **Red channel \= 0:** Vertices connected to the left control bone. -> * **Green channel \= 0:** Vertices connected to the right control bone. -> * **Blue channel \= 0:** Vertices in stitched areas (seams). These areas simulate tension between panels. -> * *In-Game:* Enable **Create Stitching Constraints** in the cloth settings for stitching to take effect. +> * **Alpha 通道 = 0:** 不得移动的顶点(附着在桅杆或帆桁上的顶点)。如果没有这个设置,帆会在模拟过程中从其挂载点上脱离。 +> * **红色通道 = 0:** 连接到左侧控制骨骼的顶点。 +> * **绿色通道 = 0:** 连接到右侧控制骨骼的顶点。 +> * **蓝色通道 = 0:** 位于缝合区域(接缝)的顶点。这些区域模拟各面料板之间的张力。 +> * *在游戏中:* 在布料设置中启用 **Create Stitching Constraints(创建缝合约束)**,以使缝合效果生效。 -**b) Rigging & Skeleton:** +**b) 索具与骨骼:** -> * A skeleton drives the control bones that adjust sail tension and yard angle. -> * **Square Sail:** Uses 2 control bones (one for each end of the yard). -> * **Lateen Sail:** Uses 1 control bone (the tip of the boom). -> * Bone names must match the names shown in the reference hierarchy images exactly, even if the skeleton object itself has a different name. +> * 骨骼驱动着调整帆张力和帆桁角度的控制骨。 +> * **方形帆:** 使用 2 个控制骨(帆桁两端各一个)。 +> * **三角帆:** 使用 1 个控制骨(桁杆尖端)。 +> * 骨骼名称必须与参考层级结构图中显示的名称完全匹配,即使骨骼对象本身有不同的名称。 -**c) Animation & States:** +**c) 动画与状态:** -> * **Morph Animation:** A 200-frame morph animation is required, representing the sail transitioning from fully open to fully closed. The same morph is played in reverse for the unfurling animation. This animation drives the furling and unfurling sequence players see when the sail order is given. -> * **Closed State:** When fully furled, the cloth mesh is swapped with a static mesh representing the bundled sail. The cloth simulation is inactive in this state. -> * **Burning State:** If the sail catches fire, it transitions to a free-hanging mesh that simulates a torn, burning sail. This mesh does not require a skeleton or morph keys — it is purely visual cloth with no control. +> * **变形动画(Morph Animation):** 需要一个 200 帧的变形动画,表示帆从完全展开到完全收拢的过渡。同样的变形会反向播放以用于展开动画。这个动画驱动着玩家在下达收帆指令时看到的收帆和展帆序列。 +> * **收拢状态:** 完全收拢后,布料网格会被替换为代表捆扎好的帆的静态网格。在此状态下,布料模拟处于非激活状态。 +> * **燃烧状态:** 如果帆着火,它会转变为模拟撕裂、燃烧中的帆的自由悬挂网格。此网格不需要骨骼或变形关键帧——它纯粹是没有控制的视觉布料。 -**d) Prefab Setup (using sail\_square\_medium\_nested as example):** +**d) 预制体设置(以 sail\_square\_medium\_nested 为例):** -Add the sail\_visual script to the topmost parent of the sail prefab and select the correct sail\_type enum value matching your sail variant. +将 sail\_visual 脚本添加到帆预制体的最顶层父节点,并选择与你的帆变体匹配的正确 sail\_type 枚举值。 -Main children: +主要子项: -> * pulley\_systems\_holder: Contains all rope visual systems. - * stability\_ropes: Ropes connecting the control bones to the deck (stays and shrouds). Each rope entity's tag must match the name of the bone it connects to. - * static\_ropes\_parent: Static decorative ropes. Tag attached\_to\_yard for ropes that connect to the yard; tag big\_rope for ropes that connect from the yard down to the hull. - * sail\_fold\_pulley\_parent: Ropes that gather the sail when furling. Tag each rope's entity with the name of the bone it is controlled by. - * sail\_rotate\_pulley\_parent: Ropes responsible for rotating the yard to catch the wind angle. -> * force\_center\_entity: Must have the tag force\_center\_entity. Defines the point at which wind force is applied to the sail for physics calculations. Position this at the center of the sail's surface area. -> * sail\_mast: Place all mast visual mesh entities under this child. -> * yaw\_rotation\_entity: Must have the tag yaw\_rotation\_entity. Place your prepared sail and yard assets under this entity. This entity rotates to simulate the yard turning to face the wind. -> * sail\_upgrade\_slot: The upgrade slot entity for sail-level upgrades. +> * 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. Upgrade & Gameplay Components** +### **2.2. 升级与玩法组件** -These components extend the ship's capabilities, define its combat capacity, or change appearance and stats based on the ship's upgrade level. They are optional in the sense that the ship will exist and float without them, but no naval gameplay (sailing, combat, upgrades) will function correctly without them. +这些组件扩展了船只的能力,定义了其战斗容量,或根据船只的升级等级改变外观和属性。从某种意义上说它们是可选的——没有它们船只仍能存在并漂浮,但没有它们任何海战玩法(航行、战斗、升级)都无法正常运作。 -The upgrade system is driven by several XML files that you must edit to register your ship and its upgrade pieces with the game: +升级系统由若干个 XML 文件驱动,你必须编辑这些文件才能将你的船只及其升级部件注册到游戏中: -> * ship\_slots.xml: Defines all upgrade slot types available for ships. Every upgrade piece type your ship uses must have a corresponding entry here. The IDs defined in this file are referenced by the other XMLs below. -> * ship\_upgrade\_pieces.xml: Defines the individual upgrade pieces — their stats, visual effects, descriptions, and which slot ID they belong to. -> * mission\_ships.xml: Registers your ship as a usable ship in missions. Contains the ship's ID, prefab name, mass, and other mission-level properties. -> * ship\_hulls.xml: Defines the ship's mission statistics (health, speed, maneuverability, etc.) and specifies which upgrade slots are available on this hull type. +> * ship\_slots.xml: 定义船只可用的所有升级槽类型。你的船只使用的每种升级部件类型都必须在此有对应的条目。该文件中定义的 ID 会被下面的其他 XML 引用。 +> * ship\_upgrade\_pieces.xml: 定义各个升级部件——它们的属性、视觉效果、描述,以及它们所属的槽位 ID。 +> * mission\_ships.xml: 将你的船只注册为任务中可用的船只。包含船只的 ID、预制体名称、质量和其他任务级属性。 +> * ship\_hulls.xml: 定义船只的任务统计数据(生命值、速度、机动性等),并指定该船体类型上可用的升级槽。 #### **2.2.1. hull\_group** -This nested prefab controls the visual appearance of the ship's hull at different upgrade levels. +该嵌套预制体控制船只在不同升级等级下船体的视觉外观。 -> * **Placement:** Add the hull\_group nested prefab to the ship's root entity at Identity (0,0,0). -> * **Structure:** The prefab contains 5 child entities, each corresponding to a different hull material or upgrade level. -> * **Setup:** Add your prepared hull mesh as a MetaMesh to the child entity that corresponds to the correct material name. -> * **Tags:** The necessary tags for the upgrade system to recognize hull states are predefined on the prefab's children. If you are creating a new hull type, you can duplicate existing hull upgrade tags from the XMLs or remove ones that are not relevant to your ship. +> * **放置:** 将 hull\_group 嵌套预制体添加到船只根实体的恒等位置(0,0,0)。 +> * **结构:** 该预制体包含 5 个子实体,分别对应不同的船体材质或升级等级。 +> * **设置:** 将你准备好的船体网格作为 MetaMesh 添加到对应正确材质名称的子实体中。 +> * **标签:** 升级系统识别船体状态所需的标签已预定义在预制体的子项上。如果你正在创建一种新的船体类型,可以从 XML 中复制现有的船体升级标签,或移除与你的船只无关的标签。 #### **2.2.2. shields\_group** -This nested prefab adds shield decorations along the ship's railings, which also serve to protect troops on deck from incoming ranged attacks. +该嵌套预制体沿船只的栏杆添加盾牌装饰,这些装饰同时也能保护甲板上的部队免受来袭远程攻击。 -> * **Placement:** Add the shields\_holder nested prefab at the ship's root Identity (0,0,0). -> * **Customization:** The number of shields displayed can be increased or decreased by editing the relevant ship XML, or by changing the MetaMeshes on the child entities. -> * **Faction Colors (Crucial):** Every shield child entity has the banner\_with\_faction\_color tag. This tag is what causes the game to apply the owning faction's sigil and colors to the shields at runtime. - * **Important:** You must also assign the banner\_with\_faction\_color tag to the MetaMesh asset itself and to all of its LOD variants in the Resource Browser. If the tag is on the entity but not the mesh asset, the faction colors will not appear. +> * **放置:** 将 shields\_holder 嵌套预制体添加到船只根实体的恒等位置(0,0,0)。 +> * **自定义:** 可以通过编辑相关的船只 XML,或更改子实体上的 MetaMesh,来增加或减少显示的盾牌数量。 +> * **阵营颜色(至关重要):** 每个盾牌子实体都带有 banner\_with\_faction\_color 标签。正是这个标签使得游戏在运行时将所属阵营的徽记和颜色应用到盾牌上。 + * **重要:** 你还必须在资源浏览器(Resource Browser)中将 banner\_with\_faction\_color 标签分配给 MetaMesh 资产本身以及其所有 LOD 变体。如果标签只在实体上而不在网格资产上,阵营颜色将不会显示。 #### **2.2.3. cam\_holder\_nested** -This prefab ensures that ship upgrade pieces are displayed correctly in the City Port UI, where players purchase and preview upgrades. +该预制体确保船只升级部件在玩家购买和预览升级的城市港口 UI 中正确显示。 -> * **Placement:** Add the cam\_holder\_nested prefab at the ship's Identity. Best practice is to add this after all upgrade pieces have been placed, so the camera can be positioned to see the complete ship. -> * **Setup:** The holder contains one child entity for every upgrade piece type, associated via tags that the UI system reads. Move each child entity to position it over its corresponding upgrade piece on the ship. -> * **Camera Instance:** Move the Camera\_Instance child to a position that gives a wide, clear view of the entire ship from a flattering angle. - * *Tip:* Set your editor viewport to the desired camera angle, then right-click Camera\_Instance and select **Assign Frame From Camera**. Fine adjustments (field of view, near/far clip) can be made via the script on the camera instance child. +> * **放置:** 将 cam\_holder\_nested 预制体添加到船只的恒等位置。最佳实践是在放置完所有升级部件之后再添加此预制体,这样摄像机就能被定位到看到完整船只的位置。 +> * **设置:** 该容器为每种升级部件类型包含一个子实体,通过 UI 系统读取的标签进行关联。移动每个子实体以将其定位在船上对应的升级部件之上。 +> * **摄像机实例:** 将 Camera\_Instance 子项移动到一个能够以讨喜的角度宽广、清晰地展示整艘船的位置。 + * *提示:* 将你的编辑器视口设置为所需的摄像机角度,然后右键单击 Camera\_Instance 并选择 **Assign Frame From Camera(从摄像机分配帧)**。可以通过摄像机实例子项上的脚本进行微调(视野、远近裁剪面)。 #### **2.2.4. roof\_group** -This prefab adds a roof structure over the aftercastle — the raised rear portion of the ship — and any forward castle if the ship design requires it. +该预制体在后甲板楼(aftercastle,船只抬高的后部)以及船只设计需要的话前甲板楼之上添加屋顶结构。 -> * **Placement:** Add the roof\_group prefab at the ship's root Identity (0,0,0). -> * **Structure:** The prefab contains 15 different roof variants and platform options. Add the platform mesh appropriate for your ship as a MetaMesh to the platform child entity, then position the roof variants to fit your geometry. +> * **放置:** 将 roof\_group 预制体添加到船只根实体的恒等位置(0,0,0)。 +> * **结构:** 该预制体包含 15 种不同的屋顶变体和平台选项。将适合你船只的平台网格作为 MetaMesh 添加到平台子实体,然后定位屋顶变体以适应你的几何形状。 -**Coloring & Tags:** +**着色与标签:** -> * Cloth elements (canvas roofing, awnings): Assign the sail\_mesh\_entity tag. This causes the cloth to be tinted to match the faction's sail color. -> * Wooden structural elements: Assign the auto\_factor\_color tag to the relevant wood material in the Resource Browser. This causes the wood to match the hull color defined in ShipColorAssigner on the root entity. -> * Other cloth elements: Assign the faction\_color tag in the Resource Browser (apply to all LODs). This applies a general faction color tint. +> * 布料元素(帆布屋顶、遮阳篷): 分配 sail\_mesh\_entity 标签。这会使布料被染成与阵营帆色相匹配的颜色。 +> * 木质结构元素: 在资源浏览器中为相关木材材质分配 auto\_factor\_color 标签。这会使木材的颜色与根实体上 ShipColorAssigner 中定义的船体颜色相匹配。 +> * 其他布料元素: 在资源浏览器中分配 faction\_color 标签(应用于所有 LOD)。这会施加一种通用的阵营颜色色调。 #### **2.2.5. figurehead\_group** -The figurehead is the decorative carved element at the bow of the ship. In gameplay terms it also provides stat bonuses (increased ram damage, morale bonuses, etc.), making it both a cosmetic and an upgrade piece. +船首像(figurehead)是船首处雕刻的装饰元素。在玩法方面,它还提供属性加成(增加撞击伤害、士气加成等),使其既是装饰品又是升级部件。 -> * **Placement:** Add the figurehead\_group prefab at the ship's Identity coordinates. -> * **Structure:** The prefab contains 17 default figurehead variants, plus a base and a platform child for the ship's default (no upgrade) state. Assign the appropriate mesh as a MetaMesh to the base and platform children if you want a default figurehead visible before any upgrades are applied. -> * **Adding New Types:** New figurehead variants must be added as children to the main prefab, and their stats and descriptions must be registered in ship\_upgrade\_pieces.xml and ship\_slots.xml. -> * **Visibility:** Unlike most other upgrade pieces, figureheads are discovered through exploration in the game world rather than purchased at port. However, they still appear in the editor's upgrade preview when using EditorShipUpgradeViewer. +> * **放置:** 将 figurehead\_group 预制体添加到船只的恒等坐标处。 +> * **结构:** 该预制体包含 17 种默认船首像变体,以及用于船只默认(未升级)状态的基座(base)和平台(platform)子项。如果你希望在应用任何升级之前就有默认船首像可见,请将适当的网格作为 MetaMesh 分配给基座和平台子项。 +> * **添加新类型:** 新的船首像变体必须作为子项添加到主预制体中,其属性和描述必须在 ship\_upgrade\_pieces.xml 和 ship\_slots.xml 中注册。 +> * **可见性:** 与大多数其他升级部件不同,船首像是通过在游戏世界中探索发现的,而不是在港口购买的。不过,在使用 EditorShipUpgradeViewer 时,它们仍会出现在编辑器的升级预览中。 #### **2.2.6. battlements\_holder\_aft** -Defensive battle shields mounted on the aftercastle to protect troops on the rear of the ship. Typically used on heavier warships. +安装在后甲板楼上的防御战盾,用于保护船尾部队。通常用于较重型的战舰。 -> * **Setup:** Create an empty entity named battlements\_holder\_aft at Identity under the ship root. -> * Add the battlement\_shield\_group\_aft nested prefab as a child. -> * **Configuration:** Multiple instances can be added. Each instance of the battlement prefab contains different visual states for different upgrade levels and destruction states. Destruction particles can be added as additional children within each instance, following the same structure used in the main ship burning system. +> * **设置:** 在船只根节点下的恒等位置创建一个名为 battlements\_holder\_aft 的空实体。 +> * 添加 battlement\_shield\_group\_aft 嵌套预制体作为子项。 +> * **配置:** 可以添加多个实例。战盾预制体的每个实例都包含针对不同升级等级和损毁状态的不同视觉状态。可以在每个实例中添加额外的子项作为损毁粒子效果,遵循船只主燃烧系统中使用的相同结构。 #### **2.2.7. deck\_upgrade\_holder** -This entity contains the deck\_upgrade\_assets\_nested prefab, which handles interactive and passive assets that appear on the deck at higher upgrade levels. +该实体包含 deck\_upgrade\_assets\_nested 预制体,处理在更高升级等级下出现在甲板上的交互式和被动资产。 -> * **Placement:** Add the deck\_upgrade\_assets\_nested prefab as a child under this holder. Multiple instances can be placed at different locations on the deck. -> * **NavMesh Constraint:** Because these assets have physics bodies, there must not be a NavMesh baked beneath them. Baking NavMesh under physics objects causes AI path-finding errors. +> * **放置:** 将 deck\_upgrade\_assets\_nested 预制体添加为该容器下的子项。可以在甲板上的不同位置放置多个实例。 +> * **NavMesh 约束:** 由于这些资产具有物理体,其下方不能烘焙 NavMesh。在物理对象下方烘焙 NavMesh 会导致 AI 寻路错误。 -**Component Breakdown:** +**组件分解:** -> * **Interactable Assets:** The children named deck\_ammo\_1, deck\_ammo\_2, deck\_ammo\_3, deck\_javelin\_2, and deck\_javelin\_3 are interactive objects. Players and AI agents can interact with these to replenish arrows and throwable weapons during combat. -> * **Passive Assets:** All other children within the prefab are purely visual upgrade decorations with no interaction. +> * **可交互资产:** 名为 deck\_ammo\_1、deck\_ammo\_2、deck\_ammo\_3、deck\_javelin\_2 和 deck\_javelin\_3 的子项是可交互对象。玩家和 AI 代理可以与这些对象交互,在战斗期间补充箭矢和投掷武器。 +> * **被动资产:** 该预制体中的所有其他子项纯粹是没有交互功能的视觉升级装饰。 #### **2.2.8. ship\_ballista\_holder** -A nested prefab that contains the complete ballista upgrade — the weapon itself, all ammo type variants, interaction points for agents, and the deck platform it sits on. +一个包含完整弩炮升级的嵌套预制体——武器本身、所有弹药类型变体、代理交互点以及它所在的甲板平台。 -> * **Placement:** Add this prefab directly under the root entity. -> * **Tags:** Assign both the upgrade\_slot tag and the fore tag to the main holder entity. The upgrade\_slot tag registers it with the upgrade system; the fore tag identifies it as a forward-facing weapon and makes it mutually exclusive with battlements\_holder\_fore (a ship cannot have both a ballista and fore battlements at the same time). +> * **放置:** 将此预制体直接添加到根实体下。 +> * **标签:** 为主容器实体分配 upgrade\_slot 标签和 fore 标签。upgrade\_slot 标签将其注册到升级系统;fore 标签将其标识为前向武器,并使其与 battlements\_holder\_fore 互斥(一艘船不能同时拥有弩炮和前甲板战盾)。 -**Child Breakdown:** +**子项分解:** -> * **ballista\_platform:** A raised deck platform that gives the ballista operator a better field of fire. This platform is only active when the ballista upgrade is equipped. - * **Tag:** Assign the platform tag to this child. - * **NavMesh Constraint:** This platform must not be higher than 1.5 metres above the baked deck NavMesh. The game does not generate a separate elevated NavMesh for this platform, so agents must be able to step onto it from the existing deck NavMesh. If it is too high, agents cannot reach the ballista. -> * **Ammo Type Children:** Each remaining child represents a different ammo type (standard bolts, fire bolts, etc.). All ammo children must be placed at the exact same coordinates — the game swaps between them by toggling visibility based on which ammo type is loaded. Each child must have a unique tag identifying its ammo type. +> * **ballista\_platform:** 一个抬高的甲板平台,为弩炮操作者提供更好的射界。该平台仅在装备弩炮升级时才处于激活状态。 + * **标签:** 为该子项分配 platform 标签。 + * **NavMesh 约束:** 该平台不得高于已烘焙甲板 NavMesh 1.5 米以上。游戏不会为此平台生成单独的抬高 NavMesh,因此代理必须能够从现有甲板 NavMesh 踏上该平台。如果它太高,代理将无法到达弩炮。 +> * **弹药类型子项:** 其余每个子项代表一种不同的弹药类型(标准弩箭、火焰弩箭等)。所有弹药子项必须放置在完全相同的坐标处——游戏通过根据加载的弹药类型切换可见性来在它们之间进行切换。每个子项必须有一个唯一的标签来标识其弹药类型。 #### **2.2.9. battlements\_holder\_fore** -Defensive shields on the forecastle — the raised front section of the ship. +安装在前甲板楼(forecastle,船只抬高的前部)上的防御盾牌。 -> * **Setup:** Create an empty entity named battlements\_holder\_fore at Identity. -> * Add the battlement\_shield\_group\_fore nested prefab as a child. -> * **Mutual Exclusivity:** This component is mutually exclusive with ship\_ballista\_holder. A ship cannot have both fore battlements and a ballista. Ensure the tags on this holder use the fore designation so the upgrade system enforces this exclusivity correctly. +> * **设置:** 在恒等位置创建一个名为 battlements\_holder\_fore 的空实体。 +> * 添加 battlement\_shield\_group\_fore 嵌套预制体作为子项。 +> * **互斥性:** 该组件与 ship\_ballista\_holder 互斥。一艘船不能同时拥有前甲板战盾和弩炮。确保此容器上的标签使用 fore 标识,以便升级系统正确强制执行这种互斥性。 #### **2.2.10. ram\_group** -The ram is the reinforced prow extension used for ramming enemy ships, dealing hull damage on collision. +撞角(ram)是用于撞击敌船、在碰撞时造成船体伤害的加固船首延伸部分。 -> * **Placement:** Add the ram\_group nested prefab at the ship's Identity. -> * **Structure:** The prefab contains 8 predefined ram variants and 1 adapter mesh. Place and orient the 8 ram variants to fit your ship's bow shape, then add the appropriate deck extension or prow platform mesh as a MetaMesh to the adapter entity. -> * **Tags:** All required tags for the upgrade and damage systems are predefined on the ram prefab's children. New ram variants can be added to the prefab and registered in the relevant XML files following the existing patterns. +> * **放置:** 将 ram\_group 嵌套预制体添加到船只的恒等位置。 +> * **结构:** 该预制体包含 8 种预定义的撞角变体和 1 个适配器网格。放置并调整这 8 种撞角变体的朝向以适应你船只的船首形状,然后将适当的甲板延伸或船首平台网格作为 MetaMesh 添加到适配器实体。 +> * **标签:** 升级和伤害系统所需的所有标签都已预定义在撞角预制体的子项上。可以按照现有模式向该预制体添加新的撞角变体,并在相关的 XML 文件中注册。 -### **2.3. Cosmetic & VFX Components** +### **2.3. 装饰与 VFX 组件** -This group contains purely visual elements. Their absence does not break the ship's functionality or gameplay, but they are essential for the ship to look and feel correct in-game. +该组包含纯视觉元素。它们的缺失不会破坏船只的功能或玩法,但对于船只在游戏中看起来和感觉正确至关重要。 #### **2.3.1. wetness\_decals** -*These decals simulate water splash marks on the outer hull, showing wet patches where waves hit the ship's sides.* +*这些贴花模拟外部船体上的水花痕迹,显示波浪拍打船侧时留下的湿润痕迹。* -> * *Setup: Create an empty entity as a direct child of the ship root (not inside mesh\_holder or ship\_water\_effects). Name it wetness\_decals and assign the tag wetness\_decals to it.* -> * *Add child entities under it. Each child must have a Decal component with the desired wetness material assigned.* -> * *Position and orient each decal against the hull surface. The decal's local up axis is used as its surface normal — ensure it points outward away from the hull surface, otherwise the system cannot correctly determine whether a splash particle is near enough to activate the decal.* -> * *Behavior: Decals fade in when active splash particles are nearby on the same side of the hull, then gradually fade out over approximately 6 seconds of inactivity.* +> * *设置:在船只根节点下创建一个空实体作为直接子项(不要放在 mesh\_holder 或 ship\_water\_effects 内部)。将其命名为 wetness\_decals,并为其分配 wetness\_decals 标签。* +> * *在其下添加子实体。每个子项必须拥有一个 Decal(贴花)组件,并分配所需的湿润材质。* +> * *将每个贴花相对于船体表面进行定位和定向。贴花的局部向上轴被用作其表面法线——确保它指向远离船体表面的方向,否则系统无法正确判断水花粒子是否足够靠近以激活该贴花。* +> * *行为:当船体同侧附近有活跃的水花粒子时,贴花会淡入显现,然后在大约 6 秒的非活动状态后逐渐淡出。* #### **2.3.2. rudder\_objects** -Used when you want a visible physical rudder on the ship that rotates in response to the ship's steering, even when the steering is not controlled by a ShipControlRudder (i.e., the rudder is visual only, not interactive). +当你希望在船上有一个可见的物理舵,它能够响应船只转向而旋转,即使该转向并非由 ShipControlRudder 控制时使用(即该舵仅是视觉效果,不具备交互性)。 -> * **Setup:** Add the appropriate rudder mesh as a MetaMesh to a child entity of this holder. -> * **Tag:** Assign the tag rudder\_rotation\_entity to the entity containing the mesh. The game reads this tag to find the visual rudder and synchronize its rotation angle with the ship's current steering input. +> * **设置:** 将适当的舵网格作为 MetaMesh 添加到该容器的子实体。 +> * **标签:** 为包含该网格的实体分配 rudder\_rotation\_entity 标签。游戏会读取此标签来查找视觉舵,并将其旋转角度与船只当前的转向输入同步。 #### **2.3.3. ship\_water\_effects** -ShipWaterEffects (ship\_water\_effects) is a script component that adds all water-related visual effects to the ship. It is purely visual and has no effect on physics or gameplay logic. +ShipWaterEffects(ship\_water\_effects)是一个脚本组件,为船只添加所有与水相关的视觉效果。它纯粹是视觉性的,对物理或玩法逻辑没有影响。 -**Prerequisite:** The ship's buoyancy (floater volumes) must be fully set up before adding this script. ShipWaterEffects reads the floater configuration to determine the waterline position used for particle placement. +**前提条件:** 在添加此脚本之前,船只的浮力(浮子体积)必须已完全设置好。ShipWaterEffects 会读取浮子配置,以确定用于粒子放置的水线位置。 -The script is attached to a **child entity** of the ship root — not the root itself. Create a child entity named ship\_visual\_only and add the ship\_water\_effects script to it. The ship\_visual\_only tag scopes this script to visual-only entities, keeping it separate from physics and gameplay logic. +该脚本附加在船只根节点的**子实体**上——而不是根节点本身。创建一个名为 ship\_visual\_only 的子实体,并将 ship\_water\_effects 脚本添加到其中。ship\_visual\_only 标签将此脚本的范围限定在仅视觉实体内,使其与物理和玩法逻辑分离。 -\[ship\_root\] - └─ \[ship\_visual\_only\] ← ShipWaterEffects script lives here +\[ship\_root\] + └─ \[ship\_visual\_only\] ← ShipWaterEffects 脚本位于此处 -**Overview of Features:** +**功能概览:** -| Feature | Description | +| 功能 | 描述 | | :---- | :---- | -| **Wake** | A trail on the water surface behind the moving ship. Shape and size are derived automatically from the hull mesh. | -| **Movement Particles** | Continuous water spray along both sides of the hull while the ship is underway. | -| **Splash Particles** | Velocity-triggered burst particles at the waterline. Thresholds: small at ≥2 m/s, medium at ≥5 m/s, large at ≥8 m/s. | -| **In-Hull Water Simulation** | A simulated water surface rendered inside the hull interior. Reacts to wave entry events and rain automatically. | -| **Foam Trail Decals** | Foam patches spawned at the bow as the ship moves, which drift and fade over time. Requires a decal renderer in the scene. | -| **Wetness Decals** | Hull decals that become visibly wet near active splash particles and dry out over time. See section 2.3.1 for setup. | -| **Rain Interaction** | The in-hull water surface reacts to scene rain density automatically. | +| **航迹(Wake)** | 移动船只身后水面上留下的尾迹。形状和大小根据船体网格自动推导。 | +| **移动粒子(Movement Particles)** | 船只航行时沿船体两侧持续产生的水花喷溅。 | +| **水花粒子(Splash Particles)** | 在水线处由速度触发的爆发式粒子。阈值:小≥2 m/s,中≥5 m/s,大≥8 m/s。 | +| **船体内部水体模拟(In-Hull Water Simulation)** | 在船体内部渲染的模拟水面。会自动对波浪进入事件和降雨做出反应。 | +| **泡沫尾迹贴花(Foam Trail Decals)** | 船只移动时在船首生成的泡沫斑块,会随时间漂移和淡出。需要场景中有贴花渲染器。 | +| **湿润贴花(Wetness Decals)** | 在活跃水花粒子附近显得明显湿润、并随时间变干的船体贴花。设置方法见 2.3.1 节。 | +| **降雨交互(Rain Interaction)** | 船体内部水面会自动对场景降雨密度做出反应。 | -**Note:** You do not need to manually place any particle entities. All particle positions are computed automatically at startup using raycasts against the body\_mesh entity. Ensure body\_mesh exists and has a valid MetaMesh with an accurate bounding box. If the ship has a ram, the bow particle strip extends automatically to cover the ram tip — no extra setup is needed. +**注意:** 你不需要手动放置任何粒子实体。所有粒子位置都会在启动时通过对 body\_mesh 实体进行射线检测自动计算。确保 body\_mesh 存在,并具有带有准确包围盒的有效 MetaMesh。如果船只带有撞角,船首粒子条带会自动延伸以覆盖撞角尖端——不需要额外设置。 -**Configurable Parameters:** +**可配置参数:** -*In-Hull Water Simulation:* +*船体内部水体模拟:* -> * Water Simulation Bounding Box (default: 1,1,1) — XYZ extents of the bounding volume. Use **Reset Water Simulation Bounding Box** to auto-compute from render\_to\_depth meshes. -> * Hull Water Simulation Resolution Scale (default: half) — Options: one, half, quarter, one\_eight, one\_sixteenth. Lower values improve performance. -> * Hull Water Splash Water Multiplier (default: 1.75) — Scales wave displacement intensity inside the hull on splash events. -> * Ship Hull Height Type (default: Small) — Use Large for tall-sided vessels. Options: Small, Medium, Large. +> * 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 Particles:* +*移动粒子:* -> * Movement Particle Type (default: Small) — Use Small for small boats, Medium or Large for bigger ships. -> * Movement Particle Height Offset (default: 0.34) — Vertical offset in metres from the computed waterline. -> * Movement Particle Surface Distance Offset (default: 0.7) — Distance from the hull surface for particle origins. +> * Movement Particle Type(移动粒子类型,默认: Small)—— 小型船只使用 Small,较大船只使用 Medium 或 Large。 +> * Movement Particle Height Offset(移动粒子高度偏移,默认: 0.34)—— 相对于计算出的水线的垂直偏移量(米)。 +> * Movement Particle Surface Distance Offset(移动粒子表面距离偏移,默认: 0.7)—— 粒子起点距船体表面的距离。 -*Splash Particles:* +*水花粒子:* -> * Splash Particle Height Offset (default: 0.4) — Vertical offset from waterline for splash particle placement. -> * Splash Particle Surface Distance Offset (default: 0.7) — Distance from hull surface for splash particle origins. +> * Splash Particle Height Offset(水花粒子高度偏移,默认: 0.4)—— 水花粒子放置相对于水线的垂直偏移。 +> * Splash Particle Surface Distance Offset(水花粒子表面距离偏移,默认: 0.7)—— 水花粒子起点距船体表面的距离。 -**Editor Debug Tools** *(editor only, no effect in shipped builds):* +**编辑器调试工具**(*仅限编辑器,出货构建中无效果*): -> * **Reset Water Simulation Bounding Box** — Auto-computes bounding box from render\_to\_depth meshes. -> * **Re-render Depth Texture** — Forces the depth texture to re-render after modifying render\_to\_depth meshes. -> * **Reset In-Hull Water** — Resets the hull water simulation to its initial state. -> * **Show Water Simulation Bounding Box** — Draws the bounding box in the viewport. -> * **Show Movement Particles / Show Splash Particles** — Draws debug markers at each particle origin. -> * **Show Water Balance Plane** — Visualizes the computed waterline as a red plane. -> * **Show Wetness Decal Values / Force Wetness Decal To Full** — Tools for inspecting wetness decal placement and opacity. +> * **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(显示湿润贴花数值/强制湿润贴花至最大)** —— 用于检查湿润贴花放置和不透明度的工具。 -**Campaign Map Behavior:** On the campaign map (Main\_map scene), this script automatically disables all particle and simulation logic. No visual overhead is incurred on the campaign map — the entity structure simply needs to be present. +**战役地图行为:** 在战役地图(Main\_map 场景)上,此脚本会自动禁用所有粒子和模拟逻辑。战役地图上不会产生视觉开销——只需要实体结构存在即可。 #### **2.3.4. ship\_burning\_system** -This entity contains all visual and audio content related to the ship's burning mechanics — fire particles, light sources, and sound nodes. The system is designed to spread fire progressively across the ship in a controlled sequence. +该实体包含与船只燃烧机制相关的所有视觉和音频内容——火焰粒子、光源和声音节点。该系统旨在以受控的顺序逐步在船上蔓延火焰。 -**a) Particle Placement Hierarchy:** +**a) 粒子放置层级结构:** -The ship\_burning\_node prefabs are sorted into specific parent entities to define where fire can appear. These parents must exist inside the ship\_burning\_system entity: +ship\_burning\_node 预制体被归类到特定的父实体中,以定义火焰可以出现的位置。这些父节点必须存在于 ship\_burning\_system 实体内部: -> * railing\_parent: Place burning nodes along the railings. -> * ship\_deck\_parent: Place burning nodes at random positions across the open deck. -> * deck\_upgrade\_parent: Place burning nodes on and around deck upgrade assets. -> * mast\_parent: Place burning nodes on the deck in the area beneath each mast. +> * railing\_parent: 沿栏杆放置燃烧节点。 +> * ship\_deck\_parent: 在开放甲板上的随机位置放置燃烧节点。 +> * deck\_upgrade\_parent: 在甲板升级资产上及其周围放置燃烧节点。 +> * mast\_parent: 在每根桅杆下方的甲板区域放置燃烧节点。 -**b) BurningNode Configuration:** +**b) BurningNode 配置:** -Each ship\_burning\_node prefab contains the BurningNode script and a particle system child. +每个 ship\_burning\_node 预制体都包含 BurningNode 脚本和一个粒子系统子项。 -> * **Node Index (Critical):** The Node Index value in the BurningNode script controls the order in which fire spreads. Assign sequential, unique integers (0, 1, 2, 3...) to adjacent nodes along a logical spread path — for example, numbering railing nodes from stern to bow causes fire to visibly travel along the railing in sequence. -> * **Audio Restriction (Important):** Remove all sound file paths from the particle systems used inside burning nodes. The burning system has its own dedicated sound management through sound\_parent. Leaving sounds on individual particles causes multiple overlapping audio sources and a loud, incorrect soundscape. +> * **Node Index(节点索引,关键):** BurningNode 脚本中的 Node Index 值控制火焰蔓延的顺序。为沿逻辑蔓延路径相邻的节点分配连续、唯一的整数(0、1、2、3……)——例如,从船尾到船首对栏杆节点进行编号,会使火焰可见地沿栏杆按顺序蔓延。 +> * **音频限制(重要):** 移除燃烧节点内部所使用粒子系统中的所有声音文件路径。燃烧系统通过 sound\_parent 拥有自己专门的声音管理。如果在单个粒子上保留声音,会导致多个重叠的音频源和响亮、错误的声景。 -**c) Lighting & Sound:** +**c) 灯光与声音:** -> * light\_parent: Contains point light entities. Position these near clusters of burning nodes to create convincing firelight illumination. Lights fade in and out automatically based on fire progress values in the ShipBurningSystem script. -> * sound\_parent: Contains burning\_sound\_node prefabs. Place 2 to 6 of these around the ship depending on its size. These nodes trigger fire sounds only when fire particles in their immediate vicinity are active. +> * light\_parent: 包含点光源实体。将这些灯光放置在燃烧节点集群附近,以营造逼真的火光照明效果。灯光会根据 ShipBurningSystem 脚本中的火焰进度值自动淡入淡出。 +> * sound\_parent: 包含 burning\_sound\_node 预制体。根据船只大小,在船周围放置 2 到 6 个这样的节点。这些节点仅在其附近的火焰粒子处于活跃状态时才会触发燃烧声音。 -**d) ShipBurningSystem Script (Root Settings):** +**d) ShipBurningSystem 脚本(根设置):** -> * **Start Fire / Stop Fire:** Editor buttons to preview the full burning sequence without launching the game. -> * **Spread Rate:** Controls how quickly fire spreads across the ship. Higher values cause faster, more aggressive burning. -> * **All Fire Mode:** Activates all fire particles simultaneously, useful for visually checking node placement. -> * **Small Hit Debug:** With this enabled, aim at the ship and press middle-click to simulate a small localized fire hit. -> * **Min/Max Fire Progress For Light:** Controls the timeline for light activation. - * *Min:* The fire progress value (0–1) at which the point lights begin to fade in. - * *Max:* The fire progress value at which lights reach their peak intensity. -> * **Max Light Intensity:** The maximum brightness value the lights under light\_parent will reach at peak fire intensity. +> * **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** -This holder contains decorative ropes that are tied between points on the ship — rigging lines, mooring ropes, and other atmospheric rope details. +该容器包含在船只各点之间系挂的装饰性绳索——索具线、系泊绳以及其他增添氛围的绳索细节。 -> * **Prefab:** Use simple\_rope\_nested for each rope. Place the start and end child entities of each rope at the desired anchor points on the ship. -> * **Configuration:** Adjust the following via the script on the start child entity: - * fixed size: Whether the rope has a fixed length or sags based on the distance between endpoints. - * loose amount: How much the rope sags between its endpoints (catenary curve depth). - * default length: The rope's natural unstretched length. -> * **Visual Properties:** Rope thickness, length-based texture tiling, and other visual parameters are controlled via the material's **custom mesh parameters** on the rope entity. +> * **预制体:** 对每根绳索使用 simple\_rope\_nested。将每根绳索的起点和终点子实体放置在船上所需的锚定点上。 +> * **配置:** 通过起点子实体上的脚本调整以下内容: + * fixed size(固定长度): 绳索是具有固定长度,还是根据端点之间的距离下垂。 + * loose amount(松弛量): 绳索在两端点之间下垂的程度(悬链线曲线深度)。 + * default length(默认长度): 绳索自然未拉伸时的长度。 +> * **视觉属性:** 绳索粗细、基于长度的纹理平铺以及其他视觉参数,通过绳索实体上材质的**自定义网格参数(custom mesh parameters)**进行控制。 #### **2.3.6. brazier\_holder** -Braziers provide the lit coal pots from which archers can ignite fire arrows. This component works interchangeably — or mutually exclusively, depending on ship design — with some shield upgrade configurations. +火盆(Braziers)提供了燃烧的煤炭盆,弓箭手可以用它点燃火箭。根据船只设计,该组件与某些盾牌升级配置可以互换使用——或互斥使用。 -> * **Placement:** Place brazier\_b or brazier\_d prefabs as children under this holder at suitable positions along the ship's edges or deck. Tags are predefined on the prefab — no additional tag setup is required. -> * Multiple braziers can be placed, and their positions should be accessible to standing agents without requiring them to move far from their combat positions. +> * **放置:** 将 brazier\_b 或 brazier\_d 预制体作为子项放置在此容器下,位于船只边缘或甲板上合适的位置。标签已在预制体上预定义——无需额外的标签设置。 +> * 可以放置多个火盆,它们的位置应便于站立的代理使用,而无需离开其战斗位置太远。 -#### **2.3.7. ship\_water\_clip (SDF System)** +#### **2.3.7. ship\_water\_clip(SDF 系统)** -The SDF (Signed Distance Field) system prevents ocean water from visually appearing inside the ship's hull — without it, the sea surface would clip through the hull geometry, which looks incorrect. +SDF(带符号距离场,Signed Distance Field)系统防止海水在视觉上出现在船体内部——如果没有它,海面会穿透船体几何体,看起来会不正确。 -> * **Model Preparation:** Create a custom 3D mesh that closely follows the outer shape of the ship's hull below the deck line, extending slightly above deck level to create a sealed volume. This mesh defines the "dry" interior zone. -> * **Naming Convention:** The mesh name must begin with the prefix sdf\_ (e.g., sdf\_dromon). The engine automatically processes any mesh with this prefix as SDF data when it is imported. +> * **模型准备:** 创建一个自定义 3D 网格,紧密贴合甲板线以下船体的外部形状,并略微延伸至甲板水平线以上,以形成一个密封的体积。此网格定义了"干燥"的内部区域。 +> * **命名约定:** 网格名称必须以前缀 sdf\_ 开头(例如 sdf\_dromon)。引擎在导入时会自动将带有此前缀的任何网格处理为 SDF 数据。 -**Setup:** +**设置:** -> 1. Add the ship\_water\_clip prefab to the ship hierarchy. -> 2. Find the signed\_distance\_field script inside this prefab. -> 3. Assign your prepared SDF mesh asset to the script. +> 1. 将 ship\_water\_clip 预制体添加到船只层级结构中。 +> 2. 在此预制体内找到 signed\_distance\_field 脚本。 +> 3. 将你准备好的 SDF 网格资产分配给该脚本。 -**Verification:** Enable the **Visualize SDF** checkbox in the script to see the field rendered in the editor viewport as a colored volume. Verify that the volume completely encloses the hull interior below deck. +**验证:** 在脚本中启用 **Visualize SDF(可视化 SDF)** 复选框,以在编辑器视口中将场渲染为彩色体积。验证该体积完全包围了甲板以下的船体内部。 -#### **2.3.8. deckwater (Heightmap Simulation)** +#### **2.3.8. deckwater(高度图模拟)** -This system simulates water pooling and sloshing on the ship's deck — the visible water that accumulates from waves washing over the sides. +该系统模拟船只甲板上的积水和晃动的水——即波浪冲过船舷时积聚的可见水体。 -> * **Asset:** A simplified "fake deck" mesh is required. This mesh is used to generate the top-down depth texture (heightmap) that the simulation reads. -> * **Setup:** - 1. Add this fake deck mesh as a child entity under mesh\_holder. - 2. Assign the render\_to\_depth tag to this entity. The water effects system will include it (along with all other render\_to\_depth tagged objects such as oar\_seats and deck furniture) in the depth render. - 3. After setup, navigate to the ship\_water\_effects child entity and click **Re-render Depth Texture** in the ShipWaterEffects script to bake the depth texture. -> * **Debug:** Increase the **Water Strength** value in the Scene Options window and enable **Enable Physics** in the Visibility window to observe the deck water simulation behavior in the editor. +> * **资产:** 需要一个简化的"假甲板"网格。该网格用于生成模拟所读取的俯视深度纹理(高度图)。 +> * **设置:** + 1. 在 mesh\_holder 下添加该假甲板网格作为子实体。 + 2. 为该实体分配 render\_to\_depth 标签。水效果系统会将其(连同所有其他带有 render\_to\_depth 标签的对象,如 oar\_seats 和甲板家具)包含在深度渲染中。 + 3. 设置完成后,导航到 ship\_water\_effects 子实体,并在 ShipWaterEffects 脚本中点击 **Re-render Depth Texture(重新渲染深度纹理)** 来烘焙深度纹理。 +> * **调试:** 在场景选项(Scene Options)窗口中增大 **Water Strength(水体强度)** 值,并在可见性(Visibility)窗口中启用 **Enable Physics(启用物理)**,以便在编辑器中观察甲板积水模拟行为。 #### **2.3.9. torch\_holder** -This holder contains lanterns and torches that provide ambient lighting on the ship at night and in dark scenes. +该容器包含灯笼和火炬,为船只在夜晚和黑暗场景中提供环境照明。 -> * **Prefab:** Add nord\_lantern\_nested as a child for each light source position. -> * Each lantern prefab contains: - * collision\_sphere: A small physics sphere used for collision interactions (e.g., agents brushing past the lantern). - * swinging\_object: The part of the lantern that physically swings in response to ship movement. Assign the tag swinging\_entity to this child. This child contains both the light source entity and the lantern mesh that visually sways. - * nord\_lantern\_part\_02: The static mounting bracket or chain that does not swing. This part stays fixed relative to the ship. +> * **预制体:** 为每个光源位置添加 nord\_lantern\_nested 作为子项。 +> * 每个灯笼预制体包含: + * collision\_sphere: 一个用于碰撞交互的小型物理球体(例如代理擦过灯笼)。 + * swinging\_object: 灯笼中随船只运动而物理摆动的部分。为该子项分配 swinging\_entity 标签。该子项包含光源实体和在视觉上摆动的灯笼网格。 + * nord\_lantern\_part\_02: 不摆动的静态安装支架或链条。该部分相对于船只保持固定。 #### **2.3.10. knobs\_holder** -This holder contains the deck-level anchor points where ropes from the sails tie off. They are the cleats, bollards, and belaying pin racks that sailors use to secure running rigging. +该容器包含帆上绳索系挂的甲板级锚点。它们是水手用来固定索具绳索的系缆桩、系柱和系索栓架。 -> * **Parent Tag:** Assign the tag knob\_points\_parent to the knobs\_holder entity itself. The sail system uses this tag to locate all available rope anchor points on the ship. +> * **父标签:** 为 knobs\_holder 实体本身分配 knob\_points\_parent 标签。帆系统使用此标签来定位船上所有可用的绳索锚点。 -**Available prefabs:** +**可用预制体:** -> * bollard\_a -> * cleat\_a -> * belaying\_pins\_a -> * belaying\_pins\_b -> * **Setup:** Inside each prefab are child entities that serve as the precise rope endpoint anchors. Assign the tag knot\_point to each of these child entities. You can duplicate and place as many anchor prefabs as your rigging design requires. The sail system will automatically use the nearest knot\_point to route rope visuals from each sail's control bone. \ No newline at end of file +> * bollard\_a +> * cleat\_a +> * belaying\_pins\_a +> * belaying\_pins\_b +> * **设置:** 每个预制体内部都有作为精确绳索端点锚定的子实体。为这些子实体中的每一个分配 knot\_point 标签。你可以根据索具设计的需要复制并放置任意数量的锚点预制体。帆系统会自动使用最近的 knot\_point 来从每个帆的控制骨布线绳索视觉效果。 diff --git a/docs/content/schinese/War Sails/what_makes_seaborne_village_raid_scene.md b/docs/content/schinese/War Sails/what_makes_seaborne_village_raid_scene.md index 36f11adf..9d0e11a5 100644 --- a/docs/content/schinese/War Sails/what_makes_seaborne_village_raid_scene.md +++ b/docs/content/schinese/War Sails/what_makes_seaborne_village_raid_scene.md @@ -1,41 +1,42 @@ +++ -title = "What Makes a Seaborne Raid Scene" +title = "海上突袭场景的构成要素" description = "" weight = 20 +ai_translated = true +++ -### **Navigation Mesh** +### **导航网格(Navigation Mesh)** -* Works similarly to village scenes. -* In scenes created using two separate levels, for the `land_raid` **Level** (check ["What Makes a Village Scene"](https://moddocs.bannerlord.com/authoring-mission-scenes/villages/) documentation), all **NavMesh** on land must have **ID 0** in the `naval_raid` **Level**. -* **Agents** can walk in water up to a height of 1.40 meters. Therefore, **NavMesh** with **ID 0** should be baked up to a depth of 1.40m; if the water is deeper, **Agents** will swim. +* 工作方式与村庄场景类似。 +* 在使用两个独立关卡(Level)创建的场景中,对于`land_raid`**关卡**(请查看["村庄场景的构成要素"](https://moddocs.bannerlord.com/authoring-mission-scenes/villages/)文档),`naval_raid`**关卡**中陆地上的所有**导航网格**必须具有**ID 0**。 +* **智能体(Agent)**可以在水深达1.40米的水中行走。因此,**ID 0**的**导航网格**应烘焙至1.40米深;如果水更深,**智能体**将会游泳。 --- -### **Spawn Points** - -* All **Spawn Points** must be positioned inside the **Soft Borders**. -* All **Spawn Points** must be placed on top of the **NavMesh**. -* **Battle Spawn Points**: - * All defender **Spawn Points** must be located within the **Defender Boundaries**. - * **Prefab**: `naval_battle_set` - * Place the defender parts of the set on land and the attacker parts in the sea/river. - * Attacker **Spawn Points** should not be too close to the shore. - * Ensure all defender **Spawn Points** have empty space around them for troops to spawn properly. - * Move defender reinforcement **Spawn Points** out of sight as much as possible without being too far from the front lines. - * Since a raid can be performed with 3 ships, you can position attacker infantry, archer, and cavalry **Spawn Points** facing the direction they will travel in the water. - * The distance between attacker **Spawn Points** should be adjusted according to ship dimensions. - * If a river scene is being prepared, it must be wide enough for large ships to move freely. +### **出生点(Spawn Points)** + +* 所有**出生点**必须位于**软边界(Soft Borders)**内。 +* 所有**出生点**必须放置在**导航网格**之上。 +* **战斗出生点**: + * 所有防守方**出生点**必须位于**防守方边界(Defender Boundaries)**内。 + * **预制体(Prefab)**:`naval_battle_set` + * 将该预制体中防守方的部分放置在陆地上,进攻方的部分放置在海/河中。 + * 进攻方**出生点**不应离海岸太近。 + * 确保所有防守方**出生点**周围有足够的空地,以便部队能够正常出生。 + * 尽可能将防守方的增援**出生点**移出视线范围,但不要离前线太远。 + * 由于突袭可以使用3艘船进行,你可以将进攻方步兵、弓箭手和骑兵的**出生点**朝向他们在水中将要行进的方向。 + * 进攻方**出生点**之间的距离应根据船只尺寸进行调整。 + * 如果正在准备河流场景,必须保证河流足够宽,以便大型船只能够自由移动。 --- -### **Tactical Positions** +### **战术位置(Tactical Positions)** -* **Prefab**: `tactical_position` -* Use the `chokepoint` **Tactical Position** type within the **Script**, adjusting its size for where you want infantry to position and defend. -* Use the `cliff` **Tactical Position** for the general placement of archers. This position determines the general location of archers, from which they distribute to `strategic_archer_point` entities and return to when retreating. -* The `cliff` **Tactical Position** **Prefab** should be used as a child of the `chokepoint` **Tactical Position** **Prefab**. -* **AI** will position themselves according to the rotation of the **Prefab** and the width defined in the **Script**. +* **预制体**:`tactical_position` +* 在**脚本(Script)**中使用`chokepoint`**战术位置**类型,并根据你希望步兵驻守和防御的区域调整其大小。 +* 使用`cliff`**战术位置**作为弓箭手的大致放置位置。此位置决定了弓箭手的总体所在地,他们会从这里分散到各个`strategic_archer_point`实体,并在撤退时返回此处。 +* `cliff`**战术位置****预制体**应作为`chokepoint`**战术位置****预制体**的子对象使用。 +* **AI**会根据**预制体**的旋转方向以及**脚本**中定义的宽度来确定自己的位置。 @@ -43,89 +44,89 @@ weight = 20 --- -### **Tactical & Strategic Archer Positions** +### **战术与战略弓箭手位置** -* **Prefab**: `strategic_archer_position` -* Defines the location where a single archer will go. Many can be added to the scene; all defender archers in battle will distribute among these positions. -* To reposition archers who are placed far from the main battlefield to harass incoming ships early on, you have two tactical options to bring them back into the main fight: -* **Option A (`unsafe_archer_point`):** If you give these entities the `unsafe_archer_point` **Tag**, once the ships complete their landing, these archers will automatically fall back toward the main battlefield (`cliff` **Tactical Position**) to rejoin the active defense. -* **Option B (`volume_box_archer_point`):** If you want more precise control, you can use the `volume_box_archer_point` **Tag** (applied to both the archer positions and a corresponding `volume_box`). This ensures that the archers will hold their positions and only fall back to the `cliff` **Tactical Position** when the enemy actually penetrates your designated **Volume Box** area. +* **预制体**:`strategic_archer_position` +* 定义单个弓箭手将前往的位置。场景中可以添加多个这样的实体;所有参战的防守方弓箭手将分布在这些位置之间。 +* 要将远离主战场、被用于早期骚扰来犯船只的弓箭手重新调回战场,你有两种战术选择: +* **选项A(`unsafe_archer_point`):** 如果你给这些实体赋予`unsafe_archer_point`**标签(Tag)**,一旦船只完成登陆,这些弓箭手将自动后撤到主战场(`cliff`**战术位置**)以重新加入积极防御。 +* **选项B(`volume_box_archer_point`):** 如果你想要更精确的控制,可以使用`volume_box_archer_point`**标签**(同时应用于弓箭手位置和对应的`volume_box`)。这样可以确保弓箭手会坚守自己的位置,只有当敌人真正突破了你所指定的**体积区域(Volume Box)**时才会后撤到`cliff`**战术位置**。 -**Volume Box Trigger Point**: +**体积区域触发点(Volume Box Trigger Point)**: -* **Prefab**: `volume_box` -* **Tag**: `volume_box_archer_point` -* This setup acts as a spatial trigger for archer maneuvers. Unlike the `unsafe_archer_point` which triggers upon landing, this allows for precise control based on attacker progression. -* **Setup Rule**: The `volume_box_archer_point` Tag must be assigned to both the `volume_box` entity itself and all `strategic_archer_point` entities that you want to be triggered by this specific box. -* **Behavior**: When any attacker enters the tagged `volume_box`, all archers stationed at the matching tagged `strategic_archer_point` entities will immediately begin their retreat toward the `cliff` **Tactical Position**. +* **预制体**:`volume_box` +* **标签**:`volume_box_archer_point` +* 此设置作为弓箭手调动的空间触发器。与登陆时触发的`unsafe_archer_point`不同,这允许根据进攻方的推进情况进行精确控制。 +* **设置规则**:`volume_box_archer_point`标签必须同时分配给`volume_box`实体本身以及所有你希望被该特定区域触发的`strategic_archer_point`实体。 +* **行为**:当任何进攻方进入被标记的`volume_box`时,驻守在匹配标记的`strategic_archer_point`实体处的所有弓箭手将立即开始向`cliff`**战术位置**撤退。 --- -### **Player View Point (for Defender)** +### **玩家视角点(用于防守方)** -* Use the `arrow_new_icon` **Prefab** and assign the `player_spawn_frame` **Tag** to it. -* The player will **Spawn** facing the direction of the arrow. -* **Note**: The rotation and direction of the arrow are critical, as they directly determine the player's initial field of view upon spawning. +* 使用`arrow_new_icon`**预制体**并为其分配`player_spawn_frame`**标签**。 +* 玩家将面向箭头所指方向**出生**。 +* **注意**:箭头的旋转方向和朝向至关重要,因为它们直接决定了玩家出生时的初始视野。 --- -### **Landing Points** +### **登陆点(Landing Points)** -* 3 empty entities must be placed on the shore using the correct **Tags** for 3 ships to land: - * Attacker infantry ship landing **Tag**: `landing_001_0` - * Attacker archer ship landing **Tag**: `landing_002_0` - * Attacker cavalry ship landing **Tag**: `landing_003_0` -* Ensure there is enough distance between the landing points of the ships on the shore. -* For the route you want ships to follow in the water, you can give similar **Tags** to empty entities placed in the water. - * Example: For the infantry ship, from near to far: `landing_001_1`, `landing_001_2`, `landing_001_3`. In this case, the attacker infantry **Spawn Point** inside the `naval_battle_set` will target `landing_001_3` first, then the others in sequence to reach `landing_001_0`. -* The rotation of all entities must face the next target landing entity. -* The rotation of the final destination `landing_00x_0` must be positioned to ensure the ship docks correctly at the shore. +* 必须在海岸上使用正确的**标签**放置3个空实体,以供3艘船登陆: + * 进攻方步兵船登陆**标签**:`landing_001_0` + * 进攻方弓箭手船登陆**标签**:`landing_002_0` + * 进攻方骑兵船登陆**标签**:`landing_003_0` +* 确保海岸上各船只登陆点之间有足够的距离。 +* 对于你希望船只在水中遵循的航线,你可以为放置在水中的空实体赋予类似的**标签**。 + * 例如:对于步兵船,从近到远依次为:`landing_001_1`、`landing_001_2`、`landing_001_3`。在这种情况下,`naval_battle_set`中的进攻方步兵**出生点**将首先以`landing_001_3`为目标,然后依次以其他点为目标,最终到达`landing_001_0`。 +* 所有实体的朝向都必须面向下一个目标登陆实体。 +* 最终目的地`landing_00x_0`的朝向必须设置正确,以确保船只能在海岸正确靠岸。 --- -### **Jumping Points** +### **跳跃点(Jumping Points)** -* Used to indicate which direction **Agents** jumping from the ship to the shore should move. -* Use empty entities with **Tags** `jumping_001`, `jumping_002`, `jumping_003` for each ship, and they must be a child of their associated final landing point. - * Example: The entity with the `jumping_001` **Tag** must always be a child of the `landing_001_0` entity. -* The rotation should be adjusted to ensure **Agents** use the most logical **Mechanics** to leave the ship. +* 用于指示从船上跳到岸上的**智能体**应朝哪个方向移动。 +* 为每艘船使用带有**标签**`jumping_001`、`jumping_002`、`jumping_003`的空实体,并且它们必须是其对应的最终登陆点的子对象。 + * 例如:带有`jumping_001`**标签**的实体必须始终是`landing_001_0`实体的子对象。 +* 应调整旋转方向,以确保**智能体**使用最合理的**机制(Mechanics)**离开船只。 --- -### **Flee Positions** +### **逃跑位置(Flee Positions)** -* Positions to which fleeing troops and horses will run. -* Ensure they are inside the **Soft Border** and have **NavMesh** below them. +* 逃跑中的部队和马匹将奔向的位置。 +* 确保它们位于**软边界**内,并且下方有**导航网格**。 --- -### **Soft Border** +### **软边界(Soft Border)** -* **Prefab**: `border_soft` -* These entities define the red boundaries of the scene. -* When placed, they form a polygon by connecting the two closest border entities. -* To visualize the current boundaries, navigate to `Visibility Window` \-\> `Visibility Masks` and enable `Borders`. -* **Design Note**: Ensure the layout of these borders prevents players from abusing the map limits or finding unintended escape routes. +* **预制体**:`border_soft` +* 这些实体定义了场景的红色边界。 +* 放置后,它们会通过连接两个最近的边界实体形成一个多边形。 +* 要查看当前边界,请导航至`Visibility Window`(可见性窗口)\-\>`Visibility Masks`(可见性遮罩),并启用`Borders`(边界)。 +* **设计说明**:确保这些边界的布局能够防止玩家滥用地图边界或找到意外的逃脱路线。 --- -### **Sounds & Atmosphere** +### **声音与氛围** -* Works similarly to village scenes. -* Ensure environmental sounds reflect the naval nature of the raid. -* **Atmosphere** must look consistent across all seasons and times of day. +* 工作方式与村庄场景类似。 +* 确保环境音效能反映出海战的特性。 +* **氛围**在所有季节和时间段内看起来都必须保持一致。 --- -### **Gameplay Design Hints** +### **游戏玩法设计提示** -* Having ships under fire before docking increases the epic battle feel. You can place archers further out to shoot at ships early on. To ensure these archers rejoin the frontline defense rather than getting left behind, you can use the `unsafe_archer_point` **Tag** to trigger their fallback to the `cliff` **Tactical Position** upon ship landing, or utilize the `volume_box_archer_point` setup to trigger their relocation exactly when the enemy reaches a specific zone in your scene. -* Using physical **Chokepoints** in the scene will increase the difficulty for the attacker. -* Make sure the scene works well at night. -* To maintain the "village raid" atmosphere, ensure the battle does not start or end too far from the village area. \ No newline at end of file +* 在船只靠岸之前让它们遭受炮火攻击会增强史诗般的战斗感。你可以将弓箭手放置在更远的地方,以便在早期射击船只。为确保这些弓箭手能重新加入前线防御而不是被落下,你可以使用`unsafe_archer_point`**标签**,在船只登陆时触发它们后撤至`cliff`**战术位置**,或者利用`volume_box_archer_point`设置,在敌人到达场景中特定区域时精确触发它们的转移。 +* 在场景中使用实体的**瓶颈区域(Chokepoints)**将增加进攻方的难度。 +* 确保场景在夜间也能良好运行。 +* 为了保持"村庄突袭"的氛围,确保战斗不会在离村庄区域太远的地方开始或结束。 diff --git a/docs/content/schinese/War Sails/wsworldmap.md b/docs/content/schinese/War Sails/wsworldmap.md index 6b006bae..90df7757 100644 --- a/docs/content/schinese/War Sails/wsworldmap.md +++ b/docs/content/schinese/War Sails/wsworldmap.md @@ -1,14 +1,15 @@ +++ -title = "War Sails World Map" +title = "War Sails 世界地图" description = "" weight = 10 +ai_translated = true +++ -Creating or modifying the War Sails world map involves a few additional requirements compared to Bannerlord. They are listed below. +与 Bannerlord 相比,创建或修改 War Sails 世界地图涉及一些额外的要求。以下列出了这些要求。 -## Navmesh +## 导航网格(Navmesh) -With the War Sails DLC, many bodies of water become navigable, introducing several new navmesh types beyond those used in the base game. When creating or modifying a War Sails world map, you may need to use the following navmesh types: +随着 War Sails DLC 的推出,许多水域变得可通航,引入了几种超出基础游戏所使用的新导航网格(navmesh)类型。在创建或修改 War Sails 世界地图时,你可能需要使用以下导航网格类型: * `CoastalSea` * `OpenSea` @@ -17,59 +18,59 @@ With the War Sails DLC, many bodies of water become navigable, introducing sever * `UnderBridge` * `Lake` -The corresponding navmesh ID values are shown in the image below. +下图显示了对应的导航网格 ID 值。 -`CoastalSea` and `OpenSea` are both navigable water types, but they serve different gameplay purposes. They use different movement speed modifiers and are treated differently by the sea attrition system, so choose the appropriate type based on the intended gameplay. +`CoastalSea` 和 `OpenSea` 都是可通航的水域类型,但它们服务于不同的游戏玩法目的。它们使用不同的移动速度修正系数,并且在海上消耗(sea attrition)系统中受到不同的对待,因此请根据预期的游戏玩法选择合适的类型。 -Use the `UnderBridge` navmesh type for the faces directly beneath bridges, as well as the adjacent faces leading into and out of the bridge. This navmesh type does not affect movement speed or sea attrition. Instead, it controls bridge-specific behavior: +对于桥梁正下方的面,以及通向桥梁出入口的相邻面,请使用 `UnderBridge` 导航网格类型。此导航网格类型不会影响移动速度或海上消耗。相反,它控制着特定于桥梁的行为: -* Ships will automatically fold and unfold their sails when passing underneath the bridge. -* When the player sails under a bridge, the bridge becomes transparent to improve visibility. +* 船只在经过桥下时会自动折叠和展开船帆。 +* 当玩家在桥下航行时,桥梁会变得透明,以提高可见度。 -Lakes are not navigable in War Sails. The `Lake` navmesh type functions as impassable terrain and cannot be traversed by ships. +在 War Sails 中,湖泊是不可通航的。`Lake` 导航网格类型相当于不可通行的地形,船只无法穿越。 -## Flowmap +## 流动图(Flowmap) -In War Sails, wind and water currents affect movement across navigable water. Strength and direction are defined by the Flowmap, which can be edited directly in the World Map Editor. +在 War Sails 中,风和水流会影响可通航水域中的移动。强度和方向由流动图(Flowmap)定义,该图可以在世界地图编辑器(World Map Editor)中直接编辑。 -To edit the Flowmap: +要编辑流动图: -1. Click Paint Flowmap, located between the Paint Flora and Navigation Mesh buttons. -2. Also, open the Inspector and select the Flowmap tab in order to correctly edit it. +1. 点击位于 Paint Flora(绘制植被)和 Navigation Mesh(导航网格)按钮之间的 Paint Flowmap(绘制流动图)按钮。 +2. 同时,打开 Inspector(检查器)并选择 Flowmap(流动图)选项卡,以便正确编辑它。 -The Flowmap is painted much like terrain textures or the heightmap, but each brush stroke also defines a direction. The editor displays colored arrows to visualize the Flowmap: +流动图的绘制方式与地形纹理或高度图非常相似,但每一笔画都会同时定义一个方向。编辑器会显示彩色箭头来可视化流动图: -* The arrow direction indicates the wind and water current direction. -* The arrow color indicates the wind and water current strength. - * Blue represents the weakest wind and water current. - * Red represents the strongest wind and water current. +* 箭头方向表示风和水流的方向。 +* 箭头颜色表示风和水流的强度。 + * 蓝色代表最弱的风和水流。 + * 红色代表最强的风和水流。 -The Flowmap directly influences the water shader. Because of this, painting neighboring areas with sharply opposing flow directions can cause visible stretching or unrealistic water deformation. If you need adjacent areas with opposite current directions, create a smooth transition between them instead of painting an abrupt change. This produces more natural-looking water while still allowing distinct current patterns. +流动图直接影响水体着色器(water shader)。因此,在相邻区域绘制方向截然相反的流动,可能会导致明显的拉伸或不真实的水体变形。如果你需要相邻区域具有相反的水流方向,应在它们之间创建平滑过渡,而不是绘制突兀的变化。这样可以产生更自然的水体外观,同时仍能保留不同的水流模式。 -## Settlement Setup +## 定居点设置 -War Sails introduces several additional entities for coastal settlements. These entities enable features such as embarking and disembarking, naval blockades, and village landing points. +War Sails 为沿海定居点引入了若干额外实体。这些实体支持诸如上船/下船、海上封锁以及村庄登陆点等功能。 -### Port Points +### 港口点(Port Points) -To allow naval parties to embark and disembark at a coastal town, add a child entity named `town_port` to the settlement. +要允许海军队伍在沿海城镇上船和下船,请向该定居点添加一个名为 `town_port` 的子实体。 -The entity must: +该实体必须: -* Be tagged with `main_map_city_port`. -* Be placed on a navigable naval navmesh, such as `CoastalSea` or `River`. Not placing it correctly will lead to errors. +* 带有 `main_map_city_port` 标签。 +* 放置在可通航的海军导航网格上,例如 `CoastalSea` 或 `River`。未正确放置将导致错误。 -**Settlement XML Configuration** +**定居点 XML 配置** -After adding a `town_port` entity to a coastal town, you must also update the `settlements.xml` file. +在向沿海城镇添加 `town_port` 实体后,你还必须更新 `settlements.xml` 文件。 -In the settlement's Buildings section, add the Shipyard building: +在定居点的 Buildings(建筑)部分中,添加船坞(Shipyard)建筑: ```xml ``` -And for the shipyard scene, you should add the shipyard location in the settlement's Locations section, like this: +对于船坞场景,你应该在定居点的 Locations(地点)部分中添加船坞地点,如下所示: ```xml ``` -### Blockade Points +### 封锁点(Blockade Points) -When a coastal town is under siege, War Sails displays a naval blockade around the settlement. To define the blockade area and ship positions, add the following: +当沿海城镇被围攻时,War Sails 会在定居点周围显示海上封锁。要定义封锁区域和船只位置,请添加以下内容: -* `town_blockade_start` entity with the `Blockade_Arc_Start` tag as a child entity -* `town_blockade_end` entity with the `Blockade_Arc_End` tag as a child entity -* `BlockadePositionScript` to the town entity +* 作为子实体的 `town_blockade_start` 实体,并带有 `Blockade_Arc_Start` 标签 +* 作为子实体的 `town_blockade_end` 实体,并带有 `Blockade_Arc_End` 标签 +* 为该城镇实体添加 `BlockadePositionScript` -Once these have been added, the editor will display: +添加这些内容后,编辑器将显示: -* Red markers representing the individual blockade ship positions. -* A sphere indicating the center of the blockade arc. +* 代表各个封锁船只位置的红色标记。 +* 一个表示封锁弧中心的球体。 -Moving the start and end points changes the extent of the blockade arc, allowing you to adjust the visual placement of the blockade fleet. +移动起点和终点会改变封锁弧的范围,从而允许你调整封锁舰队的视觉位置。 -The `BlockadePositionScript` also exposes several parameters that control the appearance of the blockade, including: +`BlockadePositionScript` 还暴露了若干控制封锁外观的参数,包括: -* The number of ships. -* The number of blockade arcs. -* The spacing between ships. -* Other blockade layout settings. +* 船只数量。 +* 封锁弧数量。 +* 船只之间的间距。 +* 其他封锁布局设置。 -Adjust these values to achieve the desired visual result. +调整这些数值以达到所需的视觉效果。 -### Drop Off Points +### 卸货点(Drop Off Points) -Coastal villages use drop-off points instead of ports to support embarking and disembarking. +沿海村庄使用卸货点(drop-off points)而非港口来支持上船和下船。 -To add a drop-off point, create a child entity named `drop_point` and assign it the `main_map_village_dropoff` tag. +要添加卸货点,请创建一个名为 `drop_point` 的子实体,并为其分配 `main_map_village_dropoff` 标签。 -As with town ports, the drop-off point must be placed on a navigable naval navmesh (such as `CoastalSea` or `River`) for it to function correctly. +与城镇港口一样,卸货点必须放置在可通航的海军导航网格上(例如 `CoastalSea` 或 `River`),才能正常工作。 -## Transition +## 过渡(Transition) -In addition to transitions between naval travel and coastal settlements, War Sails also supports direct transitions between navigable water and land. +除了海上航行与沿海定居点之间的过渡之外,War Sails 还支持可通航水域与陆地之间的直接过渡。 -The only requirement is that both the source and destination navmesh types must be navigable. +唯一的要求是,源导航网格和目标导航网格类型都必须是可通航的。 -For example: +例如: -* A party can transition from `CoastalSea` to `Plain` or `Forest`. -* A party cannot transition to an impassable terrain type, such as `Mountain`. +* 一支队伍可以从 `CoastalSea` 过渡到 `Plain`(平原)或 `Forest`(森林)。 +* 一支队伍不能过渡到不可通行的地形类型,例如 `Mountain`(山地)。 -This allows you to define embarkation and disembarkation points at any suitable navigable shoreline, not just at settlements. +这使你可以在任何合适的可通航海岸线上定义上船和下船地点,而不仅限于定居点。 -## Scripts +## 脚本 -One of the most important components in the world map scene is the `SettlementPositionScript`, located under the `settlement_scripts` entity. +世界地图场景中最重要的组件之一是位于 `settlement_scripts` 实体下的 `SettlementPositionScript`。 -Whenever you make changes that affect navigation or settlement locations, the Settlement Distance Cache must be regenerated. This includes changes such as editing the navmesh or moving a settlement, including `town_gate`, `town_port`, or `drop_point`. +每当你进行影响导航或定居点位置的更改时,都必须重新生成定居点距离缓存(Settlement Distance Cache)。这包括诸如编辑导航网格或移动定居点(包括 `town_gate`、`town_port` 或 `drop_point`)之类的更改。 -To safely regenerate the cache, perform the following steps in order: +要安全地重新生成缓存,请按顺序执行以下步骤: -1. Before rebuilding the Settlement Distance Cache, verify that the following are selected: +1. 在重新构建定居点距离缓存之前,请确认以下内容已被选中: * `_partyNavigationModelOverridenClassName` → `NavalPartyNavigationModel` * `_distanceModelOverridenClassName` → `NavalDLCMapDistanceModel` -2. Check Positions - * Validates settlement-related positions and moves the camera to any problematic locations, making them easier to identify and fix. -3. Save Positions - * Saves the current settlement positions and all associated data. +2. Check Positions(检查位置) + * 验证与定居点相关的位置,并将摄像机移动到任何有问题的位置,以便更容易识别和修复。 +3. Save Positions(保存位置) + * 保存当前的定居点位置和所有相关数据。 4. `ComputeAndSaveSettlementDistanceCache` - * Rebuilds the Settlement Distance Cache. This final step can take a significant amount of time, depending on your hardware. During the process, the editor computes pathfinding routes between every settlement and every other settlement, then stores the results in the cache. + * 重新构建定居点距离缓存。根据你的硬件配置,这最后一步可能需要相当长的时间。在此过程中,编辑器会计算每个定居点与所有其他定居点之间的寻路路线,然后将结果存储到缓存中。 -## Water Plane and Material +## 水面与材质 -War Sails does not use the engine's automatically generated scene water. Instead, it uses custom planar meshes with water materials. +War Sails 不使用引擎自动生成的场景水体。相反,它使用带有水体材质的自定义平面网格。 -The built-in scene water is designed for mission scenes and has fixed scaling and behavior, making it unsuitable for the flexibility required by the campaign world map. Custom water planes allow you to precisely control the size, placement, and appearance of navigable water. +内置的场景水体是为任务场景设计的,具有固定的缩放和行为,不适合战役世界地图所需的灵活性。自定义水面使你能够精确控制可通航水域的大小、位置和外观。 -A standard War Sails water plane uses the following configuration: +标准的 War Sails 水面使用以下配置: -* Material: `naval_worldmap_water` -* Scripts: +* 材质:`naval_worldmap_water` +* 脚本: * `water_flowmap` * `CampaignMapAmbientOccluder` -* Tag: `snapped_water_body` +* 标签:`snapped_water_body` -The image below shows the required components and parameters for the main world map water plane. +下图展示了世界地图主水面所需的组件和参数。 -Note: The world map scene also contains additional `water_plane` entities used for lakes. Before making any changes, make sure you have selected the correct water plane. +注意:世界地图场景中还包含用于湖泊的其他 `water_plane` 实体。在进行任何更改之前,请确保你已选中正确的水面。 -### Creating a New Water Plane +### 创建新的水面 -To create a new water plane: +要创建新的水面: -1. Add the `water_plane` prefab to the scene. -2. Position, rotate, and scale it as needed. -3. In the Inspector, open the Materials tab and assign the desired water material (typically `naval_worldmap_water`). -4. Ensure the required scripts and tag are present if the water plane is intended to function as navigable world map water. +1. 将 `water_plane` 预制件(prefab)添加到场景中。 +2. 根据需要对其进行定位、旋转和缩放。 +3. 在 Inspector(检查器)中,打开 Materials(材质)选项卡,并分配所需的水体材质(通常为 `naval_worldmap_water`)。 +4. 如果该水面要作为可通航的世界地图水体,请确保存在所需的脚本和标签。 -Once configured, the water plane will integrate with the War Sails water rendering and Flowmap systems. +配置完成后,该水面将与 War Sails 的水体渲染和流动图系统集成。 -## Storm System +## 风暴系统 -War Sails features a dynamic storm system that generates storms over open water. +War Sails 具有一个动态风暴系统,可在开阔水域上生成风暴。 -The world map is divided into a grid of 32 × 32 unit cells. For each cell whose center lies on an `OpenSea` navmesh, the game periodically checks whether a storm should spawn. +世界地图被划分为 32 × 32 单位的网格单元。对于每个中心位于 `OpenSea` 导航网格上的单元,游戏会定期检查是否应生成风暴。 -Three storm types are available: +有三种可用的风暴类型: -* `Storm` -* `ThunderStorm` -* `Hurricane` +* `Storm`(风暴) +* `ThunderStorm`(雷暴) +* `Hurricane`(飓风) -The type of storm generated depends on the Flowmap data at the selected location. Each storm type has its own movement speed, radius, and damage characteristics. +生成的风暴类型取决于所选位置的流动图数据。每种风暴类型都有自己的移动速度、半径和伤害特性。 -### Configuring Storms +### 配置风暴 -Storm behavior can be customized by overriding the `StormModel` (through code, not in the editor). This allows you to adjust parameters such as: +可以通过重写 `StormModel`(通过代码,而非在编辑器中)来自定义风暴行为。这允许你调整以下参数: -* Hourly spawn chance -* Maximum number of active storms -* Storm type configuration -* Storm lifetime +* 每小时生成概率 +* 最大活动风暴数量 +* 风暴类型配置 +* 风暴持续时间 -### Storm Movement +### 风暴移动 -Storms do not follow predefined paths. Instead, they are driven by the Flowmap. +风暴不遵循预定义的路径。相反,它们由流动图驱动。 -As a storm moves across the world map, it continuously follows the flow direction defined by the Flowmap at its current location. This allows storm movement to naturally match the current patterns you've painted into the map. +当风暴在世界地图上移动时,它会持续沿着其当前位置的流动图所定义的流动方向移动。这使得风暴的移动能够自然地与你在地图中绘制的水流模式相匹配。 -### Flowmap Considerations +### 流动图注意事项 -Storms gradually weaken and eventually dissipate when they remain over land navmesh. +当风暴长时间停留在陆地导航网格上时,它们会逐渐减弱并最终消散。 -For this reason, when painting the Flowmap near coastlines, it is recommended to direct the flow away from land and toward open water. This helps keep storms at sea and prevents them from immediately dissipating after spawning or drifting near the coast. +因此,在沿海地区绘制流动图时,建议将水流方向指向远离陆地、朝向开阔水域的方向。这有助于让风暴停留在海上,并防止它们在生成后或靠近海岸漂移时立即消散。 -## Pirate Spawn Points +## 海盗生成点 -War Sails uses dedicated pirate spawn points to control where pirate parties appear and the regions they patrol over time. +War Sails 使用专门的海盗生成点来控制海盗队伍出现的位置以及它们随时间巡逻的区域。 -Each pirate spawn point must have a `PirateSpawnPoint` script attached. In the script, set the Clan String ID to the appropriate pirate clan. War Sails has two clans available: +每个海盗生成点都必须附加一个 `PirateSpawnPoint` 脚本。在该脚本中,将 Clan String ID(氏族字符串 ID)设置为相应的海盗氏族。War Sails 提供两个可用氏族: * `northern_pirates` * `southern_pirates` -If you wish to add new clans, you should define them in the `clans.xml`, and then proceed to add them to the world map. +如果你希望添加新的氏族,应先在 `clans.xml` 中定义它们,然后再将其添加到世界地图中。 diff --git a/docs/content/schinese/_index.md b/docs/content/schinese/_index.md index 94ba890b..e8cf1526 100644 --- a/docs/content/schinese/_index.md +++ b/docs/content/schinese/_index.md @@ -14,7 +14,7 @@ TaleWorlds 官方的《霸主》Mod 制作指南:模块、资产、场景、 1. **[创建一个Mod - 快速入门]({{< ref "quickguide_create_a_mod.md" >}})**:创建并注册你的第一个模块。 2. **[添加与覆盖资产]({{< ref "overriding_assets.md" >}})**:添加新资产或替换现有资产。 -3. **[Merging Module XML Files with Native]({{< ref "merging_module_xml_files_with_native.md" >}})**:无需复制整个文件即可修改游戏数据。 +3. **[将模块XML文件与原生数据合并]({{< ref "merging_module_xml_files_with_native.md" >}})**:无需复制整个文件即可修改游戏数据。 4. **[上传/更新一个模组]({{< ref "uploading_updating_mod.md" >}})**:将你的 Mod 发布到 Steam 创意工坊。 5. **[常见问题解答]({{< ref "faq.md" >}})**:常见问题的解答。 @@ -25,7 +25,7 @@ TaleWorlds 官方的《霸主》Mod 制作指南:模块、资产、场景、 - [地形创建]({{< ref "terrain_creation.md" >}}) - [导航网格]({{< ref "nav_mesh.md" >}}) - [编辑器快捷键]({{< ref "editor_shortcuts.md" >}}) -- [Scene Performance Guide]({{< ref "scene_performance_guide.md" >}}) +- [场景性能指南]({{< ref "scene_performance_guide.md" >}}) {{< /card >}} {{< card title="制作任务场景" icon="fa-chess-rook" >}} - [村庄场景]({{< ref "villages.md" >}}) @@ -34,25 +34,25 @@ TaleWorlds 官方的《霸主》Mod 制作指南:模块、资产、场景、 - [藏身处场景]({{< ref "hideouts.md" >}}) {{< /card >}} {{< card title="添加物品和武器" icon="fa-shield" >}} -- [Weapon Smithing & Crafting Pieces]({{< ref "weapon_smithing.md" >}}) +- [武器锻造与制作部件]({{< ref "weapon_smithing.md" >}}) - [网格]({{< ref "meshes.md" >}}) - [材质]({{< ref "materials.md" >}}) - [纹理]({{< ref "textures.md" >}}) {{< /card >}} {{< card title="添加音效和音乐" icon="fa-music" >}} -- [Audio Modding with FMOD Studio]({{< ref "audio-modding-overview.md" >}}) -- [Event Setup]({{< ref "audio-modding-event-setup.md" >}}) -- [Scene Audio]({{< ref "audio-modding-scene-audio.md" >}}) -- [Audio Systems & Optimization]({{< ref "audio-modding-systems.md" >}}) +- [使用 FMOD Studio 进行音频模组制作]({{< ref "audio-modding-overview.md" >}}) +- [事件设置]({{< ref "audio-modding-event-setup.md" >}}) +- [场景音频]({{< ref "audio-modding-scene-audio.md" >}}) +- [音频系统与优化]({{< ref "audio-modding-systems.md" >}}) {{< /card >}} {{< card title="制作船只和海战内容" icon="fa-ship" >}} -- [Ship Creation]({{< ref "ship_creation.md" >}}) -- [Seaborne Raid Scenes]({{< ref "what_makes_seaborne_village_raid_scene.md" >}}) -- [War Sails World Map]({{< ref "wsworldmap.md" >}}) +- [船只创建]({{< ref "ship_creation.md" >}}) +- [海上突袭场景的构成要素]({{< ref "what_makes_seaborne_village_raid_scene.md" >}}) +- [War Sails 世界地图]({{< ref "wsworldmap.md" >}}) {{< /card >}} {{< card title="制作多人游戏内容" icon="fa-users" >}} - [创建自定义游戏模式]({{< ref "custom_game_mode.md" >}}) -- [Hosting a Custom Server]({{< ref "hosting_server.md" >}}) +- [托管自定义服务器]({{< ref "hosting_server.md" >}}) - [多人游戏场景的构造]({{< ref "multiplayer_scenes.md" >}}) {{< /card >}} {{< card title="修改界面、字体和旗帜" icon="fa-paint-brush" >}} @@ -63,7 +63,7 @@ TaleWorlds 官方的《霸主》Mod 制作指南:模块、资产、场景、 {{< card title="编写代码" icon="fa-code" >}} - [脚本]({{< ref "scripts.md" >}}) - [脚本组件回调函数]({{< ref "callbacks.md" >}}) -- [Sealed Class Extension]({{< ref "sealed_class_extension.md" >}}) +- [密封类(Sealed Class)的扩展]({{< ref "sealed_class_extension.md" >}}) - [API 文档](https://apidoc.bannerlord.com/) {{< /card >}} {{< /cards >}} @@ -101,7 +101,51 @@ XML 合并、XSLT、代码扩展和场景性能的推荐做法。 - **[API 文档](https://apidoc.bannerlord.com/)**:《霸主》代码参考。 - **[骑马与砍杀 Mod 制作 Discord](https://discord.gg/ykFVJGQ)**:提问并与其他 Mod 作者交流。 -- **[Bannerlord Documentation(社区)](https://docs.bannerlordmodding.com/)**:社区编写的指南,包括 Gauntlet UI 和为 Vortex 打包 Mod。 -- **[BannerlordModding.LT(社区)](https://docs.bannerlordmodding.lt/)**:记录 Mod 制作流程、技巧和经验的社区百科。 +- **[Developer Workshop – Map Editor](https://www.youtube.com/watch?v=ovQiJfeQB8s)**:TaleWorlds 官方直播,演示如何使用战役地图编辑器(英文)。 - **[TaleWorlds 论坛 – The Smithy](https://forums.taleworlds.com/index.php?forums/the-smithy-mod-development.643/)**:官方 Mod 开发论坛。 - **[在 GitHub 上贡献](https://github.com/TaleWorlds/Documentations)**:为本文档提出修改建议或新页面。 + +## 社区资源 + +以下资源由社区制作和维护,并非由 TaleWorlds 提供。部分资源基于旧版游戏制作,细节可能与当前版本不同。大多数资源仅提供英文版本。 + +### 文档与指南 + +- **[Bannerlord Documentation](https://docs.bannerlordmodding.com/)**:社区编写的指南,包括 Gauntlet UI 和为 Vortex 打包 Mod。 +- **[BannerlordModding.LT](https://docs.bannerlordmodding.lt/)**:记录 Mod 制作流程、技巧和经验的社区百科。 +- **[Unofficial Bannerlord API Docs (BUTR)](https://bannerlordapi.butr.link/)**:根据游戏文件生成的各版本 API 参考。 +- **[BUTR Documentation](https://butr.github.io/documentation)**:Harmony 调试、崩溃报告以及使用 GitHub Actions 发布 Mod 的操作指南。 +- **[Documentation & Tutorials 论坛版块](https://forums.taleworlds.com/index.php?forums/documentation-tutorials.753/)**:社区在 TaleWorlds 论坛分享的教程。 + +### 社区指南(Google 文档) + +- **[3D Asset Workflow](https://docs.google.com/document/d/1aHBsO3mzkT0JsbCt9aCOh6CWAFATXwKtSaVb__TYIoo/edit)**:为《霸主》准备 3D 资源。 +- **[Asset Import Workflow](https://docs.google.com/document/d/11-J8HzS2FdnwwXfR7JmD_FQSQ6dWaJj_BZr1-vVW9Ks/edit)**:分步骤的资源导入流程。 +- **[Importing Assets into BL Editor](https://docs.google.com/document/d/1ZnkRjNu6wUx3UM0exMiC8WhE8iDXPJKqYcbZdRh_q0o/edit)**:将你的资源导入《霸主》编辑器。 +- **[Importing Material Maps in Editor](https://docs.google.com/document/d/1843jpWFYLylJya1-_-wQpkemV58KT3EomEoqUYKpZTo/edit)**:导入纹理和材质贴图。 +- **[Basic World Mapping](https://docs.google.com/document/d/1npGJ9p1ySdu2RDU19P_2aE-OCsKWie_G02vcws36UIs/edit)**:制作自定义战役地图入门。 +- **[Adding Custom Scenes to Custom Battle](https://docs.google.com/document/d/1Rwsd9pdv5QA5s3K4oOuJX16_K9A5NaoWh0p78IcUi1w/edit)**:在自定义战斗中测试你的场景。 +- **[Adding Flora to flora_kinds](https://docs.google.com/document/d/1VGpct-__3s6hn15GXHo5P1TS-yMrGfDxCed1UZ3AaNI/edit)**:在 flora_kinds 中注册新植被。 +- **[Bannerlord Layer Buttons, Options, and Settings](https://docs.google.com/document/d/1EiLvSZEJ_88fnva6d9s8H36XLH13YkVdim6jABe095s/edit)**(部分完成):编辑器图层按钮、选项和设置的说明。 + +### 视频教程 + +- **[Lesser Scholar – Artisan Workshop Mod](https://www.youtube.com/playlist?list=PLzebdAxJeltRwfJ8jzsNolgHkRvLjoCRC)**:共 19 集的 C# 课程,涵盖环境配置、战役行为、对话、Gauntlet UI、Harmony 和发布。 +- **[A_Jannik](https://www.youtube.com/playlist?list=PLXLt7zu34iHFzZVDzZpvareujNqbJiypj)**:C# 入口点、调试和 Harmony 补丁。 +- **[Danqna & Gispry](https://www.youtube.com/watch?v=duvR9xFvu9Q)**:共 6 集的 C# 系列,涵盖 Visual Studio 配置、对话、存档和 MCM 菜单。 +- **[Macbeth of Gondor](https://www.youtube.com/@MacbethofGondor)**:共 19 集的场景编辑器系列,涵盖地形、植被、导航网格、季节、预制件和屏障。 +- **[Banner Lab](https://www.youtube.com/playlist?list=PLxhni8XI_dRDjRRDsCzEBZg4eUInzkzQT)**:无需代码的 XML Mod 制作:兵种、物品、文化、王国、英雄和定居点。 +- **[Lykon Development](https://www.youtube.com/@LykonDevelopment/videos)**:XML 兵种、武器和王国,加载画面,以及 Blender 权重绘制。 +- **[Adam Dotlačil](https://www.youtube.com/@enpremi)**:自定义弓、弩和箭袋,以及自定义模型的手部动画。 +- **[BabyLettuce – Skeletons & Races](https://www.youtube.com/watch?v=eXHd8yjoxk0)**:自定义骨骼和种族的完整教程。 + +### 工具 + +- **[Bannerlord Scene Toolkit](https://github.com/fiefevictionnotice/BannerlordSceneToolkit)**(作者:FiefEvictionNotice):在场景编辑器内运行的工具集,提供材质替换与重新着色、预制件创建、分布与镜像、场景分析和备份功能。参见[教程视频](https://www.youtube.com/watch?v=f1uzZ-qQm3c)(英文)。 +- **[XBannerlord](https://forums.taleworlds.com/index.php?threads/tool-xbannerlord-an-ai-powered-xml-editor-for-bannerlord-mod-xmls.470278/)**(作者:cookgreen):Windows 平台的 XML 编辑器,以树形结构显示《霸主》XML 文件,并可通过与 AI 模型对话来编辑所选节点。提供英文和中文界面。[GitHub 源代码](https://github.com/cookgreen/XBannerlord)。 +- **[Bannerlord Crafting Tool](https://github.com/haterade22/TAOM/releases/tag/crafting-tool-v1.0)**(作者:haterade22):Windows 工具,可在 2D 和 3D 中预览武器锻造部件,无需启动游戏即可调整部件偏移并检查武器长度。 + +### 入门资源包 + +- **[Campaign Map Prefab Starter Pack](https://www.nexusmods.com/mountandblade2bannerlord/mods/11608)**(作者:Lemmy1916):带有预建定居点和脚本的现成战役地图,可用于制作新的世界地图。 +- **[War Sails Campaign Map Prefab Starter Pack](https://www.nexusmods.com/mountandblade2bannerlord/mods/13602)**(作者:Lemmy1916):为 War Sails 配置的同款入门地图。 diff --git a/docs/layouts/_default/list.html b/docs/layouts/_default/list.html new file mode 100644 index 00000000..793103f6 --- /dev/null +++ b/docs/layouts/_default/list.html @@ -0,0 +1,21 @@ +{{ define "main" }} +{{if .Content}} +{{ .Content }} +{{ partial "ai-translation-note.html" . }} +{{else }} +{{ $paginator := .Paginator }} + + +{{ partial "pagination.html" $paginator }} + + +{{ range $index, $page := $paginator.Pages }} + {{ .Render "li" }} +{{ end }} + + + +{{ partial "pagination.html" $paginator }} + +{{end}} +{{end}} \ No newline at end of file diff --git a/docs/layouts/_default/single.html b/docs/layouts/_default/single.html new file mode 100644 index 00000000..9cd7fa88 --- /dev/null +++ b/docs/layouts/_default/single.html @@ -0,0 +1,4 @@ +{{ define "main" }} + {{ .Content }} + {{ partial "ai-translation-note.html" . }} +{{ end }} diff --git a/docs/layouts/index.html b/docs/layouts/index.html new file mode 100644 index 00000000..3d88ce5f --- /dev/null +++ b/docs/layouts/index.html @@ -0,0 +1,31 @@ +{{ define "main" }} + + navigation + +{{if .Site.Home.Content }} +{{.Site.Home.Content}} +{{ partial "ai-translation-note.html" .Site.Home }} +{{else}} + {{if eq .Site.Language.Lang "fr"}} + Personaliser la page d'accueil + + Le site fonctionne. Ne pas oublier de personaliser cette page avec votre propre contenu. 2 façons de faire : + + + 1. Créer un fichier _index.md dans le dossier content + 2. Configurer le serveur http pour rediriger automatiquement la homepage vers la page de votre choix dans le site + + {{else}} + Customize your own home page + + The site is working. Don't forget to customize this homepage with your own. You typically have 2 choices : + + + 1. Create an _index.md document in the content folder + 2. Configure your server to automatically redirect this home page to one of your documentation pages + + {{end}} + +{{ end }} + +{{ end }} \ No newline at end of file diff --git a/docs/layouts/partials/ai-translation-note.html b/docs/layouts/partials/ai-translation-note.html new file mode 100644 index 00000000..c0fe8fe0 --- /dev/null +++ b/docs/layouts/partials/ai-translation-note.html @@ -0,0 +1,5 @@ +{{ if .Params.ai_translated }} + + {{ if eq .Lang "ru" }}Эта страница переведена с помощью ИИ и может содержать неточности. Оригинал на английском языке является основным источником.{{ else if eq .Lang "zh_cn" }}本页面由 AI 翻译,可能存在不准确之处。请以英文原版为准。{{ else }}This page was translated with AI and may contain inaccuracies.{{ end }} + +{{ end }} \ No newline at end of file
Picture 1: Fine Steel Cavalry Broadsword being created on Smithing screen.
Рисунок 1: Создание кавалерийского палаша из прекрасной стали на экране кузницы.
Picture 2: Example, battania_grip_1 mesh in Blender viewport before exporting.
Рисунок 2: Пример, меш battania_grip_1 в окне просмотра Blender перед экспортом.
Picture 3: All weapon parts positioned neatly at the world origin.
Рисунок 3: Все детали оружия аккуратно размещены в начале координат мира.
Picture 4: Sword parts directory hierarchy.
Рисунок 4: Иерархия директорий деталей меча.
图1:在锻造界面上创建精钢骑兵阔剑。
图2:示例,battania_grip_1网格在导出前于Blender视口中的样子。
图3:所有武器部件整齐地定位在世界原点处。
图4:剑部件目录层级结构。
+ Le site fonctionne. Ne pas oublier de personaliser cette page avec votre propre contenu. 2 façons de faire : +
+ The site is working. Don't forget to customize this homepage with your own. You typically have 2 choices : +