'''LEB''' is a custom format used to store room data in Link's Awakening.

This format is still in the process of being reverse engineered and so this page is currently incomplete.

==Format==
'''LEB''' files are in a [[FixedHash]] format, with the data for actors stored in the data section and the names section. There is consistency in how the FixedHash is built for '''LEB''' files, with the exception of Lv07EagleTower_05E (the lower part of the Eagle boss room), which for some reason is different than all other rooms. Aside from this room, LEBs always have 0x17 hash table buckets and 0x4 child FixedHash nodes. The buckets are always the same, so the start of LEB files always look like:

<code>3d01 1700 0400 0000 ffff ffff 0000 0000</code>

<code>2000 0000 ffff ffff ffff ffff ffff ffff</code>

<code>ffff ffff ffff ffff 4000 0000 ffff ffff</code>

<code>ffff ffff 5000 0000 ffff ffff 3000 0000</code>

<code>ffff ffff ffff ffff ffff ffff ffff ffff</code>

<code>ffff ffff ffff ffff ffff ffff ffff ffff</code>

<code>ffff ffff</code>

===Entries Section===
There are 6 entries in most LEB files.
{| class="wikitable"
|+
!Node Index
!Name Offset
!Name Hash
!Next entry offset
!Data Offset
|-
|0xFFF0
|Offset of <code>version</code>in the names section
|Hash of <code>version</code>
|0xFFFFFFFF
|Offset to version section
|-
|0xFFF0
|Offset of <code>infomation</code>in the names section [sic]
|Hash of <code>infomation</code>
|0xFFFFFFFF
|Offset to infomation
|-
|0x0
|Offset of <code>point</code>in the names section
|Hash of <code>point</code>
|0xFFFFFFFF
|Offset to point section
|-
|0x1
|Offset of <code>rail</code>in the names section
|Hash of <code>rail</code>
|0xFFFFFFFF
|Offset to rail section
|-
|0x2
|Offset of <code>actor</code>in the names section
|Hash of <code>actor</code>
|0x10
|Offset to actor section
|-
|0x3
|Offset of <code>grid</code>in the names section
|Hash of <code>grid</code>
|0xFFFFFFFF
|Offset to grid secion
|}
 

===Data Section===
The data section contains one subsection for each entry (usually six).

====Version Section====
This section holds a u64 with the value 0x3 (specifying 3 bytes of data), followed by the 3 bytes of data, which seem to always be 0x1001D4. Whether it has a purpose is unclear. Given the name, it could just be a version marker. Following this is five empty bytes.
====Infomation Section====
This section holds a u64 with the value 0x4 (specifying 4 bytes of data), followed by the 4 bytes of data. Its purpose is unknown. Following this is four empty bytes.
====Point Section====
This is a FixedHash child. It's usually empty and has 1 bucket and no child nodes. The names section is empty. Purpose unknown.

An example of a room which has a non-empty FixedHash here is Lv01TailCave_04G (Moldorm boss room).

=====Rail Section=====
This is another FixedHash child. Usually it's empty and has 1 bucket and no child nodes. The names section is empty. Purpose unknown.

An example of a room which has a non-empty FixedHash here is Lv01TailCave_04G (Moldorm boss room).

