LVB: Difference between revisions
Owen-Splat (talk | contribs) (Add documentation for LVB files) |
Owen-Splat (talk | contribs) m (→Config Section: Adds info about what a specific byte determines) |
||
(3 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
'''LVB''' files are in a [[FixedHash]] format | '''LVB''' files are in a [[FixedHash]] format | ||
===Entries | ===Entries=== | ||
There are 8 entries in most LVB files. | There are 8 entries in most LVB files. | ||
===Node Section=== | ====Node Section==== | ||
This is a FixedHashed child. Not yet understood. | This is a FixedHashed child. Not yet understood. | ||
===Area Section=== | ====Area Section==== | ||
This is a FixedHashed child. Not yet understood. | This is a FixedHashed child. Not yet understood. | ||
===Zone Section=== | ====Zone Section==== | ||
This is a FixedHashed child. | This is a FixedHashed child. It contains an entry for each room where a room is defined by the camera bounds. As such, this likely defines the actual properties of each room. These all seem to be consistent with the exception being Field, which contains several entries and different room IDs. It appears to define each region instead. | ||
===tagPlayerStart Section=== | The music strings are padded with null bytes to fit 32 bytes. | ||
{| class="wikitable" | |||
|+ | |||
!Offset | |||
!Type | |||
!Description | |||
|- | |||
|0x0 | |||
|u32 | |||
|'''Room ID''' Actors load when entering the specified room and unload when leaving it. Generally this should be consistent across all actors in the file, since each room has its own file. | |||
|- | |||
|0x3C | |||
|String | |||
|'''BGM''' Defines which background music to play. Example: ''BGM_CAVE'' | |||
|- | |||
|0x5C | |||
|String | |||
|'''SE_AMB''' Defines which sound effect ambience to play. Example: ''SE_AMB_DUNGEON1_BG'' | |||
|- | |||
|0x7C | |||
|String | |||
|'''GROUP_AMB''' Defines which group ambience to play. Example: ''GROUP_AMB_DUNGEON1'' | |||
|- | |||
|0xB0 | |||
|String | |||
|'''ROOM TYPE?''' Unknown what this means. Example: ''DungeonSmall'' | |||
|} | |||
====tagPlayerStart Section==== | |||
This is a FixedHashed child. There is an entry for every tagPlayerStart actor, with the entry name being the room. | This is a FixedHashed child. There is an entry for every tagPlayerStart actor, with the entry name being the room. | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 34: | Line 62: | ||
|} | |} | ||
===staticObject Section=== | ====staticObject Section==== | ||
This is a FixedHashed child. Not yet understood. | This is a FixedHashed child. Not yet understood. | ||
===Condition Section=== | ====Condition Section==== | ||
Not yet understood. | Not yet understood. | ||
===Config Section=== | ====Config Section==== | ||
Holds 7 bytes of data. The last 5 bytes always seem to be x00\x00\x00\x00\xff. Only the first 2 bytes seem to change | Holds 7 bytes of data that define properties of the level. The last 5 bytes always seem to be x00\x00\x00\x00\xff. Only the first 2 bytes ever seem to change. The second byte is a flag for determining if companions like BowWow will load | ||
====Version Section==== | ====Version Section==== | ||
Holds 3 bytes of data, which seem to always be 0x100182. Given the name, it's probably just a version marker and has no functional purpose. | Holds 3 bytes of data, which seem to always be 0x100182. Given the name, it's probably just a version marker and has no functional purpose. |
Latest revision as of 03:04, 24 February 2023
LVB is a custom format used to store level data in Link's Awakening. This includes things such as the rooms IDs, a list of tagPlayerStart actors, and more. 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 (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
LVB files are in a FixedHash format
Entries
There are 8 entries in most LVB files.
Node Section
This is a FixedHashed child. Not yet understood.
Area Section
This is a FixedHashed child. Not yet understood.
Zone Section
This is a FixedHashed child. It contains an entry for each room where a room is defined by the camera bounds. As such, this likely defines the actual properties of each room. These all seem to be consistent with the exception being Field, which contains several entries and different room IDs. It appears to define each region instead.
The music strings are padded with null bytes to fit 32 bytes.
Offset | Type | Description |
---|---|---|
0x0 | u32 | Room ID Actors load when entering the specified room and unload when leaving it. Generally this should be consistent across all actors in the file, since each room has its own file. |
0x3C | String | BGM Defines which background music to play. Example: BGM_CAVE |
0x5C | String | SE_AMB Defines which sound effect ambience to play. Example: SE_AMB_DUNGEON1_BG |
0x7C | String | GROUP_AMB Defines which group ambience to play. Example: GROUP_AMB_DUNGEON1 |
0xB0 | String | ROOM TYPE? Unknown what this means. Example: DungeonSmall |
tagPlayerStart Section
This is a FixedHashed child. There is an entry for every tagPlayerStart actor, with the entry name being the room.
Offset | Type | Description |
---|---|---|
0x0 | float[3] | 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. Each room is 10x8 tiles, so they span 15 units along the X axis and 12 along the Z axis. |
staticObject Section
This is a FixedHashed child. Not yet understood.
Condition Section
Not yet understood.
Config Section
Holds 7 bytes of data that define properties of the level. The last 5 bytes always seem to be x00\x00\x00\x00\xff. Only the first 2 bytes ever seem to change. The second byte is a flag for determining if companions like BowWow will load
Version Section
Holds 3 bytes of data, which seem to always be 0x100182. Given the name, it's probably just a version marker and has no functional purpose.