ZeldaMods (Breath of the Wild) - User contributions [en]

Water.extm

2022-10-10T15:16:39Z

Greenlord:

{{lowercase}}
<onlyinclude>
[[File:5000000000.water.extm.png|alt=Generated water material map of Hyrule Main Field|thumb|Generated water material map of Hyrule Main Field]]
<code>water.extm</code> files describe the water heightmap and the texture of the main field and add-on content field.
</onlyinclude>

==water.extm File Specification==

===water.extm File Layout===

Each file contains a 64×64 grid. For each vertex there is 8 bytes of data that describe the height of the mesh, the material type and flow speed.

===Water Map Data===

Each entry in the water data table is 8 bytes long.

{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|0x00
|2
|Unsigned Short
|<code>height</code> (Vertex <code>y</code> component)
|-
|0x02
|2
|Unsigned Short
|<code>xAxisFlowRate</code> 128 = no flow
|-
|0x04
|2
|Unsigned Short
|<code>zAxisFlowRate</code> 128 = no flow
|-
|0x05
|1
|Unsigned Byte
|<code>materialIndex + 3</code>. This may act as a checksum?
|-
|0x06
|1
|Unsigned Byte
|<code>materialIndex</code>
|}

<code>height</code> and <code>flowRate</code> are stored as unsigned shorts, but seem to map to float values. These can be calculated by dividing by the max size of an unsigned short:

<syntaxhighlight lang="c" line="line">
32767 / 0xffff = 0.5
</syntaxhighlight>

<code>height</code> is further multiplied by another constant to get the final height (the constant is unknown at this time, but is close to <code>0x300 / 0xffff</code>).

<code>x</code> and <code>z</code><ref><code>z</code> is expected to be an integer quotient. The <code>floor</code> function can be used if integer division is not supported.</ref> can be calculated, while iterating through the data table:

<syntaxhighlight lang="c" line="line">
for (int index = 0; index < 64 * 64; index++) {
uint x = index % 64;
uint z = index / 64;
}
</syntaxhighlight>

Flow Rates are calculated as <code>(flowRate * 2) - 1</code> and ranges from <code>-1</code> to <code>1</code>. On the x-axis this changes flow direction from East (<code>-1</code>) to West (<code>+1</code>) and on the z-axis from North (<code>-1</code>) to South (<code>+1</code>).

===Material Index===

This data is stored in Terrain.Tex1.bfres.

{| class="wikitable"
!id
!file
!name
!attribute
!attribute_sub
!flag
!Google Translated
|-
|0
|Water
|水
|Water
|Water
|0
|Water
|-
|1
|HotWater
|熱湯
|Water
|Water_Hot
|0
|Hot water
|-
|2
|Poison
|毒水
|Water
|Water_Poison
|0
|Poison water
|-
|3
|Lava
|溶岩
|Lava
|Lava
|0
|Lava
|-
|4
|IceWater
|冷たい水
|Water
|Water_Ice
|0
|Cold water
|-
|5
|Mud
|泥沼
|Bog
|Bog
|0
|Bog
|-
|6
|Clear01
|透明水01
|Water
|Water
|0
|Clear water 01
|-
|7
|Sea
|海
|Water
|Water
|0
|Ocean
|}

<references />

[[Category:File formats]]
[[Category:File extensions]]
[[Category:File extensions (STERA)]]

TSCB

2022-01-10T21:49:40Z

Greenlord: Specify what extra_info_array is for.

<onlyinclude>
'''T'''errain '''sc'''ene '''b'''inary (TSCB) files describe terrain areas layout and terrain materials.
</onlyinclude>

==TSCB File Specification==

===Header===
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|String
|TSCB file signature (magic) <code>54 53 43 42</code> or "TSCB"
|-
|<code>0x04</code>
|4
|Unsigned Int
|TSCB version? <code>0A 00 00 00</code> or "10.0.0.0"<ref>U-King.elf:0x024D2F8C-0x024D300A holds two error messages: "【データロード】メジャーバージョンの不一致" ("[Data load] Major version mismatch") and "【データロード】マイナーバージョンの不一致" ("[Data Load] Minor version mismatch")</ref><ref>Game crashes on load screen if not equal to <code>0A 00 00 00</code></ref>
|-
|<code>0x08</code>
|4
|Unsigned Int
|Unknown. Always <code>00 00 00 01</code>. Game crashes on load screen if not equal to <code>00 00 00 01</code>.
|-
|<code>0x0c</code>
|4
|Unsigned Int
|<code>file_base</code> table relative offset
|-
|<code>0x10</code>
|4
|Float
|<code>world_scale</code> <code>500.0</code>. Scales the terrain along the x- and z-axis.
|-
|<code>0x14</code>
|4
|Float
|Terrain mesh max height <code>800.0</code>. Used to calculate the actual vertex height with [[HGHT|hght]] data.
|-
|<code>0x18</code>
|4
|Unsigned Int
|<code>material_info_array</code> length (number of elements in the array)
|-
|<code>0x1c</code>
|4
|Unsigned Int
|<code>area_array</code> length (number of elements in the array)
|-
|<code>0x20</code>
|4
|Unsigned Int
|Probably padding
|-
|<code>0x24</code>
|4
|Unsigned Int
|Probably padding
|-
|<code>0x28</code>
|4
|Float
|<code>tile_size</code>. Used by the area array.
|-
|<code>0x2c</code>
|4
|Unsigned Int
|Unknown <code>00 00 00 08</code>. <ref>Values <code>1</code>, <code>2</code>, <code>4</code>, <code>5</code>, <code>6</code>, <code>8</code>, <code>9</code>, <code>10</code>, <code>13</code>, <code>14</code> affects textures. <code>0</code>, <code>3</code>, <code>7</code>, <code>11</code>, <code>12</code>, <code>15</code>, <code>16</code> will crash the game.</ref>
|}

==Material Information Array==
The material information array references texture data contained in <code>content/Model/Terrain.Tex1.sbfres</code>.

===Header===
The material information header is one value, the section size. This includes the index table and the value table, as well as itself.
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|Material info section size in bytes
|}

===Material Information Array Lookup Table===
Following the header is a table of relative offsets to each entry in <code>material_info_array</code>
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|Offset to array entry, relative to the first byte of this offset
|}

