39
edits
LEB: Difference between revisions
Jump to navigation
Jump to search
→Grid Section: expanded info on grid data
No edit summary |
(→Grid Section: expanded info on grid data) |
||
| Line 1: | Line 1: | ||
'''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. | '''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 | Note that many properties in these files define measurements in 3D space (X, Y, Z). X is horizontal across the screen, Y is perpendicular to the ground (the axis on which gravity acts), and Z is vertical across the screen. | ||
==Format== | ==Format== | ||
| Line 78: | Line 78: | ||
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. | 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 | 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, Y, Z) 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===== | ||
| Line 141: | Line 141: | ||
|0x14 | |0x14 | ||
|float[3] | |float[3] | ||
|'''Co-ordinates''' as [X, Z | |'''Co-ordinates''' as [X, Y, Z]. One in-game "tile" is 1.5 units. | ||
The co-ordinate system spans entire maps and is not specific to each room. [0, 0, 0] is the very top left corner of the map, at the elevation of the main floor plane of the map. | The co-ordinate system spans entire maps and is not specific to each room. [0, 0, 0] is the very top left corner of the map, at the elevation of the main floor plane of the map. | ||
Each room is 10x8 tiles, so they span 15 units along the X axis and 12 along the | Each room is 10x8 tiles, so they span 15 units along the X axis and 12 along the Z axis. | ||
|- | |- | ||
|0x20 | |0x20 | ||
|float[3] | |float[3] | ||
|'''Rotation''' about the [X, Z | |'''Rotation''' about the [X, Y, Z] axes respectively, in degrees. | ||
|- | |- | ||
|0x2C | |0x2C | ||
|float[3] | |float[3] | ||
|'''Scaling''' along the [X, Z | |'''Scaling''' along the [X, Y, Z] axes respectively. Note that scaling doesn't seem to affect collision for every actor and only scales the model in some cases. | ||
|- | |- | ||
|0x38 | |0x38 | ||
| Line 214: | Line 214: | ||
|} | |} | ||
====Grid Section==== | ====Grid Section==== | ||
This section is a child FixedHash which appears to define | This section is a child FixedHash which appears to define properties for each tile of the room. It has two or three entries: <code>data</code>, sometimes <code>chain</code>, and <code>info</code>. | ||
| Line 225: | Line 225: | ||
|- | |- | ||
|0x0 | |0x0 | ||
| | |bit field | ||
|The 4 bytes here seem to make up a bit field with a number of flags defining various tile properties. | |||
The first two bytes are set in a pattern that is consistent with the terrain collision of the room, but editing it does not seem to have any actual effect on the collision of the room. Will require more testing. | |||
Byte 1 (bits 76543210): | |||
7: indicates that there is solid collision to the south of this tile | |||
6: unused? | |||
5: indicates that there is solid collision to the east of this tile | |||
4: unused? | |||
3: indicates there is solid collision to the north of this tile | |||
2: unused? | |||
1: indicates that this tile contains solid collision | |||
0: indicates that the tile is deep water or lava (as opposed to shallow) | |||
Byte 2: | |||
7-2: unused? | |||
1: indicates that there is collision to the west of this tile | |||
0: unused? | |||
Note that in considering if there is collision next to a tile, it doesn't consider adjacent rooms. Tiles at the edge of a room will not "see" any collision past that edge. | |||
Byte 3: | |||
7: Appears to always be 0 | |||
6: Unknown. Set for the vast majority of tiles, but unset in a few specific cases. This is observable in overworld screens around the graveyard, and the bottom left of Signpost Maze (where the stairs to Mamu are). | |||
5: Appears to indicate whether the tile is allowed to "refresh its state" when you move away from the room. Most tiles have this bit set. This bit is set to 0 for every tile which contains a seashell under a rock, bush, or dig spot, and also the tile of the Slime Key (also a dig spot). Something these tiles have in common is being able to retain the state of the item on the ground for longer than other tiles' states (e.g. simple grass being cut). Oddly, every walkable tile in Lv1TailCave_04B (the spike turtle room) does not have this bit set, which differs from literally every other dungeon room. | |||
4: Whether or not the tile is a valid respawn point from loading a save file | |||
3: Whether or not the tile is a valid respawn point from voiding out | |||
2: Set if the tile is water/lava. Whether or not the tile is deep water seems to depend on something else. If set, the elevation for this tile does not appear to impact collision, only the height above the ground where splashing effects appear. | |||
1: Appears to always be 0 | |||
0: Whether you can use the shovel to dig on the tile. | |||
The last fourth byte appears to always be 0x80, or 0b10000000. | |||
|- | |- | ||
|0x4 | |0x4 | ||
| | | | ||
|Unknown, seems to always be identical to the 4 bytes starting at 0x0. | |Unknown, seems to always be identical to the 4 bytes starting at 0x0. | ||
|- | |- | ||
| Line 271: | Line 326: | ||
|0xC | |0xC | ||
|float | |float | ||
| | |Z co-ordinate of the top edge of the room. For sidescroller rooms this seems to always be -1.5. | ||
|} | |} | ||