BFEVFL - Revision history

Leoetlino: /* Dictionary entry */

2023-04-16T11:55:03Z

Dictionary entry

← Older revision		Revision as of 11:55, 16 April 2023
Line 142:		Line 142:
	! Offset !! Type !! Description		! Offset !! Type !! Description
	\|-		\|-
	\| 0x0 \|\| u32 \|\| ~~Compact representation of bit~~ index		\| 0x0 \|\| u32 \|\| Bit index
	\|-		\|-
	\| 0x4 \|\| u16 \|\| Index of next node if bit is 0		\| 0x4 \|\| u16 \|\| Index of next node if bit is 0
Line 150:		Line 150:
	\| 0x8 \|\| PascalString* \|\| Name		\| 0x8 \|\| PascalString* \|\| Name
	\|}		\|}

	~~The compact representation of the bit index has two parts:~~
	* Bits 3-7: index of the byte that should be checked
	* Bits 0-2: index of the bit in that byte

	~~A bit index can be translated to its compact representation using:~~
	~~<syntaxhighlight lang="python">~~
	~~def get_compact_representation(bit_idx: int) -> int:~~
	~~byte_idx = bit_idx // 8~~
	~~return (byte_idx << 3) \| (bit_idx - 8*byte_idx)~~
	~~</syntaxhighlight>~~

	Example: <code>Hello</code> corresponds to 100100001100101011011000110110001101111. Bits 0-3 are 1, bit 4 is 0, etc.		Example: <code>Hello</code> corresponds to 100100001100101011011000110110001101111. Bits 0-3 are 1, bit 4 is 0, etc.

Torphedo: /* Dictionary entry */ Update phrasing to clarify that the index of the next node in the tree is not referring to the bit index.

2022-11-15T03:15:52Z

Dictionary entry: Update phrasing to clarify that the index of the next node in the tree is not referring to the bit index.

← Older revision		Revision as of 03:15, 15 November 2022
Line 144:		Line 144:
	\| 0x0 \|\| u32 \|\| Compact representation of bit index		\| 0x0 \|\| u32 \|\| Compact representation of bit index
	\|-		\|-
	\| 0x4 \|\| u16 \|\| ~~Next index~~ if bit is 0		\| 0x4 \|\| u16 \|\| Index of next node if bit is 0
	\|-		\|-
	\| 0x6 \|\| u16 \|\| ~~Next index~~ if bit is 1		\| 0x6 \|\| u16 \|\| Index of next node if bit is 1
	\|-		\|-
	\| 0x8 \|\| PascalString* \|\| Name		\| 0x8 \|\| PascalString* \|\| Name

Leoetlino: /* Relocation table */ fix code formatting

2021-05-28T17:31:25Z

Relocation table: fix code formatting

← Older revision		Revision as of 17:31, 28 May 2021
Line 78:		Line 78:
	Note: the number of sections is almost always 1 because a single section can already fit 2^32 - 1 entries. If you need more than 4 billion entries, you are probably doing something ''very wrong''.		Note: the number of sections is almost always 1 because a single section can already fit 2^32 - 1 entries. If you need more than 4 billion entries, you are probably doing something ''very wrong''.

	The table base pointer is calculated as follows: `reinterpret_cast<char*>(&table) - table_start_offset`		The table base pointer is calculated as follows: <code>reinterpret_cast<char*>(&table) - table_start_offset</code>

	==== Relocation table section ====		==== Relocation table section ====

Leoetlino: /* Header */ fix missing level of indirection for flowcharts and timelines

2021-05-28T16:20:39Z

Header: fix missing level of indirection for flowcharts and timelines