===Material Information Value Table===
Each entry in the array contains an index and four attributes
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|Array index (<code>mat_index</code>) of <code>material_info_array</code>
|-
|<code>0x04</code>
|4
|Float
|Texture u-axis (x-axis)
|-
|<code>0x08</code>
|4
|Float
|Texture v-axis (y-axis)
|-
|<code>0x0c</code>
|4
|Float
|Unknown. values range from 0-1.
|-
|<code>0x10</code>
|4
|Float
|Unknown. values range from 0.2-1.63
|}

==Area Array==

===Area Array Lookup Table===
Following the material information section is a table of relative offsets to each entry in area_array
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|Offset to array entry, relative to the first byte of this offset
|}

===Area Array Value Table===
Each entry contains meta data for one tile in the terrain scene. There are multiple levels of detail (lod) for the terrain.

Entry size ranges from <code>0x30</code> to <code>0x58</code> depending on the size of <code>extra_info_array</code>
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Float
|X Position
|-
|<code>0x04</code>
|4
|Float
|Z Position
|-
|<code>0x08</code>
|4
|Float
|<code>area_size</code> (length and width)
|-
|<code>0x0c</code>
|4
|Float
|Minimum Terrain Height - ranges from 0 to 1
|-
|<code>0x10</code>
|4
|Float
|Maximum Terrain Height - ranges from 0 to 1
|-
|<code>0x14</code>
|4
|Float
|Minimum Water Height - ranges from 0 to 1
|-
|<code>0x18</code>
|4
|Float
|Maximum Water Height - ranges from 0 to 1
|-
|<code>0x1c</code>
|4
|Unsigned Int
|Unknown. Usually <code>0</code>, <code>1</code> or <code>2</code>, crashes on <code>4</code>, <code>16</code>.<ref>May be a flag for grass and water? <code>0</code> seems to indicate no water or grass.</ref>
|-
|<code>0x20</code>
|4
|Unsigned Int
|<code>file_base</code>. Relative offset to file base name string.
|-
|<code>0x24</code>
|4
|Unsigned Int
|Unknown. Usually <code>0</code>.
|-
|<code>0x28</code>
|4
|Unsigned Int
|Unknown. Usually <code>0</code>.
|-
|<code>0x2c</code>
|4
|Unsigned Int
|<code>ref_extra</code>. It seems to be a flag to indicate if there is an attached <code>extra_info_array</code>
|}

====Parameters====
<code>x</code> - Area tile x coordinate (East-West)

<code>z</code> - Area tile z coordinate (North-South)
<code>area_size</code> - Determines the length and width of the area. It can be calculated with:<blockquote><code>(area_size / tile_size * world_scale) * 20</code></blockquote><code>tile_size</code> and <code>world_scale</code> are in the header.

===Extra Information Array===
if <code>ref_extra</code> does not equal <code>0</code> there is an <code>extra_info_array</code> attached to this area. The array is 4 or 8 values long.

Every area includes a [[HGHT|.hght]] and [[MATE|.mate]] file. Entries in the <code>extra_info_array</code> indicate if there is an additional [[Water.extm|.water.extm]] and / or [[Grass.extm|.grass.extm]] file to look for.

===Terrain and Water Height===
0x0c through 0x18 are used to determine what height range the terrain and water should render within. This is possibly used to assist with occlusion. If the heightmap moves outside of the range defined here, there will be visual artefacts present at higher viewing angles, usually between 45 and 90 degrees. The range value is multiplied by the max height defined in the TSCB header to determine the final value in 'real' co-ordinates.

====Header====
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|extra_info_array length. Number of values (not elements) in array.
|-
|<code>(0x04)</code>
|4
|Unsigned Int
|Unknown. Always 20, but only present when extra_info_array length is 8.
|}

====Extra Information Array Value Table====
After the Header, there are <code>extra_info_array length / 4</code> elements of this structure.
Elements act as flags for presence of [[Water.extm|.water.extm]] or [[Grass.extm|.grass.extm]] files.
A "water" element indicates that there is water data for the terrain section defined in a [[Water.extm|.water.extm]] file. A "grass" element similarly indicates the presence of a [[Grass.extm|.grass.extm]] file.
Grass and water are referenced via the <code>extra_info_array</code> because presence water and grass data for any given terrain area is optional.
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|0x00
|4
|Unsigned Int
|Unknown. Always 3.
|-
|0x04
|4
|Unsigned Int
|Unknown. 0 or 1.
|-
|0x08
|4
|Unsigned Int
|Unknown. Always 1.
|-
|0x0c
|4
|Unsigned Int
|Unknown. Always 0.
|}
[3, 0, 1, 0, 3, 1, 1, 0] = grass, water
[3, 1, 1, 0, 3, 0, 1, 0] = water, grass
[3, 1, 1, 0] = water
[3, 0, 1, 0] = grass
It seems that water is <code>[3, 1, 1]</code> and grass is <code>[3, 0, 1]</code>

==<code>stera</code> File Positions==
[[File:Stera_File_Positions.png|alt=stera File Positions|thumb|<code>stera</code> File Positions]]
<code>stera</code> files referenced in the area array are positioned using a [[wikipedia:Z-order_curve|z-order curve]] or the [[wikipedia:Moser–de_Bruijn_sequence|Moser-de Bruijn sequence]].
<references />
[[Category:File formats]]
[[Category:File extensions]]
[[Category:File extensions (STERA)]]

Water.extm

2022-01-08T22:41:38Z

Greenlord: Adjust code snippet to be consistent with water.extm size

{{lowercase}}
<onlyinclude>
[[File:5000000000.water.extm.png|alt=Generated water material map of Hyrule Main Field|thumb|Generated water material map of Hyrule Main Field]]
<code>water.extm</code> files describe the water heightmap and the texture of the main field and add-on content field.
</onlyinclude>

== water.extm File Specification ==

=== water.extm File Layout ===

Each file contains a 64×64 grid. For each vertex there is 8 bytes of data that describe the height of the mesh, the material type and flow speed.

=== Water Map Data ===

Each entry in the water data table is 8 bytes long.

