46
edits
AINB: Difference between revisions
Update "precondition" to "query" and "internal" to "property" based on terminology found in NSO Playtest.
(Rewrite head of article to clarify information.) |
(Update "precondition" to "query" and "internal" to "property" based on terminology found in NSO Playtest.) |
||
| Line 2: | Line 2: | ||
=== File Structure === | === File Structure === | ||
AINB is little endian. An AINB file defines a set of commands to evaluate a tree of built-in or game-specific node classes. The built-in "Element_ModuleCaller" node and supporting structures allow a "root" AINB file to call out to an external "module" AINB file, module's can call further modules, allowing AINB files to form a tree of tree's. An AINB's file extension typically designates whether it is a root <code>.root.ainb</code> or module <code>.module.ainb</code>. For AI and Sequence files, the file's entry point is one or more commands which is linked to one or two child nodes. All nodes are accessed by their index (references to | AINB is little endian. An AINB file defines a set of commands to evaluate a tree of built-in or game-specific node classes. The built-in "Element_ModuleCaller" node and supporting structures allow a "root" AINB file to call out to an external "module" AINB file, module's can call further modules, allowing AINB files to form a tree of tree's. An AINB's file extension typically designates whether it is a root <code>.root.ainb</code> or module <code>.module.ainb</code>. For AI and Sequence files, the file's entry point is one or more commands which is linked to one or two child nodes. All nodes are accessed by their index (references to query nodes will use their query node index which is local to the amount of query nodes in the file). | ||
All string offsets in the file are relative to the beginning of the string pool and name hashes are 32-bit murmur3 hashes. There are six possible data types for AINB parameters: int (signed 32-bit integer), bool, float (32-bit), vector3f, and pointer. Pointer parameters are pointers to objects. | All string offsets in the file are relative to the beginning of the string pool and name hashes are 32-bit murmur3 hashes. There are six possible data types for AINB parameters: int (signed 32-bit integer), bool, float (32-bit), vector3f, and pointer. Pointer parameters are pointers to objects. | ||
| Line 14: | Line 14: | ||
# Node Bodies | # Node Bodies | ||
# Attachment Parameters | # Attachment Parameters | ||
# | # Property Parameters | ||
# Input/Output Parameters | # Input/Output Parameters | ||
# Multi-Parameters | # Multi-Parameters | ||
# Active Node Update Array | # Active Node Update Array | ||
# 0x50 Section (Unused in ''TotK'') | # 0x50 Section (Unused in ''TotK'') | ||
# | # Query Node Array | ||
# Expression Binary | # Expression Binary | ||
# AINB Modules | # AINB Modules | ||
| Line 68: | Line 68: | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
| | |Query Node Count | ||
|- | |- | ||
|0x18 | |0x18 | ||
| Line 98: | Line 98: | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
| | |Property Parameters Offset | ||
|- | |- | ||
|0x30 | |0x30 | ||
| Line 138: | Line 138: | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
| | |Query Node Array Offset | ||
|- | |- | ||
|0x50 | |0x50 | ||
| Line 216: | Line 216: | ||
|0x02 | |0x02 | ||
|u16 | |u16 | ||
| | |Main Node Index | ||
|- | |- | ||
|0x16 | |0x16 | ||
|0x02 | |0x02 | ||
|u16 | |u16 | ||
| | |Secondary Node Index (value offset by 1, 0 is reserved) | ||
|} | |} | ||
Command GUIDs are only used for debug messages. Right Node Index will be -1 if the command only has one child node. | Command GUIDs are only used for debug messages. Right Node Index will be -1 if the command only has one child node. | ||
| Line 307: | Line 307: | ||
|0x02 | |0x02 | ||
|u16 | |u16 | ||
|Base | |Base Query Node | ||
|- | |- | ||
|0x26 | |0x26 | ||
|0x02 | |0x02 | ||
|u16 | |u16 | ||
| | |Query Node Count | ||
|- | |- | ||
|0x28 | |0x28 | ||
| Line 545: | Line 545: | ||
|- | |- | ||
|1 | |1 | ||
|Is | |Is Query Node | ||
|- | |- | ||
|1 | |1 | ||
| Line 666: | Line 666: | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Int | |Int Property Parameter Base Index | ||
|- | |- | ||
|0x04 | |0x04 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Int | |Int Property Parameter Count | ||
|- | |- | ||
|0x08 | |0x08 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Bool | |Bool Property Parameter Base Index | ||
|- | |- | ||
|0x0C | |0x0C | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Bool | |Bool Property Parameter Count | ||
|- | |- | ||
|0x10 | |0x10 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Float | |Float Property Parameter Base Index | ||
|- | |- | ||
|0x14 | |0x14 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Float | |Float Property Parameter Count | ||
|- | |- | ||
|0x18 | |0x18 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|String | |String Property Parameter Base Index | ||
|- | |- | ||
|0x1C | |0x1C | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|String | |String Property Parameter Count | ||
|- | |- | ||
|0x20 | |0x20 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Vector3f | |Vector3f Property Parameter Base Index | ||
|- | |- | ||
|0x24 | |0x24 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Vector3f | |Vector3f Property Parameter Count | ||
|- | |- | ||
|0x28 | |0x28 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Pointer | |Pointer Property Parameter Base Index | ||
|- | |- | ||
|0x2C | |0x2C | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Pointer | |Pointer Property Parameter Count | ||
|- | |- | ||
|0x30 | |0x30 | ||
| Line 1,037: | Line 1,037: | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Int | |Int Property Parameter Base Index | ||
|- | |- | ||
|0x08 | |0x08 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Int | |Int Property Parameter Count | ||
|- | |- | ||
|0x0C | |0x0C | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Bool | |Bool Property Parameter Base Index | ||
|- | |- | ||
|0x10 | |0x10 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Bool | |Bool Property Parameter Count | ||
|- | |- | ||
|0x14 | |0x14 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Float | |Float Property Parameter Base Index | ||
|- | |- | ||
|0x18 | |0x18 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Float | |Float Property Parameter Count | ||
|- | |- | ||
|0x1C | |0x1C | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|String | |String Property Parameter Base Index | ||
|- | |- | ||
|0x20 | |0x20 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|String | |String Property Parameter Count | ||
|- | |- | ||
|0x24 | |0x24 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Vector3f | |Vector3f Property Parameter Base Index | ||
|- | |- | ||
|0x28 | |0x28 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Vector3f | |Vector3f Property Parameter Count | ||
|- | |- | ||
|0x2C | |0x2C | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Pointer | |Pointer Property Parameter Base Index | ||
|- | |- | ||
|0x30 | |0x30 | ||
|0x04 | |0x04 | ||
|u32 | |u32 | ||
|Pointer | |Pointer Property Parameter Count | ||
|- | |- | ||
|0x34 | |0x34 | ||
| Line 1,155: | Line 1,155: | ||
|} | |} | ||
==== | ==== Property Parameters ==== | ||
This section contains an array of | This section contains an array of property parameters for nodes. The section begins with a six u32 relative offsets to the first entry for each data type. The data type order for this section is int, bool, float, string, vector3f, and pointer. | ||
{| class="wikitable" | {| class="wikitable" | ||
|+Parameter Entry | |+Parameter Entry | ||
| Line 1,226: | Line 1,226: | ||
==== Input/Output Parameters ==== | ==== Input/Output Parameters ==== | ||
This section contains an array of input and output parameter entries. These appear to be canonically referred to as "plugs". Similarly to the | This section contains an array of input and output parameter entries. These appear to be canonically referred to as "plugs". Similarly to the property parameters section, the section begins with u32 relative offsets to the first entry of each data type. However, instead of six offsets, there are 12 - two for each data type (one input, one output). The order of parameters in this section is int input, int output, bool input, bool output, float intput, float output, string input, string output, vector3f input, vector3f output, pointer input, and pointer output. | ||
{| class="wikitable" | {| class="wikitable" | ||
|+Input Parameter Entry | |+Input Parameter Entry | ||
| Line 1,402: | Line 1,402: | ||
|Update Post Calc | |Update Post Calc | ||
|} | |} | ||
If the first byte of the flags is set to false, then the entry contains another four bytes with a string offset (purpose unknown). Otherwise, the entry is considered valid if the first byte equals 1. When processing a node graph, the game maintains an array of active root nodes. When a command calculated, the root node of the command is added to this array and it and its child nodes are calculated recursively. An active node update will change the current active root node to the specified node. This usually happens right before the next command's calculation occurs, but if the top bit is set, then it will occur immediately after the current command's calculation finishes (if the source node is an Element_Join nodes, it will always update the active node post current command calculation). This is primarily used for "subroutines" that run a single time then return to the main execution routine. This system is also used for Element_Fork and Element_Join nodes. An Element_Fork node, unlike normal nodes, will replace the entire current active node array with its array of active node updates (essentially forking execution into multiple different paths). The node at the end of each of these paths will optionally also have an active node update referencing a specific Element_Join node. Each of these nodes will push the Element_Join into the active node array. However, Element_Join nodes have an | If the first byte of the flags is set to false, then the entry contains another four bytes with a string offset (purpose unknown). Otherwise, the entry is considered valid if the first byte equals 1. When processing a node graph, the game maintains an array of active root nodes. When a command calculated, the root node of the command is added to this array and it and its child nodes are calculated recursively. An active node update will change the current active root node to the specified node. This usually happens right before the next command's calculation occurs, but if the top bit is set, then it will occur immediately after the current command's calculation finishes (if the source node is an Element_Join nodes, it will always update the active node post current command calculation). This is primarily used for "subroutines" that run a single time then return to the main execution routine. This system is also used for Element_Fork and Element_Join nodes. An Element_Fork node, unlike normal nodes, will replace the entire current active node array with its array of active node updates (essentially forking execution into multiple different paths). The node at the end of each of these paths will optionally also have an active node update referencing a specific Element_Join node. Each of these nodes will push the Element_Join into the active node array. However, Element_Join nodes have an property parameter called InFlowNum and until it has been pushed onto the array that many times in a single calculation, it will not activate and remain dormant. However, once this threshold is reached, it will begin execution (with a guard to make sure only one of the instances added to the array will execute). | ||
==== 0x50 Section ==== | ==== 0x50 Section ==== | ||
This section is unused in ''Tears of the Kingdom''. | This section is unused in ''Tears of the Kingdom''. | ||
==== | ==== Query Node Array ==== | ||
This section is an array of entries of | This section is an array of entries of query nodes present in the file. | ||
{| class="wikitable" | {| class="wikitable" | ||
|+ | |+Query Node Entry | ||
!Offset | !Offset | ||
!Size | !Size | ||
| Line 1,419: | Line 1,419: | ||
|0x02 | |0x02 | ||
|u16 | |u16 | ||
| | |Query Node Index (local to number of query nodes) | ||
|- | |- | ||
|0x02 | |0x02 | ||