← Older revision		Revision as of 16:20, 28 May 2021
Line 46:		Line 46:
	\| 0x24 \|\| u32 \|\| Padding		\| 0x24 \|\| u32 \|\| Padding
	\|-		\|-
	\| 0x28 \|\| Flowchart* \|\| Flowchart (nullptr if no flowchart)		\| 0x28 \|\| Flowchart** \|\| Flowchart (nullptr if no flowchart)
	\|-		\|-
	\| 0x30 \|\| [[#Dictionary\|Dictionary]]* \|\| Flowchart name dictionary		\| 0x30 \|\| [[#Dictionary\|Dictionary]]* \|\| Flowchart name dictionary
	\|-		\|-
	\| 0x38 \|\| Timeline* \|\| Timeline (nullptr if no timeline)		\| 0x38 \|\| Timeline** \|\| Timeline (nullptr if no timeline)
	\|-		\|-
	\| 0x40 \|\| Dictionary* \|\| Timeline name dictionary		\| 0x40 \|\| Dictionary* \|\| Timeline name dictionary

Leoetlino: /* ContainerItemData */ wide strings

2021-05-26T13:24:26Z

ContainerItemData: wide strings

← Older revision		Revision as of 13:24, 26 May 2021
Line 208:		Line 208:
	\| String \|\| String (not in string pool, follows item structure immediately) \|\| 1		\| String \|\| String (not in string pool, follows item structure immediately) \|\| 1
	\|-		\|-
	\| Wide string ("wstring") \|\| (not ~~implemented~~) \|\| ?		\| Wide string ("wstring") \|\| Wide string (not in string pool, follows item structure immediately) \|\| 1
	\|-		\|-
	\| Int array \|\| Int[n] \|\| n		\| Int array \|\| Int[n] \|\| n
Line 218:		Line 218:
	\| String array \|\| String[n] (aligned to 8-byte boundaries this time) \|\| n		\| String array \|\| String[n] (aligned to 8-byte boundaries this time) \|\| n
	\|-		\|-
	\| Wstring array \|\| (~~not implemented~~) \|\| ?		\| Wstring array \|\| WString[n] (aligned to 8-byte boundaries this time) \|\| n
	\|-		\|-
	\| Actor identifier \|\| Two strings: actor name + secondary name \|\| 2		\| Actor identifier \|\| Two strings: actor name + secondary name \|\| 2
	\|}		\|}

			Wide strings use wchar_t which is 32-bit long on Switch.

	==== ContainerDataType enum ====		==== ContainerDataType enum ====

Leoetlino: /* Container */ ore::ResMetaData, not ore::ResMetadata

2021-05-26T13:22:41Z

Container: ore::ResMetaData, not ore::ResMetadata

