LVB: Difference between revisions

From ZeldaMods (Link's Awakening)
Jump to navigation Jump to search
m (Small correction)
m (→‎Config Section: Adds info about what a specific byte determines)
 
Line 69: Line 69:


====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, and there does appear to be a pattern with level types.
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.