LEB - Revision history

Owen-Splat: Change room ID to zone ID to be more accurate

2025-06-03T18:53:36Z

Change room ID to zone ID to be more accurate

← Older revision		Revision as of 18:53, 3 June 2025
Line 137:		Line 137:
	\|0x10		\|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.~~		\|'''Zone ID'''. The actor loads when entering the specified zone and unloads when leaving it
	\|-		\|-
	\|0x14		\|0x14

Glan at 07:20, 5 November 2021

2021-11-05T07:20:01Z

← Older revision		Revision as of 07:20, 5 November 2021
Line 80:		Line 80:
	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.		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====
	This is another FixedHash child. The exact purpose of this section is not understand but it seems to work in conjunction with <code>point</code>. There is one entry per rail.		This is another FixedHash child. The exact purpose of this section is not understand but it seems to work in conjunction with <code>point</code>. There is one entry per rail.

Glan: /* Grid Section */ expanded info on grid data

2021-11-05T06:58:28Z

Grid Section: expanded info on grid data

← Older revision		Revision as of 06:58, 5 November 2021
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~~; since Link's Awakening is a top-down game we will call the vertical axis~~ Z ~~(i.e~~. the ~~axis~~ perpendicular to the ~~plane of~~ the ~~floor~~), and ~~X and Y will be as normal for a 2D game~~.		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~~, Y~~) 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.		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~~, Y~~]. One in-game "tile" is 1.5 units.		\|'''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 Y axis.		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~~, Y~~] axes respectively, in degrees.		\|'''Rotation''' about the [X, Y, Z] axes respectively, in degrees.
	\|-		\|-
	\|0x2C		\|0x2C
	\|float[3]		\|float[3]
	\|'''Scaling''' along the [X, Z~~, Y~~] axes respectively. Note that scaling doesn't seem to affect collision for every actor and only scales the model in some cases.		\|'''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 ~~collision~~ properties of the room. It has two or three entries: <code>data</code>, sometimes <code>chain</code>, and <code>info</code>.		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
	\|~~u32~~?		\|bit field
	\|Unknown. The ~~most significant~~ byte appears to always be 0x80.		\|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
	\|~~u32?~~		\|
	\|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
	\|Y co-ordinate of the top edge of the room. For sidescroller rooms this seems to always be -1.5.		\|Z co-ordinate of the top edge of the room. For sidescroller rooms this seems to always be -1.5.
	\|}		\|}

Glan at 22:59, 3 November 2021

2021-11-03T22:59:34Z

← Older revision		Revision as of 22:59, 3 November 2021
Line 1:		Line 1:
	'''LEB''' is a custom format used to store room data in Link's Awakening.		'''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.

	~~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; since Link's Awakening is a top-down game we will call the vertical axis Z (i.e. the axis perpendicular to the plane of the floor), and X and Y will be as normal for a 2D game.

	==Format==		==Format==