← Older revision		Revision as of 13:22, 26 May 2021
Line 165:		Line 165:

	=== Container ===		=== Container ===
	(The official name for this structure in the EventFlow library is ore::~~ResMetadata~~.)		(The official name for this structure in the EventFlow library is ore::ResMetaData.)

	Containers are key-value mappings with keys being strings. A [[#Dictionary]] is used to store keys.		Containers are key-value mappings with keys being strings. A [[#Dictionary]] is used to store keys.

Leoetlino: fix incorrect documentation

2021-05-26T13:22:13Z

fix incorrect documentation

← Older revision		Revision as of 13:22, 26 May 2021
Line 1:		Line 1:
	<onlyinclude>'''~~bfevfl~~''' is a binary file format for [[Event flow\|'''ev'''ent '''fl'''ows]].</onlyinclude> In ''Breath of the Wild'' and other Nintendo games such as ''Splatoon 2'' and ''Link's Awakening'', binary event flows are parsed by Nintendo's EventFlow/evfl library.		<onlyinclude>'''BFEVFL''' is a binary file format for [[Event flow\|'''ev'''ent '''fl'''ows]].</onlyinclude> In ''Breath of the Wild'' and other Nintendo games such as ''Splatoon 2'' and ''Link's Awakening'', binary event flows are parsed by Nintendo's EventFlow/evfl library.

	== Structures ==		== Structures ==
	~~bfevfl~~ is a little endian ~~format~~, ~~so values are stored in~~ little endian even on Wii U.		BFEVFL is a format that supports both big endian and little endian; however, event flows typically use little endian even on Wii U, as is the case in ''Breath of the Wild''.

	~~bfevfl~~ uses pointers very heavily to refer to strings, to other sections, etc. All pointers are always 64 bit long -- ~~since~~ the same format is used on the Switch ~~which is a 64 bit platform~~. ~~They~~ must be present in the [[#Relocation table]] if the file is to be loaded correctly by the official ~~bfevfl~~ code.		BFEVFL uses pointers very heavily to refer to strings, to other sections, etc. All pointers are always 64-bit long -- this is because the same format is used on 64-bit platforms like the Switch. Pointers must be present in the [[#Relocation table]] if the file is to be loaded correctly by the official EventFlow code.

	As a direct consequence, most sections don't have any fixed order. Therefore, this article will only document the data structures and mention the order Nintendo places sections in. For more details, it is recommended to look at the [https://github.com/leoetlino/evfl <code>evfl</code> library] directly.		As a direct consequence, most sections don't have any fixed order. Therefore, this article will only document the data structures and mention the order Nintendo places sections in. For more details, it is recommended to look at the [https://github.com/leoetlino/evfl <code>evfl</code> library] directly.
Line 16:		Line 16:
	\| 0x0 \|\| char[8] \|\| Magic ("BFEVFL\x00\x00")		\| 0x0 \|\| char[8] \|\| Magic ("BFEVFL\x00\x00")
	\|-		\|-
	\| 0x8 \|\| ~~u16~~ \|\| Version (~~0x0300~~)		\| 0x8 \|\| u8 \|\| Version (major)
	\|-		\|-
	\| ~~0xa~~ \|\| u8 \|\| ~~Unknown~~ (~~must be zero~~)		\| 0x9 \|\| u8 \|\| Version (minor)
	\|-		\|-
	\| ~~0xb~~ \|\| u8 \|\| ~~Unknown~~		\| 0xa \|\| u8 \|\| Version (patch)
	\|-		\|-
	\| 0xc \|\| ~~u16~~ \|\| Byte order mark		\| 0xb \|\| u8 \|\| Version (sub-patch)
			\|-
			\| 0xc \|\| s16 \|\| Byte order mark
	\|-		\|-
	\| 0xe \|\| u8 \|\| Alignment (to get the actual value: 1 << raw_value)		\| 0xe \|\| u8 \|\| Alignment (to get the actual value: 1 << raw_value)
	\|-		\|-
	\| 0xf \|\| u8 \|\| ~~Unknown~~		\| 0xf \|\| u8 \|\| Padding
	\|-		\|-
	\| 0x10 \|\| ~~u32~~ \|\| File name offset		\| 0x10 \|\| int \|\| File name offset
	\|-		\|-
	\| 0x14 \|\| u16 \|\| Is relocated flag (set in memory)		\| 0x14 \|\| u16 \|\| Is relocated flag (set in memory)
Line 34:		Line 36:
	\| 0x16 \|\| u16 \|\| First block offset		\| 0x16 \|\| u16 \|\| First block offset
	\|-		\|-
	\| 0x18 \|\| ~~u32~~ \|\| Relocation table offset		\| 0x18 \|\| int \|\| Relocation table offset
	\|-		\|-
	\| 0x1c \|\| ~~u32~~ \|\| File size		\| 0x1c \|\| int \|\| File size
	\|-		\|-
	\| 0x20 \|\| u16 \|\| Number of [[#Flowchart\|flowchart]]s		\| 0x20 \|\| u16 \|\| Number of [[#Flowchart\|flowchart]]s
Line 63:		Line 65:
	\| 0x0 \|\| char[4] \|\| Magic ("RELT")		\| 0x0 \|\| char[4] \|\| Magic ("RELT")
	\|-		\|-
	\| 0x4 \|\| ~~u32~~ \|\| Offset to relocation table start		\| 0x4 \|\| int \|\| Offset to relocation table start (<code>table_start_offset</code>)
	\|-		\|-
	\| 0x8 \|\| ~~u32~~ \|\| Number of sections		\| 0x8 \|\| int \|\| Number of sections
	\|-		\|-
	\| 0xc \|\| u32 \|\| Padding		\| 0xc \|\| u32 \|\| Padding
	\|-		\|-
	\| 0x10 \|\| Section[num_sections] \|\| Sections		\| 0x10 \|\| Section[num_sections] \|\| Sections
			\|-
			\| - \|\| Entry[...] \|\| Section entries (emitted in the same order as each section)
	\|}		\|}

	Note: the number of sections is almost always 1 because a single section can already fit 2^32 - 1 entries. If you need more than 4 billion entries, you are probably doing something ''very wrong''.		Note: the number of sections is almost always 1 because a single section can already fit 2^32 - 1 entries. If you need more than 4 billion entries, you are probably doing something ''very wrong''.

			The table base pointer is calculated as follows: `reinterpret_cast<char*>(&table) - table_start_offset`

	==== Relocation table section ====		==== Relocation table section ====
Line 78:		Line 84:
	! Offset !! Type !! Description		! Offset !! Type !! Description
	\|-		\|-
	\| 0x0 \|\| void* \|\| ~~Alternative~~ base ~~offset~~ (~~unused by Nintendo~~)		\| 0x0 \|\| void* \|\| Optional base pointer (<code>ptr</code>)
	\|-		\|-
	\| 0x8 \|\| ~~u32~~ \|\| ~~Used to calculate the~~ base pointer ~~if an alternative base~~ offset ~~is used~~		\| 0x8 \|\| int \|\| Optional base pointer offset (<code>offset</code>)
	\|-		\|-
	\| 0xc \|\| ~~u32~~ \|\| ~~Data end offset (before alignment)~~		\| 0xc \|\| int \|\| Size
	\|-		\|-
	\| 0x10 \|\| ~~u32~~ \|\| ~~Number~~ of ~~entries to skip~~		\| 0x10 \|\| int \|\| Index of the first entry in this section
	\|-		\|-
	\| 0x14 \|\| ~~u32~~ \|\| Number of entries ~~(includes skipped entries)~~		\| 0x14 \|\| int \|\| Number of entries
	\|-
	~~\| 0x18 \|\| Entry[num_entries] \|\| Entries~~
	\|}		\|}

			The base pointer (<code>base</code>) is calculated as follows:
			* If the optional base pointer field is nullptr, the base pointer is equal to the table base pointer.
			* Otherwise, it is equal to <code>ptr - offset</code>.

	==== Relocation table entry ====		==== Relocation table entry ====
Line 95:		Line 103:
	! Offset !! Type !! Description		! Offset !! Type !! Description
	\|-		\|-
	\| 0x0 \|\| u32 \|\| Offset to pointers to relocate		\| 0x0 \|\| u32 \|\| Offset to pointers to relocate, relative to the table base pointer
	\|-		\|-
	\| 0x4 \|\| u32 \|\| Bit field that determines which pointers need to be relocated (up to 32 contiguous pointers starting from the listed offset)		\| 0x4 \|\| u32 \|\| Bit field that determines which pointers need to be relocated (up to 32 contiguous pointers starting from the listed offset)
	\|}		\|}

			Offsets are treated as signed 32-bit integers.

			Pointers are relocated by overwriting each 64-bit pointer field with <code>base + offset</code>.

	=== String pool ===		=== String pool ===

imported>Leoetlino: move LAS section to LAS wiki

2019-10-27T15:11:58Z

move LAS section to LAS wiki

← Older revision		Revision as of 15:11, 27 October 2019
Line 563:		Line 563:

	For development versions, it appears that a different, non-binary format was used ("evfl").		For development versions, it appears that a different, non-binary format was used ("evfl").

	~~== Usage in ''Link's Awakening'' ==~~
	BFEVFL is used as the underlying format for event flows in the release versions. Both flowcharts and timelines have .bfevfl as their file extension. Flowcharts are stored directly in [[las:Content/event\|event]], and timelines in [[las:Content/event/tl\|event/tl]].

	== Tools ==		== Tools ==

imported>Leoetlino: usage in LAS

2019-10-27T10:34:04Z

usage in LAS

← Older revision		Revision as of 10:34, 27 October 2019
Line 563:		Line 563:

	For development versions, it appears that a different, non-binary format was used ("evfl").		For development versions, it appears that a different, non-binary format was used ("evfl").

			== Usage in ''Link's Awakening'' ==
			BFEVFL is used as the underlying format for event flows in the release versions. Both flowcharts and timelines have .bfevfl as their file extension. Flowcharts are stored directly in [[las:Content/event\|event]], and timelines in [[las:Content/event/tl\|event/tl]].

	== Tools ==		== Tools ==
Line 568:		Line 571:
	* [https://github.com/leoetlino/event-editor EventEditor]: graphical editor for event flows		* [https://github.com/leoetlino/event-editor EventEditor]: graphical editor for event flows

	~~<hr>~~		== References ==

	<references/>		<references/>

	[[Category:File formats]]		[[Category:File formats]]

imported>Leoetlino: /* Entry point */

2019-09-21T18:20:18Z

Entry point

← Older revision		Revision as of 18:20, 21 September 2019
Line 346:		Line 346:
	\| 0x1a \|\| u16 \|\| Number of variable definitions		\| 0x1a \|\| u16 \|\| Number of variable definitions
	\|-		\|-
	\| 0x1c \|\| u16 \|\| Main event index		\| 0x1c \|\| u16 \|\| Main event index. 0xffff if the entry point doesn't point to any event.
	\|-		\|-
	\| 0x1e \|\| u16 \|\| Padding		\| 0x1e \|\| u16 \|\| Padding