{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|0x00
|2
|Unsigned Short
|<code>height</code> (Vertex <code>y</code> component)
|-
|0x02
|2
|Unsigned Short
|<code>xAxisFlowRate</code>
|-
|0x04
|2
|Unsigned Short
|<code>zAxisFlowRate</code>
|-
|0x05
|1
|Unsigned Byte
|<code>materialIndex + 3</code>. This may act as a checksum?
|-
|0x06
|1
|Unsigned Byte
|<code>materialIndex</code>
|}

<code>height</code> and <code>flowSpeed</code> are stored as unsigned shorts, but seem to map to float values. These can be calculated by dividing by the max size of an unsigned short:

<syntaxhighlight lang="c" line="line">
32767 / 0xffff = 0.5
</syntaxhighlight>

<code>height</code> is further multiplied by another constant to get the final height (the constant is unknown at this time, but is close to <code>0x300 / 0xffff</code>).

<code>x</code> and <code>z</code><ref><code>z</code> is expected to be an integer quotient. The <code>floor</code> function can be used if integer division is not supported.</ref> can be calculated, while iterating through the data table:

<syntaxhighlight lang="c" line="line">
for (int index = 0; index < 64 * 64; index++) {
uint x = index % 64;
uint z = index / 64;
}
</syntaxhighlight>

Flow Rates are calculated as <code>(flowRate * 2) - 1</code> and ranges from <code>-1</code> to <code>1</code>. On the x-axis this changes flow direction from East (<code>-1</code>) to West (<code>+1</code>) and on the z-axis from North (<code>-1</code>) to South (<code>+1</code>).

=== Material Index ===

This data is stored in Terrain.Tex1.bfres.

{| class="wikitable"
!id
!file
!name
!attribute
!attribute_sub
!flag
!Google Translated
|-
|0
|Water
|水
|Water
|Water
|0
|Water
|-
|1
|HotWater
|熱湯
|Water
|Water_Hot
|0
|Hot water
|-
|2
|Poison
|毒水
|Water
|Water_Poison
|0
|Poison water
|-
|3
|Lava
|溶岩
|Lava
|Lava
|0
|Lava
|-
|4
|IceWater
|冷たい水
|Water
|Water_Ice
|0
|Cold water
|-
|5
|Mud
|泥沼
|Bog
|Bog
|0
|Bog
|-
|6
|Clear01
|透明水01
|Water
|Water
|0
|Clear water 01
|-
|7
|Sea
|海
|Water
|Water
|0
|Ocean
|}

<references />

[[Category:File formats]]
[[Category:File extensions]]
[[Category:File extensions (STERA)]]

Terminal

2021-11-07T20:16:28Z

Greenlord:

{{Subsystem infobox|name=Terminal|is_name_official=1|description=Debug tool?|init_addr_switch150=000000710109CC44|init_addr_wiiu150=035eb994}}
{{stub}}

[[Category: Internals]]
[[Category: Subsystems (BotW)]]

Havok

2021-10-28T11:15:09Z

Greenlord: Relative offsets tend to be relative to the provided absolute offset.

'''Havok''' is a middleware software suite developed by the Irish company Havok. Havok provides a physics engine component and related functions to video games.