Line 72:		Line 72:

	====Version Section====		====Version Section====
	~~This section holds a u64 with the value 0x3 (specifying 3 bytes of data), followed by the~~ 3 bytes of data, which seem to always be 0x1001D4~~. Whether it has a purpose is unclear~~. Given the name, it ~~could~~ just be a version marker~~. Following this is five empty bytes~~.		Holds 3 bytes of data, which seem to always be 0x1001D4. Given the name, it's probably just a version marker and has no functional purpose.
	====Infomation Section====		====Infomation Section====
	~~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~~.		Holds 4 bytes of data. The purpose of this is unknown.
	====Point Section====		====Point Section====
	This is a FixedHash child. It~~'s usually empty and has 1 bucket~~ and ~~no child nodes. The names section is empty. Purpose unknown~~.		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.

	~~An example~~ of ~~a room which has a non-empty FixedHash here is Lv01TailCave_04G~~ (~~Moldorm boss room~~).		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, Y) 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=====
	This is another FixedHash child~~. Usually it's empty and has 1 bucket and no child nodes~~. The ~~names~~ section is ~~empty~~. ~~Purpose unknown~~.		This is another FixedHash child. The exact purpose of this section is not understand but it seems to work in conjunction with <code>point</code>. There is one entry per rail.

	~~An example~~ of a ~~room which has a non~~-~~empty FixedHash here~~ is ~~Lv01TailCave_04G~~ (~~Moldorm boss room~~).		Each rail has a data block of variable size, typically 0x32 or more bytes.
			{\| class="wikitable"
			\|+
			!Offset
			!Type
			!Description
			\|-
			\|0x0
			\|
			\|Appears to always be 0xC null bytes?
			\|-
			\|0xC
			\|
			\|Block of 4 structures with a parameter-like structure (see actor section) except for using 0xFFFFFF04 instead of 0x4. So far only observed to be blocks of [0x19, 0xFFFFFF04].
			\|-
			\|0x2C
			\|u16
			\|Number of entries in following list
			\|-
			\|0x2E
			\|u16
			\|Number of indexes per entry? Only observed to ever be 0x01 so far, so no clear purpose.
			\|-
			\|0x30
			\|u16[...]
			\|Indexes of points used per rail (in the <code>point</code> section). The logic behind how points are grouped into rails is not understood, but always seems to line up with how actors reference points. So, an actor that refers to (rail 0, point 0) and (rail 0, point 1) means that rail 0 references points 0 and 1. An actor referring only to (rail 2, point 2) and nothing else with rail 2 means that rail 2 only references point 2.
			\|}

	====Actor Section====		====Actor Section====
	This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, a block with a minimum size of 0x90 bytes, but can be longer. The names section is empty. The data block for each actor is formatted as follows. Some properties are related to measurements along the three axes; since Link's Awakening is a top-down game we will call the vertical axis Z (i.e. the axis perpendicular to the plane of the floor), and X and Y will be as normal for a 2D game.		This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, a block with a minimum size of 0x90 bytes, but can be longer. The names section is empty. The data block for each actor is formatted as follows.
	{\| class="wikitable"		{\| class="wikitable"
	\|+		\|+
Line 182:		Line 208:


	'''Section 2'''~~<nowiki/>'s purpose is not yet known~~. It consists of a sequence of 24-byte structures, which are each 2 parameters (8 bytes each), and 2 u32's.		'''Section 2''' defines a list of points the actor knows about. It consists of a sequence of 24-byte structures, which are each 2 parameters (8 bytes each), and 2 u32's, which respectively index into the <code>rail</code> section and the <code>point</code> section. This is used for various things, for example the Link:MoveToTargetLinkedPoint event action, or the location for item drops from the actor to land, or the location to dynamically spawn other actors (e.g. pickups in rapids rush).


Line 204:		Line 230:
	\|0x4		\|0x4
	\|u32?		\|u32?
	\|Unknown, seems to always be identical to the ~~value~~ at 0x0.		\|Unknown, seems to always be identical to the 4 bytes starting at 0x0.
	\|-		\|-
	\|0x8		\|0x8
Line 216:		Line 242:


	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 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 data is stored in the same structures as the <code>data</code> section.

Glan: /* Actor Section */

2021-11-03T19:05:06Z

Actor Section

← Older revision		Revision as of 19:05, 3 November 2021
Line 131:		Line 131:
	\|u32[16]		\|u32[16]
	\|'''Parameters'''. This section contains 16 u32's, which are grouped into 8 pairs of [parameter, parameter type].		\|'''Parameters'''. This section contains 16 u32's, which are grouped into 8 pairs of [parameter, parameter type].
	~~For any pair, the first 4 bytes make up the value of the parameter. This can be basically anything (will include some known parameters for certain actor~~ types ~~below).~~		The types are as follows:

	~~The second 4 bytes indicate what the purpose of~~ the parameter is. ~~There are only~~ 3 ~~observed values so far~~:		*0: the parameter is not used? Mainly observable in lighting actors.
			*2: Float
			*3: Unsigned integer (u32)
			*4: String, where the parameter value define the offset of the string in the top-level names section.

	*0, which indicates the parameter is not used?		Unused parameters are generally entered as offsets to a null byte in the names section, as a type 4 parameter.
	*2, unknown purpose. Observable on the small key in Lv04AnglersTunnel_06A among other rooms, but the parameters appear to not do anything.
	*3, which indicates that the parameter is an integer parameter, taken as just the value of the first u32.
	*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.

	Unused parameters are entered as offsets to a null byte in the names section, as a type 4 parameter.
	\|-		\|-
	\|0x78		\|0x78

Glan: /* Actor Section */ Update relationship section

2021-11-03T19:02:03Z

Actor Section: Update relationship section

← Older revision		Revision as of 19:02, 3 November 2021
Line 163:		Line 163:


	The sections starts with 8 bytes which define the structure and purpose of the data in the section, ~~followed by 4~~ null ~~bytes, and then followed by 3 sections of data~~.		The sections starts with 12 bytes which define the structure and purpose of the data in the section, where the latter 6 bytes are always null.


	'''xx ~~bb kk ee~~''' ~~00 00~~ '''yy zz''' 00 00 00 00		'''ee kk bb xx''' '''yy zz''' 00 00 00 00 00 00

			'''e''' is 01 for any enemy actor and 00 otherwise.

			'''k''' is 01 only for TagHolocaustChecker actors. Probably indicates looking at enemy spawns/kills.

			'''b''' appears to be 01 for an enemy that appears from the +enemies tile in a chamber dungeon and 00 otherwise.

	'''x''' indicates the number of entries in section 1.		'''x''' indicates the number of entries in section 1.
Line 173:		Line 179:

	'''z''' indicates the number of entries in section 2. (This is not a typo, for some reason it defines the group sizes in the order 1, 3, 2.)		'''z''' indicates the number of entries in section 2. (This is not a typo, for some reason it defines the group sizes in the order 1, 3, 2.)

	~~'''b''' appears to be 01 if the enemy appears from the +enemies tile in a chamber dungeon and 00 otherwise.~~

	~~'''k''' is 01 only for TagHolocaustChecker actors. Probably indicates looking at enemy spawns/kills.~~

	~~'''e''' is 01 for all enemies and 00 for anything else.~~

Glan: /* Actor Section */

2021-11-03T18:54:35Z

Actor Section

← Older revision		Revision as of 18:54, 3 November 2021
Line 170:		Line 170:
	'''x''' indicates the number of entries in section 1.		'''x''' indicates the number of entries in section 1.

	'''y''' indicates the number of entries in section 2.		'''y''' indicates the number of entries in section 3.

	'''z''' indicates the number of entries in section 3.		'''z''' indicates the number of entries in section 2. (This is not a typo, for some reason it defines the group sizes in the order 1, 3, 2.)

	'''b''' appears to be 01 if the enemy appears from the +enemies tile in a chamber dungeon and 00 otherwise.		'''b''' appears to be 01 if the enemy appears from the +enemies tile in a chamber dungeon and 00 otherwise.

Glan: /* Grid Section */ added info

2021-11-03T06:30:09Z

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:
-*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
@@ Line 190: / Line 190: @@
 |}
 ====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.
 ===Names Section===

Glan: Updated actor section

2021-11-03T00:44:08Z

Updated actor section

← Older revision		Revision as of 00:44, 3 November 2021
Line 86:		Line 86:

	====Actor Section====		====Actor Section====
	This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, ~~usually blocks~~ of 0x90 bytes, but ~~sometimes~~ longer. The names section is empty. The data block for each actor is formatted as follows. Some properties are related to measurements along ~~certain~~ axes; since ~~this~~ is a top-down game we will call the vertical axis Z (i.e. the axis ~~toward~~ the ~~camera~~), and X and Y will be as normal for a 2D game.		This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, a block with a minimum size of 0x90 bytes, but can be longer. The names section is empty. The data block for each actor is formatted as follows. Some properties are related to measurements along the three axes; since Link's Awakening is a top-down game we will call the vertical axis Z (i.e. the axis perpendicular to the plane of the floor), and X and Y will be as normal for a 2D game.
	{\| class="wikitable"		{\| class="wikitable"
	\|+		\|+
Line 114:		Line 114:
	\|-		\|-
	\|0x14		\|0x14
	\|~~u32~~		\|float[3]
	\|'''~~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~~		\|'''Co-ordinates''' as [X, Z, Y]. 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.
	~~\|0x18~~
	~~\|u32~~		Each room is 10x8 tiles, so they span 15 units along the X axis and 12 along the Y axis.
	~~\|Appears~~ to ~~be Z coordinate (height)~~. ~~However it scales~~ very ~~strangely~~, ~~maybe not linear?~~
	\|-
	~~\|0x1C~~
	~~\|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~~
	\|-		\|-
	\|0x20		\|0x20
	\|~~u32~~		\|float[3]
	\|~~Most likely rotation~~ about the X ~~axis. This is primarily only used with lighting actors.~~		\|'''Rotation''' about the [X, Z, Y] axes respectively, in degrees.
	\|-
	~~\|0x24~~
	~~\|u32~~
	~~\|Rotation about the~~ Z ~~(vertical) axis. The scaling of this value is uncertain~~, ~~but 0xC2B40000 is 90° clockwise, 0x43340000 is 180°~~, ~~and 0x42B40000 is 270° clockwise (90° counterclockwise).~~
	\|-
	~~\|0x28~~
	~~\|u32~~
	~~\|Most likely rotation about the Y axis. This is primarily only used with lighting actors~~.
	\|-		\|-
	\|0x2C		\|0x2C
	\|~~u32~~		\|float[3]
	\|'''~~X-axis scaling~~'''~~. 0x3F800000 is~~ the ~~normal scale.~~		\|'''Scaling''' along the [X, Z, Y] axes respectively. Note that scaling doesn't seem to affect collision for every actor and only scales the model in some cases.
	\|-
	~~\|0x30~~
	~~\|u32~~
	~~\|'''~~Z~~-axis scaling'''~~. ~~0x3F800000 is the normal scale.~~
	\|-
	~~\|0x34~~
	~~\|u32~~
	~~\|'''Y-axis~~ scaling'~~''. 0x3F800000 is~~ the ~~normal scale~~.
	\|-		\|-
	\|0x38		\|0x38
Line 189:		Line 168:
	'''xx bb kk ee''' 00 00 '''yy zz''' 00 00 00 00		'''xx bb kk ee''' 00 00 '''yy zz''' 00 00 00 00

	'''x''' indicates the number of ~~actors~~ in section 1.		'''x''' indicates the number of entries in section 1.

	'''y''' indicates the number of ~~actors~~ in section 2.		'''y''' indicates the number of entries in section 2.

	'''z''' indicates the number of ~~actors~~ in section 3.		'''z''' indicates the number of entries in section 3.

	'''b''' appears to be 01 if the enemy appears from the +enemies tile in a chamber dungeon and 00 otherwise.		'''b''' appears to be 01 if the enemy appears from the +enemies tile in a chamber dungeon and 00 otherwise.

Glan: /* Actor Section */

2021-11-02T23:13:53Z

Actor Section

← Older revision		Revision as of 23:13, 2 November 2021
Line 86:		Line 86:

	====Actor Section====		====Actor Section====
	This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, usually blocks of 0x90 bytes, but sometimes longer. The names section is empty. The data block for each actor is formatted as follows:		This section is a FixedHash which holds actor data. Each entry corresponds to one actor. Every entry points to non-node data, usually blocks of 0x90 bytes, but sometimes longer. The names section is empty. The data block for each actor is formatted as follows. Some properties are related to measurements along certain axes; since this is a top-down game we will call the vertical axis Z (i.e. the axis toward the camera), and X and Y will be as normal for a 2D game.
	{\| class="wikitable"		{\| class="wikitable"
	\|+		\|+
Line 127:		Line 127:
	\|0x20		\|0x20
	\|u32		\|u32
	\|~~Unknown~~		\|Most likely rotation about the X axis. This is primarily only used with lighting actors.
	\|-		\|-
	\|0x24		\|0x24
	\|u32		\|u32
	\|~~Unknown~~		\|Rotation about the Z (vertical) axis. The scaling of this value is uncertain, but 0xC2B40000 is 90° clockwise, 0x43340000 is 180°, and 0x42B40000 is 270° clockwise (90° counterclockwise).
	\|-		\|-
	\|0x28		\|0x28
	\|u32		\|u32
	\|~~Unknown~~. ~~Mostly~~ only used on lighting actors		\|Most likely rotation about the Y axis. This is primarily only used with lighting actors.
	\|-		\|-
	\|0x2C		\|0x2C
	\|u32		\|u32
	\|~~Unknown~~. ~~Commonly~~ 0x3F800000		\|'''X-axis scaling'''. 0x3F800000 is the normal scale.
	\|-		\|-
	\|0x30		\|0x30
	\|u32		\|u32
	\|~~Unknown~~. ~~Commonly~~ 0x3F800000		\|'''Z-axis scaling'''. 0x3F800000 is the normal scale.
	\|-		\|-
	\|0x34		\|0x34
	\|u32		\|u32
	\|~~Unknown~~. ~~Commonly~~ 0x3F800000		\|'''Y-axis scaling'''. 0x3F800000 is the normal scale.
	\|-		\|-
	\|0x38		\|0x38