ZeldaMods (Link's Awakening)

LEB: Difference between revisions

Page Discussion

LEB (view source)

Revision as of 20:53, 7 June 2021

200 bytes removed ,  2 years ago
Large update of info
VisualWikitext
m (→‎Actor Data Section: added ending code)
(Large update of info)
Line 4: Line 4:


==Format==
==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:
'''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 Lv07EagleTower_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:


<code>3d01 1700 0400 0000 ffff ffff 0000 0000</code>
<code>3d01 1700 0400 0000 ffff ffff 0000 0000</code>
Line 26: Line 26:
!Node Index
!Node Index
!Name Offset
!Name Offset
!Name Hash
!Next entry offset
!Next entry offset
!Data Offset
|-
|-
|0xFFF0
|0xFFF0
|Offset of <code>version</code>in the names section
|Offset of <code>version</code>in the names section
|Hash of <code>version</code>
|0xFFFFFFFF
|0xFFFFFFFF
|Offset to section 1
|-
|-
|0xFFF0
|0xFFF0
|Offset of <code>information</code>in the names section
|Offset of <code>infomation</code>in the names section [sic]
|Hash of <code>infomation</code>
|0xFFFFFFFF
|0xFFFFFFFF
|Offset to section 2
|-
|-
|0x0
|0x0
|Offset of <code>point</code>in the names section
|Offset of <code>point</code>in the names section
|Hash of <code>point</code>
|0xFFFFFFFF
|0xFFFFFFFF
|Offset to section 3
|-
|-
|0x1
|0x1
|Offset of <code>rail</code>in the names section
|Offset of <code>rail</code>in the names section
|Hash of <code>rail</code>
|0xFFFFFFFF
|0xFFFFFFFF
|Offset to section 4
|-
|-
|0x2
|0x2
|Offset of <code>actor</code>in the names section
|Offset of <code>actor</code>in the names section
|Hash of <code>actor</code>
|0x10
|0x10
|Offset to Actors Section
|-
|-
|0x3
|0x3
|Offset of <code>grid</code>in the names section
|Offset of <code>grid</code>in the names section
|Hash of <code>grid</code>
|0xFFFFFFFF
|0xFFFFFFFF
|Offset to section 5
|}
|}
The Name Hashes of each should not be touched. The purpose of the DataOffsets is still unknown.
<br />


===Data Section===
===Data Section===
The data section contains nine subsections. Only some of these have a known purpose so far.
The data section contains one subsection for each entry (usually six).  


====Section 1====
====Section 1====
Appears to always consist of 0x2C bytes.
This section holds a u64 with the value 0x3 (specifying 3 bytes of data), followed by the 3 bytes of data. Its purpose is unknown. Following this is five empty bytes.
{| class="wikitable"
|+
!Offset
!Type
!Description
|-
|0x0
|u64
|Always 0x4
|-
|0x8-0xF
|
|Unknown
|-
|0x10
|u64
|Always 0x3
|-
|0x18
|
|Unknown
|-
|0x20
|
|Remaining bytes from here are always <code>3D 01 01 00 00 00 00 FF FF FF FF FF</code>. Probably a termination marker.
|}
 
====Section 2====
====Section 2====
Unknown purpose. Always ends in <code>3D 01 01 00 00 00 00 FF FF FF FF FF</code>.
This section holds a u64 with the value 0x4 (specifying 4 bytes of data), followed by the 4 bytes of data. Its purpose is unknown. Following this is four empty bytes.
 
====Section 3====
====Section 3====
Unknown purpose. Always ends in <code>3D 01 01 00 00 00 00 FF FF FF FF FF</code>.
This is a FixedHash child. It's usually empty and has 1 bucket and no child nodes. The names section is empty. Purpose unknown.


=====Actor Entries Section=====
An example of a room which has a non-empty FixedHash here is Lv01TailCave_04G (Moldorm boss room).
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:
=====Section 4=====
This is another FixedHash child. Usually it's empty and has 1 bucket and no child nodes. The names section is empty. Purpose unknown.


<code>F0 FF 00 00 00 00 00 00 FF FF FF FF xx xx xx xx</code>
An example of a room which has a non-empty FixedHash here is Lv01TailCave_04G (Moldorm boss room).


Where the last 4 bytes store the offset of each actor's data block in the actor data section.
==== Actors Section ====
 
This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry is non-node data, usually 0x90 bytes but sometimes longer. The names section is empty. The data block for each actor is formatted as follows:
====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:
{| class="wikitable"
{| class="wikitable"
|+
|+
Line 114: Line 95:
|0x0
|0x0
|u64
|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.
|'''Actor key'''. This value must match the hex value of the corresponding actor label in the names section.
|-
|-
|0x8
|0x8
|u64
|'''Actor key'''. This value must match the hex value of the corresponding actor label in the names section.
|-
|0x10
|u32
|u32
|'''Names section offset'''. This stores the offset in the names section for the start of the label that corresponds to this actor.
|'''Names section offset'''. This stores the offset in the names section for the start of the label that corresponds to this actor.
|-
|-
|0x14
|0xC
|u16
|u16
|[[Actors|'''Actor ID''']]
|[[Actors|'''Actor ID''']]
|-
|-
|0x16
|0xE
|u16
|u16
|Padding?
|Padding?
|-
|-
|0x18
|0x10
|u32
|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.
|'''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
|0x14
|u32
|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
|'''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
|0x18
|u32
|u32
|Appears to be Z coordinate (height). However it scales very strangely, maybe not linear?
|Appears to be Z coordinate (height). However it scales very strangely, maybe not linear?
|-
|-
|0x24
|0x1C
|u32
|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
|'''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
|0x20-0x37
|
|
|Unknown.
|Unknown.
|-
|-
|0x40
|0x38
|u32[N]
|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).
|'''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).
Line 165: Line 142:
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.
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
|0x38 + N*0x8
|
|
|Unknown.
|Unknown.
|}
|}
Following all of these data blocks, the section ends with <code>00 00 00 00 3D 01 02 00 00 00 00 FF FF FF FF FF</code>.
=====Notes on Parameters for Specific Actors=====
=====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.
'''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====
====Section 6====
Unknown purpose. Usually short (16 bytes), but sometimes longer.
Another child FixedHash. It has a name section which usually contains two strings: <code>data</code> and <code>info</code>. Some have other strings in between, such as Lv08TurtleRock_01H (right half of the sidescroller leading to the boss). This FixedHash has one Entry for each of these strings in the names section. Each entry holds a block of data. The purpose of this is still unknown. The final entry seems to always have a data block of 0x10 bytes.
 
====Section 8====
Another section filled with entry-like data. The purpose of it is still unknown.


====Section 9====
The purpose of this section is unknown.
Preceded by a u32 specifying the length of this section. Contains a few strings in plain ASCII, usually <code>data</code> and <code>info</code>. The purpose of this is unknown.


===Names Section===
===Names Section===
Glan
39

edits

Retrieved from "https://zeldamods.org/las/Special:MobileDiff/684"