AINB: Difference between revisions

Jump to navigation Jump to search
1,325 bytes added ,  9 days ago
update resident update stuff -> active node
m (immediate param -> internal param and added node flag 3)
(update resident update stuff -> active node)
 
Line 17: Line 17:
# Input/Output Parameters
# Input/Output Parameters
# Multi-Parameters
# Multi-Parameters
# Resident Update Array
# Active Node Update Array
# 0x50 Section (Unused in ''TotK'')
# 0x50 Section (Unused in ''TotK'')
# Precondition Nodes
# Precondition Nodes
Line 103: Line 103:
|0x04
|0x04
|u32
|u32
|Resident Update Array Offset
|Active Node Update Array Offset
|-
|-
|0x34
|0x34
Line 143: Line 143:
|0x04
|0x04
|u32
|u32
|Unknown (unused in ''TotK'', always the same as the Resident Update Array Offset)
|Unknown (unused in ''TotK'', always the same as the Active Node Update Array Offset)
|-
|-
|0x54
|0x54
Line 483: Line 483:
|-
|-
|Element_Fork
|Element_Fork
|See Resident Update Array
|See Active Node Update Array
|-
|-
|Element_Join
|Element_Join
|See Resident Update Array
|See Active Node Update Array
|-
|-
|Element_Alert
|Element_Alert
Line 883: Line 883:
|0x01
|0x01
|u8
|u8
|Resident Update Node Count
|Active Node Update Count
|-
|-
|0x07
|0x07
|0x01
|0x01
|u8
|u8
|Resident Update Base Index
|Active Node Update Base Index
|-
|-
|0x08
|0x08
Line 968: Line 968:
|Value
|Value
|}
|}
The interpretation of the value depends on the connection type. For input or output connections, the value is a string offset to the parameter name. For standard connections, the value is a string offset to the connection name. For resident update connections, the value is an index into the resident update array. Certain node/connection types will also extend the entry length. Selector-type nodes excluding <code>Element_BoolSelector</code> and <code>Element_F32Selector</code> will have an extra four bytes which stores the condition for to link to the child node. For <code>Element_S32Selector</code>, this is an immediate value. For <code>Element_RandomSelector</code>, this is a weight and for <code>Element_StringSelector</code> it is a u32 string offset. The condition for  <code>Element_BoolSelector</code> is the entry's value string. <code>Element_F32Selector</code> adds 24 bytes to each entry, consisting of four eight-byte sub-entries.
The interpretation of the value depends on the connection type. For input or output connections, the value is a string offset to the parameter name. For standard connections, the value is a string offset to the connection name. For active node update connections, the value is an index into the active node update array. Certain node/connection types will also extend the entry length. Selector-type nodes excluding <code>Element_BoolSelector</code> and <code>Element_F32Selector</code> will have an extra four bytes which stores the condition for to link to the child node. For <code>Element_S32Selector</code>, this is an immediate value. For <code>Element_RandomSelector</code>, this is a weight and for <code>Element_StringSelector</code> it is a u32 string offset. The condition for  <code>Element_BoolSelector</code> is the entry's value string. <code>Element_F32Selector</code> adds 24 bytes to each entry, consisting of four eight-byte sub-entries.
{| class="wikitable"
{| class="wikitable"
|+<code>Element_F32Selector Condition Entry</code>
|+<code>Element_F32Selector Condition Entry</code>
Line 1,156: Line 1,156:


==== Internal Parameters ====
==== Internal Parameters ====
This section contains an array of internalparameters 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.
This section contains an array of internal 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. Similarly to the internal 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.
This section contains an array of input and output parameter entries. These appear to be canonically referred to as "plugs". Similarly to the internal 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,386: Line 1,386:
|}
|}


==== Resident Update Array ====
==== Active Node Update Array ====
This section is an array of entries for resident nodes that are updated mid-node update sequence. The first four bytes specify the number of entries. Each entry is four bytes.
This section is an array of entries for updates to the active node array. The first four bytes specify the number of entries. Each entry is four bytes.
{| class="wikitable"
{| class="wikitable"
|+
|+
Line 1,400: Line 1,400:
|-
|-
|1
|1
|Update Post Current Command Calculation
|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). By default, the node is scheduled to update pre-next command calculation, however, this can change depending on the flags set. Additionally, Fork and Join nodes behave differently. Fork nodes will append the node to the run array while Join nodes will update the node post-current command calculation.
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 internal 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 ====
34

edits

Navigation menu