LEB

Revision as of 03:59, 6 June 2021 by Glan (talk | contribs) (→‎Actor Data Section: added ending code)

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 Lv7EagleTower_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 Next entry offset
0xFFF0 Offset of versionin the names section 0xFFFFFFFF
0xFFF0 Offset of informationin the names section 0xFFFFFFFF
0x0 Offset of pointin the names section 0xFFFFFFFF
0x1 Offset of railin the names section 0xFFFFFFFF
0x2 Offset of actorin the names section 0x10
0x3 Offset of gridin the names section 0xFFFFFFFF

The Name Hashes of each should not be touched. The purpose of the DataOffsets is still unknown.

Data Section

The data section contains nine subsections. Only some of these have a known purpose so far.

Section 1

Appears to always consist of 0x2C bytes.

Offset Type Description
0x0 u64 Always 0x4
0x8-0xF Unknown
0x10 u64 Always 0x3
0x18 Unknown
0x20 Remaining bytes from here are always 3D 01 01 00 00 00 00 FF FF FF FF FF. Probably a termination marker.

Section 2

Unknown purpose. Always ends in 3D 01 01 00 00 00 00 FF FF FF FF FF.

Section 3

Unknown purpose. Always ends in 3D 01 01 00 00 00 00 FF FF FF FF FF.

Actor Entries Section

This section is preceded by a u64 which specifies the length of the section in bytes.

This section holds a list of entry-like data, 16 bytes for each actor, which look like:

F0 FF 00 00 00 00 00 00 FF FF FF FF xx xx xx xx

Where the last 4 bytes store the offset of each actor's data block in the actor data section.

Actor Entry Offsets Section

Similar to the regular FixedHash entry offsets section, but corresponding to the previous section (Actor Entries)

Actor Data Section

This section starts is preceded by a u64 which specifies the number of bytes the actor data section takes. The section contains blocks of data for each actor in the room. Usually these are 0x98 bytes but for some actors are longer, and in the following format:

Offset Type Description
0x0 u64 Group. For most actors, this will be 0x90, but in some cases it will be different. For example, rooms with Three-of-a-Kind enemies have 0xC4 for those enemies. Does not seem to functionally matter in most cases.
0x8 u64 Actor key. This value must match the hex value of the corresponding actor label in the names section.
0x10 u32 Names section offset. This stores the offset in the names section for the start of the label that corresponds to this actor.
0x14 u16 Actor ID
0x16 u16 Padding?
0x18 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.
0x1C 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
0x20 u32 Appears to be Z coordinate (height). However it scales very strangely, maybe not linear?
0x24 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
0x28-0x3F Unknown.
0x40 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.

0x40 + N*0x8 Unknown.

Following all of these data blocks, the section ends with 00 00 00 00 3D 01 02 00 00 00 00 FF FF FF FF FF.

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.

Section 7

Unknown purpose. Usually short (16 bytes), but sometimes longer.

Section 8

Another section filled with entry-like data. The purpose of it is still unknown.

Section 9

Preceded by a u32 specifying the length of this section. Contains a few strings in plain ASCII, usually data and info. The purpose of this 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).