====Actor Section====
This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, usually blocks of 0x90 bytes, but sometimes longer. The names section is empty. The data block for each actor is formatted as follows:
{| class="wikitable"
|+
!Offset
!Type
!Description
|-
|0x0
|u64
|'''Actor key'''. This value must match the hex value of the corresponding actor label in the names section.
|-
|0x8
|u32
|'''Names section offset'''. This stores the offset in the names section for the start of the label that corresponds to this actor.
|-
|0xC
|u16
|[[Actors|'''Actor ID''']]
|-
|0xE
|u16
|Padding?
|-
|0x10
|u32
|'''Room ID'''. The actor loads when entering the specified room and unloads when leaving it. Generally this should be consistent across all actors in the file, since each room has its own file.
|-
|0x14
|u32
|'''X coordinate'''. One “tile” is 0xC0000 units, so using the lower 2 bytes here is going to generally be pretty insignificant. Hence them usually being 0
|-
|0x18
|u32
|Appears to be Z coordinate (height). However it scales very strangely, maybe not linear?
|-
|0x1C
|u32
|'''Y coordinate'''. One “tile” is 0xC0000 units, so using the lower 2 bytes here is going to generally be pretty insignificant. Hence them usually being 0
|-
|0x20-0x37
|
|Unknown.
|-
|0x38
|u32[16]
|'''Parameters'''. This section contains 16 u32's, which are grouped into 8 pairs of [parameter, parameter type].
For any pair, the first 4 bytes make up the value of the parameter. This can be basically anything (will include some known parameters for certain actor types below).

The second 4 bytes indicate what the purpose of the parameter is. There are only 3 observed values so far:

*0x0, which indicates the parameter is not used?
*0x2, unknown purpose. Observable on the small key in Lv04AnglersTunnel_06A, but the parameters appear to not do anything.
*0x3, which indicates that the parameter is a direct parameter. e.g., the parameter 0x1 is used to indicate being able to push a block actor.
*0x4, which indicates that the parameter is a plaintext parameter specified in the names section. The value in the previous u32 is the offset in the names section for this parameter.

Most actors have "blank " parameters filled in as offsets to the 2nd null byte after the first label in the names section; however, this seems to be functionally equivalent to leaving the parameter as 0.
|-
|0x78
|
|'''Actor Switches'''. Defines 4 actor switches for the event. These are used for the spawn behavior of many things like small keys, chests, NPCs, loading zones, etc.

First there is 4 bytes which define the usage of actor switches 0-3 respectively:

*0: uncertain purpose. Observable on dungeon torches (ObjDungeonFaceLamp)
*1: The actor switch is the index of a global flag.
*2: Defines a hardcoded value for the switch, usually 1. For example, while some treasure chests appear based on a global flag being set, some don't; these ones would just use this hardcoded 1 instead of a flag index.
*3: Used only on actors in panel dungeon rooms. Appears to be an index for a flag system specific to panel dungeons.
*4: The switch is unused.

Following this are the four actor switch definitions, each 2 bytes (u16).
|-
|0x84
|
|'''Unknown'''.
|-
|0x90
|
|For actors that are longer than 0x90 bytes, this section is used for more data. The purpose so far is not clear, but often seems to be similar in structure to the parameters section.
|}
=====Notes on Parameters for Specific Actors=====
'''ObjCaveRock:''' (and other blocks?), the first four parameters correspond to whether you can push them in a certain direction, ordered as RIGHT, LEFT, DOWN, UP. 0x0 is not pushable in that direction, 0x1 is pushable.

====Grid Section====
Another child FixedHash. It has a name section which usually contains two strings: <code>data</code> and <code>info</code>. Some have other strings in between, such as Lv08TurtleRock_01H (right half of the sidescroller leading to the boss). This FixedHash has one Entry for each of these strings in the names section. Each entry holds a block of data. The purpose of this is still unknown. The final entry seems to always have a data block of 0x10 bytes.

The purpose of this section is unknown.

===Names Section===
The names section contains a list of actors by name, followed by a hyphen (-), followed by a 16-digit hexadecimal number. This also includes some plaintext parameters for some objects, such as the contents of a chest (ObjTreasureBox) or the destination of a loading zone (AreaLevelOpen). Note that these do not define what actors exist, in fact it seems like the actual labels here are meaningless aside from the aforementioned parameters.

All labels in the names section are separated by null bytes. Of note, there seems to always be one separator that 2 null bytes instead of 1. Depending on the file, this is either between <code>point</code> and <code>rail</code> at the start of the names section, or between the 1st and 2nd listed actors (it is more commonly the latter).
[[Category:File formats]]

LEB

2021-10-30T08:54:49Z

Glan: /* Actor Section */

LEB

2021-10-30T07:29:10Z

Glan: /* Actor Section */

LEB

2021-10-30T01:19:03Z

Glan:

LEB

2021-10-22T04:22:34Z

