# Graph Editor

Level: Beginner

## Goal

Build and inspect a Flow Graph visually: add nodes, connect ports, configure values, read summaries, and keep the graph understandable while it grows.

## When To Use This

Use this page when you are working inside the Flow Graph editor and need to know what each authoring action changes. For the full scene-to-Play-Mode loop, use [Editor Workflow](/flow-core-docs/documentation/editor-guide/editor-workflow.md).

## Prerequisites

* A Flow Graph asset exists.
* You can open the Flow Graph editor.
* A `FlowCoreProcess` is available when you want summaries or visual debugging to resolve scene data.

## Where To Find It

Open the editor from `Tools/Flow Core/Flow Graph Editor`, or open a Flow Graph asset directly when your Unity layout supports it.

The main areas are:

| Area             | Purpose                                                                           |
| ---------------- | --------------------------------------------------------------------------------- |
| Canvas           | Place nodes, route connections, organize comments, and read graph flow.           |
| Header / Toolbar | Select graph-level tools, set Debug Context, and control editor display.          |
| Inspector        | Edit the selected node, instruction, condition, value, Guard, or module settings. |
| Node body        | Read configuration sections, ports, summaries, comments, and value previews.      |

## Workflow

1. Set the graph and context.

   Open the graph asset you want to edit. If the graph reads scene data, set **Debug Context** to the GameObject that owns the matching `FlowCoreProcess`. Without Debug Context, the graph can still be edited, but Local and Scene value summaries may not resolve.
2. Add a start node.

   Start simple. Add a `Trigger` when Unity lifecycle, input, UI, timer, or event bus data should start the chain. Add an `Enter` node when the graph should be called by name from code, another graph, or a module.
3. Add work nodes.

   Right-click the canvas and search by node name or behavior. For visual authoring, prefer the smallest node chain that gives observable feedback before adding branches. If the search list is too broad, use more specific words from the node name or category.
4. Connect ports.

   Drag from an output port to a compatible input port. Flow ports describe execution order. BT child ports describe Behavior Tree child order. Control inputs such as Enable, Disable, Abort, and Invalid are signals into an existing node, not normal "continue here" flow.
5. Configure values in the Inspector.

   Select a node and edit its fields. For instructions and conditions, choose whether each value comes from Literal data, Blackboard data, payload, TempPayload, or a target resolver. Use exact Blackboard key spelling and the intended scope.
6. Read summaries and values.

   Turn on Summary and Value detail while authoring data-heavy nodes. Summary should tell you what the node will try to do; Value detail should help you spot unresolved keys, wrong scopes, or suspicious literal defaults.
7. Use comments for intent.

   Add comments to explain gameplay rules, not just node mechanics. Good comments say why the graph does something, which branch owns a responsibility, or which Entry name another system depends on.
8. Collapse after the path works.

   Collapsing a node hides configuration detail but keeps ports visible. Use collapse to reduce visual noise after the chain is tested, not before you understand why it works.
9. Verify in Play Mode.

   Keep the graph editor open, set Debug Context to the runtime owner, then enter Play Mode. Trigger the behavior and watch visual debugging, summaries, Console output, and Blackboard values.

## Authoring Notes

### Node Search

* Use short, specific words such as `Trigger`, `Log`, `Blackboard`, `Sequence`, `Selector`, or `Cooldown`.
* Dragging from a port can open a creation menu filtered to compatible node targets.
* If search results feel too flat or too broad, review `SearchFlatResultsThreshold` in Flow Core Settings.

### Port Reading

* Main Flow connections read left to right best.
* A disconnected output means the chain stops at that branch.
* A disconnected required input means the node cannot be reached from that path.
* BT child order is meaningful. Earlier children are usually higher priority.

### Control Inputs

Flow nodes with control inputs expose Enable, Disable, Abort, and Invalid in a dedicated section. `BTRoot` also exposes Flow control inputs. BT non-root nodes do not expose these control inputs.

Enable and Disable toggle the node's Pass Enabled gate. This does not change the node Enabled flag. When Pass Enabled is off, incoming chains end as Invalid and the node does not execute.

Abort and Invalid control inputs affect matching active chains. Use them intentionally when another path needs to stop or invalidate currently running work.

### Behavior Tree Branches

To create a BT branch, add a `BTRoot`, connect a Flow chain into its Active control input, add child outputs, connect those child outputs to BT nodes, then route BTRoot Success and Failure outputs back into Flow.

For reusable BT work, use `BtSubGraph`, assign a Flow Graph asset, select the BTRoot inside that graph, then use Open Graph and the breadcrumb controls to inspect and return.

## What Changes

* Adding, moving, connecting, renaming, and configuring nodes changes the graph asset.
* Setting Debug Context changes editor preview only.
* Enabling or disabling display toggles changes what the editor shows, not runtime behavior.
* Editing values that point to Blackboard keys changes node configuration, not the Blackboard key itself.

## Verify the Result

You are using the editor correctly when:

* The graph has a clear start node.
* Each visible chain has connected ports from start to result.
* Key nodes show useful summaries.
* Blackboard value fields resolve against the selected Debug Context.
* The graph remains readable after collapse, comments, and branch organization.

## Common Mistakes

* Creating work nodes without connecting a Trigger, Entry, or module root.
* Connecting Flow outputs into BT child ports or reading BT child order as decoration.
* Editing a value source but forgetting to create the matching Blackboard key.
* Leaving Debug Context empty while expecting Local Blackboard summaries.
* Collapsing nodes before verifying their value bindings.
* Using Abort or Invalid control inputs as normal sequence connections.

## Related

* [Editor Workflow](/flow-core-docs/documentation/editor-guide/editor-workflow.md)
* [First 15 Minutes](/flow-core-docs/documentation/tutorials/first-15-minutes.md)
* [Behavior Tree Authoring](/flow-core-docs/documentation/gameplay-modules/behavior-tree-authoring.md)
* [Detail Level Toggles](/flow-core-docs/documentation/editor-guide/detail-level-toggles.md)
* [Debug Context](/flow-core-docs/documentation/editor-guide/debug-context.md)
* [Invoke and Reject Modes](/flow-core-docs/documentation/reference/invoke-and-reject-modes.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://flow-core.gitbook.io/flow-core-docs/documentation/editor-guide/graph-editor.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.