> For the complete documentation index, see [llms.txt](https://malbersanimations.gitbook.io/animal-controller/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://malbersanimations.gitbook.io/animal-controller/malbers-questforge/dialogue-system/nodes/true-false-node-conditions2.md). # True/False Node (Conditions2) ### Overview The **True/False Node** is the branching and conditional logic node of the Dialogue System. It evaluates a set of Malbers **Conditions2** against a target GameObject and routes the dialogue graph down either the **True** or **False** output path based on the result. It is the primary tool for making dialogue context-aware — showing different responses based on quest state, player stats, dialogue flags, NPC state, or any other condition supported by the Malbers Conditions2 system. The node is notably wider than others in the graph editor (minimum 450px) to accommodate the full Conditions2 property drawer inline, and resizes dynamically as conditions are added or removed. ***
### Ports | Port | Direction | Capacity | Description | | ------------ | --------- | -------- | ------------------------------------------------------- | | **Previous** | Input | Single | Receives a connection from the preceding node. | | **True** | Output | Single | Followed when the condition block evaluates to `true`. | | **False** | Output | Single | Followed when the condition block evaluates to `false`. | > The **Previous** input port accepts only a **single** incoming connection, unlike most other nodes which accept Multi. Plan your graph accordingly — use a preceding branching node if you need multiple paths to converge here. *** ### Node Properties | Property | Type | Description | | -------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Target (GameObjectVar)** | `GameObjectVar` | A Malbers `GameObjectVar` ScriptableObject pointing to the GameObject that conditions will be evaluated against. Optional — see target resolution order below. | | **Conditions** | `Conditions2` | A full Malbers Conditions2 block. Supports multiple conditions with AND/OR logic, an active toggle, and all standard Malbers condition types. Rendered as a live IMGUI property drawer directly inside the node. | #### Target Resolution Order At runtime, `DialogueManager` resolves the evaluation target in the following priority order: 1. **Explicit Target** — the `GameObjectVar` assigned to this node, if it has a valid runtime value. 2. **Player** — the player GameObject from `QuestManager.Instance.playerTransform`, if no explicit target is set. 3. **DialogueManager** — the `DialogueManager` GameObject itself, used as a last-resort fallback. > **Note:** `GameObjectVar` is used here (rather than `TransformVar`) because the Conditions2 block must be hosted inside a ScriptableObject for proper serialization, which requires a ScriptableObject-compatible variable type. *** ### How It Works At runtime, `DialogueManager.ProcessTrueFalseNode()` calls `EvaluateCondition()`: 1. If the `Conditions2` block is **inactive** or has **no conditions configured**, the result defaults to `true` and the **True** path is followed immediately. 2. Otherwise, the resolved target GameObject is passed to `Conditions2.Evaluate(targetObject)`. 3. The result (`true` or `false`) selects the corresponding output port by **name** — matching `"True"` or `"False"` on the outgoing edge's port name, not by list order. 4. The graph jumps to whichever node is connected to the matching port. If the matching port has no connection, `DialogueManager` logs an error and calls `EndDialogue()`. *** ### Supported Condition Types The Conditions2 block supports all standard Malbers condition types, including the three custom QuestForge conditions: | Condition | Description | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------- | | **C2\_DialogueFlag** | Checks a named boolean flag stored on `DialogueManager`. | | **C2\_DialogueInt** | Checks a named integer variable stored on `DialogueManager` against a value (equal, greater, less, etc.). | | **C2\_DialogueString** | Checks a named string variable stored on `DialogueManager` against a value. | | *(All standard Malbers Conditions2 types)* | Quest state, animal state, stats, distances, tags, components, and more. | Multiple conditions can be combined with **AND** / **OR** logic within the same block. *** ### Validation | Condition | Severity | | ---------------------- | -------- | | No incoming connection | Warning | | No outgoing connection | Warning | > Neither a missing **Target** nor an empty **Conditions** block is flagged as an error — an empty or inactive conditions block simply defaults to `true` at runtime, which is a valid design for a node that conditionally routes only under specific circumstances. *** ### Usage Tips * **Quest state gating** — use the standard Malbers `C2_QuestState` condition (or equivalent) to check whether a quest is active, complete, or not started, and route the NPC's dialogue to an appropriate branch accordingly. * **Dialogue flags for conversation memory** — set a `DialogueFlag` using a **Malbers Event Node** or code earlier in the conversation (or a previous session), then check it here with `C2_DialogueFlag` to detect whether the player has spoken to this NPC before. * **No target needed for dialogue variables** — `C2_DialogueFlag`, `C2_DialogueInt`, and `C2_DialogueString` read directly from `DialogueManager` and do not require a **Target** to be assigned. * **Default to True when empty** — if the Conditions block is left inactive or empty, the node always follows the **True** path. This can be used temporarily during graph construction as a passthrough before conditions are fully configured. * **Single input port** — unlike most nodes, this node only accepts one incoming connection. If you need multiple paths to converge into a single condition check, route them through an intermediate node first. * **Port routing is by name** — the **True** and **False** edges are matched by their port name at runtime, not by their serialization order. Re-wiring edges in the graph will not break routing as long as the port names remain correct.