Glan: /* Actor Section */

'''LEB''' is a custom format used to store room data in Link's Awakening.

This format is still in the process of being reverse engineered and so this page is currently incomplete.

==Format==
'''LEB''' files are in a [[FixedHash]] format, with the data for actors stored in the data section and the names section. There is consistency in how the FixedHash is built for '''LEB''' files, with the exception of Lv07EagleTower_05E (the lower part of the Eagle boss room), which for some reason is different than all other rooms. Aside from this room, LEBs always have 0x17 hash table buckets and 0x4 child FixedHash nodes. The buckets are always the same, so the start of LEB files always look like:

<code>3d01 1700 0400 0000 ffff ffff 0000 0000</code>

<code>2000 0000 ffff ffff ffff ffff ffff ffff</code>

<code>ffff ffff ffff ffff 4000 0000 ffff ffff</code>

<code>ffff ffff 5000 0000 ffff ffff 3000 0000</code>

<code>ffff ffff ffff ffff ffff ffff ffff ffff</code>

<code>ffff ffff ffff ffff ffff ffff ffff ffff</code>

<code>ffff ffff</code>

===Entries Section===
There are 6 entries in most LEB files.
{| class="wikitable"
|+
!Node Index
!Name Offset
!Name Hash
!Next entry offset
!Data Offset
|-
|0xFFF0
|Offset of <code>version</code>in the names section
|Hash of <code>version</code>
|0xFFFFFFFF
|Offset to version section
|-
|0xFFF0
|Offset of <code>infomation</code>in the names section [sic]
|Hash of <code>infomation</code>
|0xFFFFFFFF
|Offset to infomation
|-
|0x0
|Offset of <code>point</code>in the names section
|Hash of <code>point</code>
|0xFFFFFFFF
|Offset to point section
|-
|0x1
|Offset of <code>rail</code>in the names section
|Hash of <code>rail</code>
|0xFFFFFFFF
|Offset to rail section
|-
|0x2
|Offset of <code>actor</code>in the names section
|Hash of <code>actor</code>
|0x10
|Offset to actor section
|-
|0x3
|Offset of <code>grid</code>in the names section
|Hash of <code>grid</code>
|0xFFFFFFFF
|Offset to grid secion
|}
 

===Data Section===
The data section contains one subsection for each entry (usually six).

====Version Section====
This section holds a u64 with the value 0x3 (specifying 3 bytes of data), followed by the 3 bytes of data, which seem to always be 0x1001D4. Whether it has a purpose is unclear. Given the name, it could just be a version marker. Following this is five empty bytes.
====Infomation Section====
This section holds a u64 with the value 0x4 (specifying 4 bytes of data), followed by the 4 bytes of data. Its purpose is unknown. Following this is four empty bytes.
====Point Section====
This is a FixedHash child. It's usually empty and has 1 bucket and no child nodes. The names section is empty. Purpose unknown.

An example of a room which has a non-empty FixedHash here is Lv01TailCave_04G (Moldorm boss room).

=====Rail Section=====
This is another FixedHash child. Usually it's empty and has 1 bucket and no child nodes. The names section is empty. Purpose unknown.

An example of a room which has a non-empty FixedHash here is Lv01TailCave_04G (Moldorm boss room).

