LEB: Difference between revisions

Jump to navigation Jump to search

LEB (view source)

Revision as of 06:30, 3 November 2021

1,212 bytes added ,  3 years ago
→‎Grid Section: added info
VisualWikitext
(Updated actor section)
(→‎Grid Section: added info)
Line 135: Line 135:
The second 4 bytes indicate what the purpose of the parameter is. There are only 3 observed values so far:
The second 4 bytes indicate what the purpose of the parameter is. There are only 3 observed values so far:


*0x0, which indicates the parameter is not used?
*0, which indicates the parameter is not used?
*0x2, unknown purpose. Observable on the small key in Lv04AnglersTunnel_06A among other rooms, but the parameters appear to not do anything.
*2, unknown purpose. Observable on the small key in Lv04AnglersTunnel_06A among other rooms, but the parameters appear to not do anything.
*0x3, which indicates that the parameter is an integer parameter, taken as just the value of the first u32.
*3, which indicates that the parameter is an integer parameter, taken as just the value of the first u32.
*0x4, which indicates that the parameter is a string parameter specified in the names section. The value in the previous u32 is the offset in the names section for this parameter.
*4, which indicates that the parameter is a string parameter specified in the names section. The value in the previous u32 is the offset in the names section for this parameter.


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.
Unused parameters are entered as offsets to a null byte in the names section, as a type 4 parameter.
|-
|-
|0x78
|0x78
Line 190: Line 190:
|}
|}
====Grid Section====
====Grid Section====
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. It seems like the block of data for the <code>info</code> entry is also 0x10 bytes, and the data for the <code>data</code> section is almost always 0x500 bytes, except in some cases (like the aforementioned room with an extra entry in this fixed hash).
This section is a child FixedHash which appears to define collision properties of the room. It has two or three entries: <code>data</code>, sometimes <code>chain</code>, and <code>info</code>.  


The data in the <code>data</code> section contains 80 blocks 0x10 bytes each which define some properties for every tile on the screen (which is 10 by 8). The exact format is still unknown.
 
The data in the <code>data</code> section contains blocks 0x10 bytes each which define some properties for every tile on the screen, for a total of 0x500 bytes for top-down rooms and 0x140 bytes for sidescroller rooms. The format of these is not fully understood yet.
{| class="wikitable"
|+
!Offset
!Type
!Description
|-
|0x0
|u32?
|Unknown. The most significant byte appears to always be 0x80.
|-
|0x4
|u32?
|Unknown, seems to always be identical to the value at 0x0.
|-
|0x8
|u32
|'''Chain index'''. Defines which chain to use as an index into the sequence of chains. If the tile doesn't refer to a chain tile, or there is no chain table defined, this will be 0xFFFFFFFF.
|-
|0xC
|float
|'''Elevation'''. Specifies the height of the surface that Link walks on over this tile. It is still unclear what causes tiles' elevations to be gradient (a ramp) or a sudden increase or decrease (a wall).
|}
 
 
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 info block is always 0x10 bytes and holds some essentially metadata about the room, probably to be used alongside the other data here to determine collision.
{| class="wikitable"
|+
!Offset
!Type
!Description
|-
|0x0
|u16
|How many tiles tall the room is. Will always be 0x8 for top-down rooms and 0x2 for sidescroller rooms.
|-
|0x2
|u16
|How many tiles wide the room is. Seems to always be 0xA (10)
|-
|0x4
|float
|The size of 1 tile in units. Seems to always be 1.5.
|-
|0x8
|float
|X co-ordinate of the left edge of the room.
|-
|0xC
|float
|Y co-ordinate of the top edge of the room. For sidescroller rooms this seems to always be -1.5.
|}


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

edits

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

Navigation menu