LEB

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:

3d01 1700 0400 0000 ffff ffff 0000 0000

2000 0000 ffff ffff ffff ffff ffff ffff

ffff ffff ffff ffff 4000 0000 ffff ffff

ffff ffff 5000 0000 ffff ffff 3000 0000

ffff ffff ffff ffff ffff ffff ffff ffff

ffff ffff ffff ffff ffff ffff ffff ffff

ffff ffff

Entries Section

There are 6 entries in most LEB files.

Node Index	Name Offset	Name Hash	Next entry offset	Data Offset
0xFFF0	Offset of versionin the names section	Hash of version	0xFFFFFFFF	Offset to version section
0xFFF0	Offset of infomationin the names section [sic]	Hash of infomation	0xFFFFFFFF	Offset to infomation
0x0	Offset of pointin the names section	Hash of point	0xFFFFFFFF	Offset to point section
0x1	Offset of railin the names section	Hash of rail	0xFFFFFFFF	Offset to rail section
0x2	Offset of actorin the names section	Hash of actor	0x10	Offset to actor section
0x3	Offset of gridin the names section	Hash of grid	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:

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	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[N]	Parameters. This section contains multiple u32's, which appear to be grouped into pairs of [parameter, parameter type]. For most actors, there are 8 parameters (and so this section is 64 bytes long). 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? 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.
0x38 + N*0x8		Exact formatting is still unknown, but in this section it lists the indices of game flags that this actor looks at. e.g. whether a chest is open, whether a door is open, whether a small key has fallen, etc.

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: data and info. 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 point and rail at the start of the names section, or between the 1st and 2nd listed actors (it is more commonly the latter).