39
edits
LEB: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
'''LEB''' is a custom format used to store room data in Link's Awakening. | '''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. | ||
Note that many properties in these files define measurements in 3D space; since Link's Awakening is a top-down game we will call the vertical axis Z (i.e. the axis perpendicular to the plane of the floor), and X and Y will be as normal for a 2D game. | |||
==Format== | ==Format== | ||
| Line 72: | Line 72: | ||
====Version Section==== | ====Version Section==== | ||
Holds 3 bytes of data, which seem to always be 0x1001D4. Given the name, it's probably just a version marker and has no functional purpose. | |||
====Infomation Section==== | ====Infomation Section==== | ||
Holds 4 bytes of data. The purpose of this is unknown. | |||
====Point Section==== | ====Point Section==== | ||
This is a FixedHash child. It | This is a FixedHash child. It defines relevant co-ordinate points for actors in the room to use. Examples of this include points which actors can force Link to walk to during events, where a seashell should land from bonking a tree, and more. | ||
There is one entry per point. Points have data blocks of 0x18 bytes each. This block consists of 3 floats (4 bytes each) representing the (X, Z, Y) of the point. It appears that this is always followed by 0xC bytes of FF to fill out the block, but the reason for this is not known. | |||
=====Rail Section===== | =====Rail Section===== | ||
This is another FixedHash child | This is another FixedHash child. The exact purpose of this section is not understand but it seems to work in conjunction with <code>point</code>. There is one entry per rail. | ||
Each rail has a data block of variable size, typically 0x32 or more bytes. | |||
{| class="wikitable" | |||
|+ | |||
!Offset | |||
!Type | |||
!Description | |||
|- | |||
|0x0 | |||
| | |||
|Appears to always be 0xC null bytes? | |||
|- | |||
|0xC | |||
| | |||
|Block of 4 structures with a parameter-like structure (see actor section) except for using 0xFFFFFF04 instead of 0x4. So far only observed to be blocks of [0x19, 0xFFFFFF04]. | |||
|- | |||
|0x2C | |||
|u16 | |||
|Number of entries in following list | |||
|- | |||
|0x2E | |||
|u16 | |||
|Number of indexes per entry? Only observed to ever be 0x01 so far, so no clear purpose. | |||
|- | |||
|0x30 | |||
|u16[...] | |||
|Indexes of points used per rail (in the <code>point</code> section). The logic behind how points are grouped into rails is not understood, but always seems to line up with how actors reference points. So, an actor that refers to (rail 0, point 0) and (rail 0, point 1) means that rail 0 references points 0 and 1. An actor referring only to (rail 2, point 2) and nothing else with rail 2 means that rail 2 only references point 2. | |||
|} | |||
====Actor Section==== | ====Actor Section==== | ||
This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, a block with a minimum size of 0x90 bytes, but can be longer. The names section is empty. The data block for each actor is formatted as follows | This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, a block with a minimum size of 0x90 bytes, but can be longer. The names section is empty. The data block for each actor is formatted as follows. | ||
{| class="wikitable" | {| class="wikitable" | ||
|+ | |+ | ||
| Line 182: | Line 208: | ||
'''Section 2''' | '''Section 2''' defines a list of points the actor knows about. It consists of a sequence of 24-byte structures, which are each 2 parameters (8 bytes each), and 2 u32's, which respectively index into the <code>rail</code> section and the <code>point</code> section. This is used for various things, for example the Link:MoveToTargetLinkedPoint event action, or the location for item drops from the actor to land, or the location to dynamically spawn other actors (e.g. pickups in rapids rush). | ||
| Line 204: | Line 230: | ||
|0x4 | |0x4 | ||
|u32? | |u32? | ||
|Unknown, seems to always be identical to the | |Unknown, seems to always be identical to the 4 bytes starting at 0x0. | ||
|- | |- | ||
|0x8 | |0x8 | ||
| Line 216: | Line 242: | ||
The chain section is used for when there needs to be a higher walkable surface directly above a lower one. This is common in sidescroller rooms, but is also used in some overworld areas; mainly in Tal Tal Mountains where there are some walkable surfaces inside cliff faces which can be reached with out of bounds methods. Chain entries can still index to other chains. | The chain section is used for when there needs to be a higher walkable surface directly above a lower one. This is common in sidescroller rooms, but is also used in some overworld areas; mainly in Tal Tal Mountains where there are some walkable surfaces inside cliff faces which can be reached with out of bounds methods. Chain entries can still index to other chains. The data is stored in the same structures as the <code>data</code> section. | ||