On September 14, 2007, Intel announced it had signed a definitive agreement to acquire Havok Inc.<ref>[http://www.intel.com/pressroom/archive/releases/2007/20070914corp.htm Intel To Acquire Havok]</ref> In 2008, Havok was honored at the 59th Annual Technology & Engineering Emmy Awards for advancing the development of physics engines in electronic entertainment. On October 2, 2015, Microsoft announced it had acquired Havok.<ref>[http://blogs.microsoft.com/blog/2015/10/02/havok-to-join-microsoft Havok to join Microsoft]</ref>
</onlyinclude>

==Products==
The Havok middleware suite consists of the following modules:<ref>[http://www.havok.com/products Product Overview]</ref>

*'''Havok Physics''': It is designed primarily for video games, and allows for real-time collision and dynamics of rigid bodies in three dimensions. It provides multiple types of dynamic constraints between rigid bodies (e.g. for ragdoll physics), and has a highly optimized collision detection library. By using dynamical simulation, Havok Physics allows for more realistic virtual worlds in games. The company was developing a specialized version of Havok Physics called Havok FX that made use of ATI and NVIDIA GPUs for physics simulations;<ref>[https://web.archive.org/web/20081205092623/http://www.xbitlabs.com/news/multimedia/display/20051028224421.html Havok Intros Havok FX Engine to Compute Physics Effects on GPUs]</ref> however, the goal of GPU acceleration did not materialize until several years later.<ref>[https://www.youtube.com/watch?v=v1hoVCZZOd0&list=UUfcEdH66zmcp8JEz5NkwJuw&index=6 Havok Physics Playstation 4 Demo]</ref>
*'''Havok AI''': In 2009, Havok released Havok AI, which provides advanced pathfinding capabilities for games. Havok AI provides navigation mesh generation, pathfinding and path following for video game environments.
*'''Havok Cloth''': Released in 2008, Havok Cloth deals with efficient simulation of character garments and soft body dynamics.
*'''Havok Destruction''': Also released in 2008, Havok Destruction provides tools for creation of destructible and deformable rigid body environments.
*'''Havok Animation Studio (discontinued)''': Havok Animation Studio is formally known as Havok Behavior and Havok Animation. Havok Behavior is a runtime SDK for controlling game character animation at a high level using finite state machines. Havok Animation provides efficient playback and compression of character animations in games, and features such as inverse kinematics.
*'''Havok Script (discontinued)''': Havok Script is a Lua-compatible virtual machine designed for video game development. It is shipped as part of the Havok Script Studio.
*'''Havok Vision Engine''' '''(discontinued):''' On August 8, 2011, Havok announced their acquisition of German game engine development company Trinigy and their Vision Engine and toolset.

==Usage==
{{Expand section}}
''Breath of the Wild'' uses the '''Havok Physics''', '''Havok AI''' and '''Havok Cloth'''.
{| class="wikitable"
|+File Extensions
!Extension
!Product
!Description
!Locations
|-
|[[hknm2]]
|Havok AI
|Navigation meshes (used by AI for path finding)
|<code>NavMesh/</code>
|-
|[[hkrb]]
|Havok Physics
|Rigid body physics
|<code>Physics/RigidBody/</code>
|-
|[[hkcl]]
|Havok Cloth
|Cloth physics
|<code>Physics/Cloth/</code>
|-
|[[hkrg]]
|Havok Physics
|Rag doll physics
|<code>Physics/Ragdoll/</code>
|-
|[[hksc]]
|Havok Physics
|Static compound physics
|<code>Physics/StaticCompound/</code>
|-
|[[hktmrb]]
|Havok Physics
|Terrain mesh rigid body physics
|<code>Physics/TeraMeshRigidBody/</code>
|}

===File Types===

====hknm2====
{{Expand section}}Used in shrines and field sections.

====hkrb====
{{Expand section}}Used in actors.

====hkcl====
{{Expand section}}Used in actors.

====hkrg====
{{Expand section}}Used in actors.

====hksc====
{{Expand section}}Used in shrines and field sections.

====hktmrb====
{{Expand section}}Used in field sections.

==Havok File Specification==
Havok files serve as a data container for multiple Havok classes per file and sometimes multiple Havok files per file<ref>Static Compound files ([[hksc]]) include two Havok file definitions. The first file defines <code>StaticCompoundInfo</code> and the second defines <code>hkpPhysicsData</code> (which includes <code>hkpRigidBody</code>, <code>hkpStaticCompoundShape</code>, <code>hkpBvCompressedMeshShape</code>, <code>hkpConvexVerticesShape</code>, et. al.).</ref>. The class names are defined in each file.

Note that this specification only applies to version 2014.2.0-r1

===File Structure===
[[File:Havok-file-structure.png|thumb|File structure]]
Each file contains a header and three sections: classnames, types and data

====classnames====
The classnames section (<code>__classnames__</code> internally) contains a list of Havok classes used by the file to correctly decompile the binary data into a usable data structure.

====types====
The types section (<code>__types__</code> internally) does not appear to be used by ''Breath of the Wild''.

====data====
the data section (<code>__data__</code> internally) contains binary data to be serialized into Havok data structures for use by the Havok engine.

==Header==
The header seems to have a 16-byte alignment and can be 64-bytes (short header) or 80-bytes (long header) in length, depending on if '''Section offset''' equals 0 (short header) or 16 (long header).
{| class="wikitable"
|+
Header Specification
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|8
|Bytes
|Havok file signature (magic) <code>57 E0 E0 57 10 C0 C0 10</code>
|-
|<code>0x08</code>
|4
|Int
|User tag (always 0)
|-
|<code>0x0c</code>
|4
|Int
|Version (always 11)
|-
|<code>0x10</code>
|1
|Byte
|Pointer size (always 4 on Wii U, 8 on Switch)
|-
|<code>0x11</code>
|1
|Byte
|Endian (always 0 on WiiU, 1 on Switch)
|-
|<code>0x12</code>
|1
|Byte
|Padding option (always 0 on WiiU, 1 on Switch)
|-
|<code>0x13</code>
|1
|Byte
|Base class (always 1)
|-
|<code>0x14</code>
|4
|Int
|Section count (always 3)
|-
|<code>0x18</code>
|4
|Int
|Contents section index (always 2)
|-
|<code>0x1c</code>
|4
|Int
|Contents section offset (always 0)
|-
|<code>0x20</code>
|4
|Int
|Contents classname section index (always 0)
|-
|<code>0x24</code>
|4
|Int
|Contents classname section offset (always 75)
|-
|<code>0x28</code>
|16
|String
|Havok version <code>hk_2014.2.0-r1</code> for BotW files
|-
|<code>0x38</code>
|4
|Int
|Flags (always 0)
|-
|<code>0x3c</code>
|2
|Short
|Unknown (always 21)
|-
|<code>0x3e</code>
|2
|Short
|Section offset (0 or 16; if 16, the header is 16 bytes longer)
|}

===Optional Header Bytes===
There are optional header bytes for a long header. If Section offset equals 16, an additional 16 bytes are added to the header for a total of 80 bytes.
{| class="wikitable"
|+Optional Header Bytes
!Offset (h)
!Size
!Data Type
!Description
|-
|0x40
|4
|Int
|Unknown (always 20)
|-
|0x44
|4
|Int
|Unknown (always 0; probably padding for alignment)
|-
|0x48
|4
|Int
|Unknown (always 0; probably padding for alignment)
|-
|0x4c
|4
|Int
|Unknown (always 0; probably padding for alignment)
|}

==Section Headers==
[[File:Havok-class-header-delimits.png|thumb|<code>FF</code> bytes indicate section header boundaries]]
Each section has a 64-byte header which includes the section name, absolute offset to the section start and six relative offsets to segments within the section. These relative offsets are often relative to the absolute offset. {{check}} All three section headers follow the file header and are delimited by 16 delimiter bytes (<code>0xFF</code>).
{| class="wikitable"
|+Section Header Specification
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|20
|String
|Section name
|-
|<code>0x14</code>
|4
|Unsigned Int
|Absolute offset
|-
|<code>0x18</code>
|4
|Unsigned Int
|Relative offset 1
|-
|<code>0x1c</code>
|4
|Unsigned Int
|Relative offset 2
|-
|<code>0x20</code>
|4
|Unsigned Int
|Relative offset 3
|-
|<code>0x24</code>
|4
|Unsigned Int
|Relative offset 4
|-
|<code>0x28</code>
|4
|Unsigned Int
|Relative offset 5
|-
|<code>0x2c</code>
|4
|Unsigned Int
|Relative offset 6
|}

===Section Name===
There are only three section names: <code>__classnames__</code>, <code>__types__</code> and <code>__data__</code>. The section name is a null-terminated string with a delimiter byte (<code>0xFF</code>) in byte 20.

===Absolute Offset===
The absolute offset to the section.

===Relative Offsets===
The relative offsets point to different large structures within the section.

For example, given the following section header:
<syntaxhighlight>
5F 5F 64 61 74 61 5F 5F 00 00 00 00 00 00 00 00 | __data__........
00 00 00 FF 00 00 01 60 00 00 3C 00 00 00 3C 10 | .......`..<...<.
00 00 3C 10 00 00 3C 20 00 00 3C 20 00 00 3C 20 | ..<...< ..< ..<
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ................
</syntaxhighlight>The section name is <code>__data__</code>.

The absolute offset is the beginning of the data section, right after the class names.

This following tables shows to which sections the offsets are pointing:
{| class="wikitable"
|+Data Header Specification
!Offset (h)
!Size
!Data Type
!Description / Section
|-
|<code>0x00</code>
|20
|String
|Section name
|-
|<code>0x14</code>
|4
|Unsigned Int
|Beginning of data section
|-
|<code>0x18</code>
|4
|Unsigned Int
|Pointer - Data Pointer
|-
|<code>0x1c</code>
|4
|Unsigned Int
|Pointer - Linked Entries
|-
|<code>0x20</code>
|4
|Unsigned Int
|Pointer - Class Mapping
|-
|<code>0x24</code>
|4
|Unsigned Int
|EOF
|-
|<code>0x28</code>
|4
|Unsigned Int
|EOF
|-
|<code>0x2c</code>
|4
|Unsigned Int
|EOF
|}

==Class Names Section==
[[File:Havok-class-names.png|thumb|Class names binary data]]
The classnames section header includes the absolute offset to the class names data and a single unique relative offset to the end of the section. The section is made up of an array of hash ids and a null-terminated string class name.

===Class Name===
Class names are read until the end of the section or a delimiter byte (<code>0xFF</code>) is is reached.
{| class="wikitable"
|+Class Name Specification
!Offset (h)
!Size
!Type
!Description
|-
|0x00
|4
|Unsigned Int
|An integer associated with the class type
|-
|0x05
|1
|Byte
|Unknown (always <code>0x09</code>)<ref>It is assumed to be a delimiter between the id and the class name string. However, <code>0x09</code> is also the tab character and could imply something to the engine.</ref>
|-
|0x06
|n
|String
|Class name (null-terminated string)
|}

==Types Section==
The types section is unused in ''Breath of the Wild''. The absolute offset points to the beginning of the data section with all null (<code>0x00</code>) relative offsets.

==Data Section==
[[File:Havok-data-structure.png|thumb|390x390px|Data structure]]

===Data===
The bulk of the file is devoted to the data section which is divided into smaller segments dependent on the file type.
All files follow a general structure as you can see in the picture.

Right after the header begins the data section which contains multiple chunks, luckily, the first four chunks are always the same.

After that, several more chunks can be found depending on the file.

===Pointer===
The next section, at the end of the file, contains three different pointer arrays.
It is used to connect the whole file together, and should be used as an entry point while reading the file.

The offsets to these three sections can be found in the header.

====Data Pointer====
An array of offsets relative to the beginning of the data section, pointing into various chunks.

Which offsets ends up in this list, depends completely on the chunks used in the data section.

However, since the first four classes are always the same, the first 14 offsets will be the constant.
[[File:Havok_data_pointer.png|none|thumb|Data Pointer]]

====Linked Entries====
Contains pointer-pairs to connect chunks together.

Each pair has the following format:
{| class="wikitable"
|+Pointer Pair
!Offset (h)
!Size
!Type
!Name
!Description
|-
|0x00
|4
|Unsigned Int
|base
|Offset somewhere in the parent chunk
|-
|0x04
|4
|Unsigned Int
|flags
|Unknown (always <code>0x00000002)</code>
|-
|0x08
|4
|Unsigned Int
|target
|Target chunk (always beginning of the chunk)
|}
To connect a chunk with another, a base pointer somewhere inside the base-chunk (depending on the class/type) is used as the first pointer.

Then, the target pointer is the offset of the beginning of the target chunk.
[[File:Havok_pointer_linked.png|none|thumb|Linked Entries]]

====Class Mapping====
The last section contains the mapping between the chunks and the classes they are using.

They, again, use pointer pairs:
{| class="wikitable"
|+Class Mapping Pointer
!Offset (h)
!Size
!Type
!Name
!Description
|-
|0x00
|4
|Unsigned Int
|data
|Offset to the start of an chunk, relative to data-section
|-
|0x04
|4
|Unsigned Int
|flags
|Unknown (always <code>0x00000000)</code>
|-
|0x08
|4
|Unsigned Int
|class
|Offset to the class name, relative to class-section
|}
To link a chunk to a class, the data pointer is set to the beginning of the chunk.

The class pointer is set to the first character of the class name found in the header section.
[[File:Havok_class_mapping.png|none|thumb|Class Mapping]]

This also marks the end of the file, if the offset is not aligned to 16 bytes, the rest is filled with <code>0xFF</code>.

==Data Classes==
{{Expand section}}
All known classes that chunks can use are listed here.
{| class="wikitable"
|+Generally used classes
!Signature
!Name
|-
|0x2772c11e
|hkRootLevelContainer
|-
|}

{| class="wikitable"
|+Havok Animation classes
!Signature
!Name
|-
|0x26859f4c
|hkaAnimationContainer
|-
|0xfec1cedb
|hkaSkeleton
|-
|0xace9849c
|hkaSkeletonMapper
|-
|0x5448f464
|hkaRagdollInstance
|-
|}

{| class="wikitable"
|+Havok Physics classes
!Signature
!Name
|-
|0x47a8ca83
|hkpPhysicsData
|-
|0xb3cc6e64
|hkpPhysicsSystem
|-
|0xcd2e69e5
|hkpRigidBody
|-
|0xfda179f3
|hkpCapsuleShape
|-
|0xda4ce91e
|hkpConstraintInstance
|-
|0xed9648f7
|hkpRagdollConstraintData
|-
|0x75aae5a3
|hkpLimitedHingeConstraintData
|-
|0x143dd400
|hkpPositionConstraintMotor
|-
|0xabab6bb3
|hkpBvCompressedMeshShape
|-
|}

{| class="wikitable"
|+Havok Cloth classes
!Signature
!Name
|-
|0x3512912b
|hclClothContainer
|-
|0xf14068be
|hclCollidable
|-
|0xdd03f524
|hclCapsuleShape
|-
|0xd779f2c5
|hclSphereShape
|-
|0x92f3edba
|hclClothData
|-
|0xe6105187
|hclSimClothData
|-
|0x426b3354
|hclStandardLinkConstraintSet
|-
|0x426b3354
|hclStretchLinkConstraintSet
|-
|0x82567805
|hclLocalRangeConstraintSet
|-
|0x9cfe2c7d
|hclTransitionConstraintSet
|-
|0x26824757
|hclBendLinkConstraintSet
|-
|0x1b254ca1
|hclSimClothPose
|-
|0xa0130a2c
|hclScratchBufferDefinition
|-
|0x7f4a5bfc
|hclBufferDefinition
|-
|0x18fd4565
|hclTransformSetDefinition
|-
|0x6171b106
|hclObjectSpaceSkinPOperator
|-
|0xe65a701c
|hclMoveParticlesOperator
|-
|0x75c72f0f
|hclSimulateOperator
|-
|0x80d9769f
|hclSimpleMeshBoneDeformOperator
|-
|0xda737296
|hclGatherAllVerticesOperator
|-
|0x7b02cd1b
|hclClothState
|-
|0xe6db074c
|hclCopyVerticesOperator
|-
|}

{| class="wikitable"
|+Havok AI classes
!Signature
!Name
|-
|0x6d493bdb
|hkaiNavMesh
|-
|0x2f02d92c
|hkaiDirectedGraphExplicitCost
|-
|0x433a1e61
|hkaiStaticTreeNavMeshQueryMediator
|-
|}

{| class="wikitable"
|+Havok Compound classes
!Signature
!Name
|-
|0x99e8d0cb
|hkcdStaticAabbTree
|-
|0x33735476
|hkcdStaticTreeDefaultTreeStorage6
|-
|0x5115a202
|StaticCompoundInfo
|-
|}

<references />
[[Category:File formats]]

TSCB

2021-10-18T21:09:12Z

Greenlord: Material information header value should include itself

<onlyinclude>
'''T'''errain '''sc'''ene '''b'''inary (TSCB) files describe terrain areas layout and terrain materials.
</onlyinclude>

==TSCB File Specification==

===Header===
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|String
|TSCB file signature (magic) <code>54 53 43 42</code> or "TSCB"
|-
|<code>0x04</code>
|4
|Unsigned Int
|TSCB version? <code>0A 00 00 00</code> or "10.0.0.0"<ref>U-King.elf:0x024D2F8C-0x024D300A holds two error messages: "【データロード】メジャーバージョンの不一致" ("[Data load] Major version mismatch") and "【データロード】マイナーバージョンの不一致" ("[Data Load] Minor version mismatch")</ref><ref>Game crashes on load screen if not equal to <code>0A 00 00 00</code></ref>
|-
|<code>0x08</code>
|4
|Unsigned Int
|Unknown. Always <code>00 00 00 01</code>. Game crashes on load screen if not equal to <code>00 00 00 01</code>.
|-
|<code>0x0c</code>
|4
|Unsigned Int
|<code>file_base</code> table relative offset
|-
|<code>0x10</code>
|4
|Float
|<code>world_scale</code> <code>500.0</code>. Scales the terrain along the x- and z-axis.
|-
|<code>0x14</code>
|4
|Float
|Terrain mesh max height <code>800.0</code>. Used to calculate the actual vertex height with [[HGHT|hght]] data.
|-
|<code>0x18</code>
|4
|Unsigned Int
|<code>material_info_array</code> length (number of elements in the array)
|-
|<code>0x1c</code>
|4
|Unsigned Int
|<code>area_array</code> length (number of elements in the array)
|-
|<code>0x20</code>
|4
|Unsigned Int
|Probably padding
|-
|<code>0x24</code>
|4
|Unsigned Int
|Probably padding
|-
|<code>0x28</code>
|4
|Float
|<code>tile_size</code>. Used by the area array.
|-
|<code>0x2c</code>
|4
|Unsigned Int
|Unknown <code>00 00 00 08</code>. <ref>Values <code>1</code>, <code>2</code>, <code>4</code>, <code>5</code>, <code>6</code>, <code>8</code>, <code>9</code>, <code>10</code>, <code>13</code>, <code>14</code> affects textures. <code>0</code>, <code>3</code>, <code>7</code>, <code>11</code>, <code>12</code>, <code>15</code>, <code>16</code> will crash the game.</ref>
|}

==Material Information Array==
The material information array references texture data contained in <code>content/Model/Terrain.Tex1.sbfres</code>.

===Header===
The material information header is one value, the section size. This includes the index table and the value table, as well as itself.
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|Material info section size in bytes
|}

===Material Information Array Lookup Table===
Following the header is a table of relative offsets to each entry in <code>material_info_array</code>
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|Offset to array entry, relative to the first byte of this offset
|}

===Material Information Value Table===
Each entry in the array contains an index and four attributes
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|Array index (<code>mat_index</code>) of <code>material_info_array</code>
|-
|<code>0x04</code>
|4
|Float
|Texture u-axis (x-axis)
|-
|<code>0x08</code>
|4
|Float
|Texture v-axis (y-axis)
|-
|<code>0x0c</code>
|4
|Float
|Unknown. values range from 0-1.
|-
|<code>0x10</code>
|4
|Float
|Unknown. values range from 0.2-1.63
|}

==Area Array==

===Area Array Lookup Table===
Following the material information section is a table of relative offsets to each entry in area_array
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|Offset to array entry, relative to the first byte of this offset
|}

===Area Array Value Table===
Each entry contains meta data for one tile in the terrain scene. There are multiple levels of detail (lod) for the terrain.

Entry size ranges from <code>0x30</code> to <code>0x58</code> depending on the size of <code>extra_info_array</code>
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Float
|X Position
|-
|<code>0x04</code>
|4
|Float
|Z Position
|-
|<code>0x08</code>
|4
|Float
|<code>area_size</code> (length and width)
|-
|<code>0x0c</code>
|4
|Float
|Minimum Terrain Height - ranges from 0 to 1
|-
|<code>0x10</code>
|4
|Float
|Maximum Terrain Height - ranges from 0 to 1
|-
|<code>0x14</code>
|4
|Float
|Minimum Water Height - ranges from 0 to 1
|-
|<code>0x18</code>
|4
|Float
|Maximum Water Height - ranges from 0 to 1
|-
|<code>0x1c</code>
|4
|Unsigned Int
|Unknown. Usually <code>0</code>, <code>1</code> or <code>2</code>, crashes on <code>4</code>, <code>16</code>.<ref>May be a flag for grass and water? <code>0</code> seems to indicate no water or grass.</ref>
|-
|<code>0x20</code>
|4
|Unsigned Int
|<code>file_base</code>. Relative offset to file base name string.
|-
|<code>0x24</code>
|4
|Unsigned Int
|Unknown. Usually <code>0</code>.
|-
|<code>0x28</code>
|4
|Unsigned Int
|Unknown. Usually <code>0</code>.
|-
|<code>0x2c</code>
|4
|Unsigned Int
|<code>ref_extra</code>. It seems to be a flag to indicate if there is an attached <code>extra_info_array</code>
|}

====Parameters====
<code>x</code> - Area tile x coordinate (East-West)

<code>z</code> - Area tile z coordinate (North-South)
<code>area_size</code> - Determines the length and width of the area. It can be calculated with:<blockquote><code>(area_size / tile_size * world_scale) * 20</code></blockquote><code>tile_size</code> and <code>world_scale</code> are in the header.

===Extra Information Array===
if <code>ref_extra</code> does not equal <code>0</code> there is an <code>extra_info_array</code> attached to this area. The array is 4 or 8 values long.

Every area includes a [[HGHT|.hght]] and [[MATE|.mate]] file. The <code>extra_info_array</code> indicates if there is an additional [[Water.extm|.water.extm]] and / or [[Grass.extm|.grass.extm]] file

===Terrain and Water Height===
0x0c through 0x18 are used to determine what height range the terrain and water should render within. This is possibly used to assist with occlusion. If the heightmap moves outside of the range defined here, there will be visual artefacts present at higher viewing angles, usually between 45 and 90 degrees. The range value is multiplied by the max height defined in the TSCB header to determine the final value in 'real' co-ordinates.

====Header====
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|<code>0x00</code>
|4
|Unsigned Int
|extra_info_array length. Number of values (not elements) in array.
|-
|<code>(0x04)</code>
|4
|Unsigned Int
|Unknown. Always 20, but only present when extra_info_array length is 8.
|}

====Extra Information Array Value Table====
After the Header, there are <code>extra_info_array length / 4</code> elements of this structure.
{| class="wikitable"
!Offset (h)
!Size
!Data Type
!Description
|-
|0x00
|4
|Unsigned Int
|Unknown. Always 3.
|-
|0x04
|4
|Unsigned Int
|Unknown. 0 or 1.
|-
|0x08
|4
|Unsigned Int
|Unknown. Always 1.
|-
|0x0c
|4
|Unsigned Int
|Unknown. Always 0.
|}
[3, 0, 1, 0, 3, 1, 1, 0] = grass, water
[3, 1, 1, 0, 3, 0, 1, 0] = water, grass
[3, 1, 1, 0] = water
[3, 0, 1, 0] = grass
It seems that water is <code>[3, 1, 1]</code> and grass is <code>[3, 0, 1]</code>

==<code>stera</code> File Positions==
[[File:Stera_File_Positions.png|alt=stera File Positions|thumb|<code>stera</code> File Positions]]
<code>stera</code> files referenced in the area array are positioned using a [[wikipedia:Z-order_curve|z-order curve]] or the [[wikipedia:Moser–de_Bruijn_sequence|Moser-de Bruijn sequence]].
<references />
[[Category:File formats]]
[[Category:File extensions]]
[[Category:File extensions (STERA)]]

Map unit

2020-11-25T14:46:46Z

Greenlord: Some clarification for Pulse Linktags. (Footnote)

''Not to be confused with [[map]]s, [[Stage|stages]] or [[Scene|scenes]]''.

<onlyinclude>'''Map units''' contain placement data for game maps (e.g. MainField/A-1). In other words, they are used to configure fixed object spawns on maps for actors such as scenery and enemies for example, in contrast to the [[AutoPlacement]] system, which dynamically spawns actors.</onlyinclude>

== Types ==
Two types of map units exist: ''Static'' and ''Dynamic''.

'''Static map units''' are loaded during stage generation (see [[GameScene]] for more details). Their name is suffixed with <code>_Static</code>. They can contain both map rails and map objects; furthermore objects can be linked to each other to implement custom game logic using the [[#Link system]].

'''Dynamic map units''' are loaded and unloaded on-the-fly. Their name is suffixed with <code>_Dynamic</code>. The dynamic loading capability is only really put to good use for open-world type stages (e.g. MainField and AocField). In such map units, the link system cannot be used and only map objects can be specified.

== Contents ==

=== <code>LocationPosX</code> ===
X coordinate of the center of the map unit.

=== <code>LocationPosZ</code> ===
Y coordinate of the center of the map unit.

=== <code>LocationSize</code> ===
Size of the map unit (side length of the square).

=== <code>Objs</code> ===
{{expand section}}
Array of object structures. '''Must be sorted by HashId'''<ref>Technically, sorting is only required for Dynamic (non-group 0) map units. However, not sorting causes the game to fall back to a slower linear search.</ref> because the placement subsystem performs binary searches on the object array in various cases<ref>0x7101256E14</ref>.

=== <code>Rails</code> ===
{{expand section}}
Array of rail structures. Can only appear in group 0 maps (Static); this section is completely ignored for non-static map units.

== Link system ==
'''In static map units only''', map objects can be linked to other objects (up to 255 in a single generation group<ref>"一つの生成グループに 255 以上のアクタが指定されています。テストで無ければプログラマに相談"</ref>). These links allow implementing custom logic and callbacks. For example, DeadUp signals the destination object when the source object dies. This is used to implement enemy chests that only unlock after clearing an enemy camp.

LinkTags and other tag objects are lightweight actors that are used to link objects together.

Objects that are linked together, either directly or via indirect links, are put into the same '''generation group''' and loaded at the same time{{check}}. If the placement system fails to load an actor, the entire generation group is discarded.

===Definitions===
{{expand section}}
Cs means Constraint<ref>SliderCs links are handled by a function {{addr|a=0x7100F70D60|ver=nx-1.5.0}} that is also called by [[AIDef:Action/SwitchStepSliderConstraint]]</ref>.

{|class="wikitable sortable"
! ID !! Name !! Description !! Official description
|-
| 4 || -AxisX || - || マイナスX軸シグナル
|-
| 5 || -AxisY || - || マイナスY軸シグナル
|-
| 6 || -AxisZ || - || マイナスZ軸シグナル
|-
| 24 || AreaCol || Area collision (link target is an Area object) || エリア(センサ)指定
|-
| 1 || AxisX || - || X軸シグナル
|-
| 2 || AxisY || - || Y軸シグナル
|-
| 3 || AxisZ || - || Z軸シグナル
|-
| 37 || BAndSCs || Ball & Socket constraint || ボール＆ソケットCS
|-
| 38 || BAndSLimitAngYCs || Y angular velocity limited Ball & Socket constraint || Y角速度制限付ボール＆ソケットCS
|-
| 0 || BasicSig || Basic signal || 基本シグナル
|-
| 9 || BasicSigOnOnly || Basic signal [only emits ON signals] || オンのみ基本シグナル
|-
| 14 || ChangeAtnSig || Signal on Attention change (e.g. picking up a weapon) || アテンション変更時シグナル
|-
| 39 || CogWheelCs || Gear/cogwheel constraint || 歯車CS
|-
| 21 || CopyWaitRevival || Activate links when the revival flag of the CopyWaitRevival target is set (e.g. can be used with LinkTagAnd to trigger basic signals when a chest is opened) || 配置自動セーブ継承
|-
| 15 || Create || Create a map object. Target objects are not created unless this link is activated. || 生成
|-
| 11 || DeadUp || Signal on death || 死んだらオン
|-
| 16 || Delete || Delete a map object. Target objects are created and stay spawned until this link is activated. Note: the corresponding collision is disabled even for objects that have their collision data extracted to separate Static Compound files. || 削除
|-
| 29 || DemoMember || - || デモ参加
|-
| 32 || FixedCs || - || 固定CS
|-
| 26 || ForSale || Links a shop item to its seller (target is the seller NPC). || 売り物
|-
| 19 || ForbidAttention || Prevent attention (i.e. interacting with an object, for example picking up a weapon) || アテンションタイプ変更
|-
| 18 || Freeze || Freeze the target object || 凍結
|-
| 7 || GimmickSuccess || Success signal (used for minigames) || ネタ成功シグナル
|-
| 33 || HingeCs || Hinge constraint || ヒンジCS
|-
| 12 || LifeZero || Emit a LifeZero signal when the life of the source object is 0 || ライフ0
|-
| 34 || LimitHingeCs || Limited hinge constraint || 制限付ヒンジCS
|-
| 27 || ModelBind || - || モデルバインド
|-
| 17 || MtxCopyCreate || - || 位置継承生成
|-
| 22 || OffWaitRevival || Reset the revival flag of the target object || 配置自動セーブオフ
|-
| 30 || PhysSystemGroup || - || 物理システムグループ
|-
| 28 || PlacementLOD || Replace the source object with the link target object at lower level of details || 配置LOD
|-
| 36 || PulleyCs || - || 滑車CS
|-
| 40 || RackAndPinionCs || Rack-and-pinion constraint || ラック＆ピニオンCS
|-
| 23 || Recreate || Recreates the target object || 再生成
|-
| 41 || Reference || - || 参照
|-
| 10 || Remains || Divine Beast signal || 遺物シグナル
|-
| 25 || SensorBind || - || センサバインド
|-
| 35 || SliderCs || Slider constraint || スライダーCS
|-
| 13 || Stable || - || 安定
|-
| 31 || StackLink || - || スタック
|-
| 20 || SyncLink || Put the destination object and any object that is linked to it into the same generation group || 生成グループ
|-
| 8 || VelocityControl || Velocity control signal || 速度制御シグナル
|-
|}

=== Link tags ===
''Not to be confused with [[actor tag]]s.''

LinkTagAnd, LinkTagOr, LinkTagNAnd, LinkTagNOr, LinkTagXOr, LinkTagCount, LinkTagPulse, LinkTagNone are small objects that are used to implement a basic logic system in map units.

AND, OR, NAND, NOR, XOR LinkTags are logical operators. They can be used to conditionally set or clear GameData flags, or conditionally spawn objects, trigger other objects, etc. A basic signal is emitted when the LinkTag has been triggered by ''all'' of the source links (for LinkTagAnds) or by one of them (for LinkTagOrs), etc.

Count LinkTags are used to increment a GameData flag every time the link tag itself is signalled.

Pulse LinkTags continuously emit a basic signal with a configurable signal duration (PulseLength)<ref>This appears to require a BasicSig input and does not repeat automatically. In order to get this behavior, fire it with a SwitchTimer.</ref>.

None LinkTags have no effect. They are only used to put different map unit objects into the same placement generation group.

Internally, they are all implemented by the same actor class (<code>LinkTag</code>) since they share most of their core functionality, with only small differences in effects. A single link tag can only handle 0x60 incoming links<ref>0x7100D388C4</ref>. Only incoming links with defType <= 0xe are processed<ref>0x7100D389DC</ref>; other links are ignored.

Parameters are documented in [[AIDef:Action/LinkTagBaseAction#MapUnitInstParams]].

== File formats ==

=== Map unit binary ===
In ''Breath of the Wild'', map units are stored in a binary format and given the ''mubin'' (Map Unit Binary) file extension. All map object IDs are replaced with CRC32 hashes as a space optimisation. [[BYML]] is used as the serialisation format.

Map units can be found in the [[Content/Map|Map]] content directory, and use the following naming convention: <code>Map/%s/%s/%s%s.mubin</code> (map type, map name, map name, suffix).

Despite the file extension, <code>Map/%s/Location.mubin</code> and <code>Map/%s/LazyTraverseList.mubin</code> are not actually map units.

=== Source map unit ===
Source map units have muunt<ref>The executable has remnants of error logging functions that print paths to development map units of the following type: <code>Map/Project/%s/Data/%s/%s.muunt</code></ref> as their file extension and use strings for map object IDs such as <code>F-5_challenge.muunt/obj760</code> instead of CRC32 hashes of the IDs in map unit binaries.
[[Category:Internals]]
<references />
[[Category:File formats]]