====Actor Section====
This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, usually blocks of 0x90 bytes, but sometimes longer. The names section is empty. The data block for each actor is formatted as follows:
{| class="wikitable"
|+
!Offset
!Type
!Description
|-
|0x0
|u64
|'''Actor key'''. This value must match the hex value of the corresponding actor label in the names section.
|-
|0x8
|u32
|'''Names section offset'''. This stores the offset in the names section for the start of the label that corresponds to this actor.
|-
|0xC
|u16
|[[Actors|'''Actor ID''']]
|-
|0xE
|u16
|Padding?
|-
|0x10
|u32
|'''Room ID'''. The actor loads when entering the specified room and unloads when leaving it. Generally this should be consistent across all actors in the file, since each room has its own file.
|-
|0x14
|u32
|'''X coordinate'''. One “tile” is 0xC0000 units, so using the lower 2 bytes here is going to generally be pretty insignificant. Hence them usually being 0
|-
|0x18
|u32
|Appears to be Z coordinate (height). However it scales very strangely, maybe not linear?
|-
|0x1C
|u32
|'''Y coordinate'''. One “tile” is 0xC0000 units, so using the lower 2 bytes here is going to generally be pretty insignificant. Hence them usually being 0
|-
|0x20-0x37
|
|Unknown.
|-
|0x38
|u32[16]
|'''Parameters'''. This section contains 16 u32's, which are grouped into 8 pairs of [parameter, parameter type].
For any pair, the first 4 bytes make up the value of the parameter. This can be basically anything (will include some known parameters for certain actor types below).

The second 4 bytes indicate what the purpose of the parameter is. There are only 3 observed values so far:

*0x0, which indicates the parameter is not used?
*0x2, unknown purpose. Observable on the small key in Lv04AnglersTunnel_06A, but the parameters appear to not do anything.
*0x3, which indicates that the parameter is a direct parameter. e.g., the parameter 0x1 is used to indicate being able to push a block actor.
*0x4, which indicates that the parameter is a plaintext parameter specified in the names section. The value in the previous u32 is the offset in the names section for this parameter.

Most actors have "blank " parameters filled in as offsets to the 2nd null byte after the first label in the names section; however, this seems to be functionally equivalent to leaving the parameter as 0.
|-
|0x78
|
|'''Control section.''' Used to define actor-specific behavior, including actors which appear from switches, enemy kill tags, etc., as well actors which use flags to mark a state, e.g. whether you've picked it up yet or not.
Every value in this section is a u16.

Actors affected by these (e.g. a chest that appears after killing enemies, or a door that opens when pressing a switch) have the value 0x0101.

Actors which control this behavior (e.g. the switch, enemy kill tag, etc.) have the value 0x0201.

Actors not intended to be a part of this behavior omit this value. Other values have been observed here but aren't yet understood. (e.g. 0x0202)

The value 0x0401 here indicates conditional spawning based on the value of a flag. If the flag at the specified index (specified a few values later) is not set, this actor will not exist in the game world.

Following this value, or immediately after the parameters if it hasn't been used, holds the value 0x0404.

Following that is a list of game flag indices.

Listed first, if applicable, is the flag for whether the actor has been made to appear (for falling keys/spawn chests).

Next, if applicable, is the flag for whether the actor has been picked up/opened (for fallen keys, chests, doors, etc).

The rest of the section will be 0 if not used.
|}
=====Notes on Parameters for Specific Actors=====
'''ObjCaveRock:''' (and other blocks?), the first four parameters correspond to whether you can push them in a certain direction, ordered as RIGHT, LEFT, DOWN, UP. 0x0 is not pushable in that direction, 0x1 is pushable.

====Grid Section====
Another child FixedHash. It has a name section which usually contains two strings: <code>data</code> and <code>info</code>. Some have other strings in between, such as Lv08TurtleRock_01H (right half of the sidescroller leading to the boss). This FixedHash has one Entry for each of these strings in the names section. Each entry holds a block of data. The purpose of this is still unknown. The final entry seems to always have a data block of 0x10 bytes.

The purpose of this section is unknown.

===Names Section===
The names section contains a list of actors by name, followed by a hyphen (-), followed by a 16-digit hexadecimal number. This also includes some plaintext parameters for some objects, such as the contents of a chest (ObjTreasureBox) or the destination of a loading zone (AreaLevelOpen). Note that these do not define what actors exist, in fact it seems like the actual labels here are meaningless aside from the aforementioned parameters.

All labels in the names section are separated by null bytes. Of note, there seems to always be one separator that 2 null bytes instead of 1. Depending on the file, this is either between <code>point</code> and <code>rail</code> at the start of the names section, or between the 1st and 2nd listed actors (it is more commonly the latter).
[[Category:File formats]]

LEB

LEB

2021-06-03T01:36:01Z

Glan: formatting

LEB

2021-06-03T01:34:36Z

Glan: Created page