Skip to main content
Flow Core Documentation
Menu

Debug and Maintain Projects

Questions & Answers

Find concise answers to common Flow Core setup, graph, data, module, scripting, debugging, and update questions.

Audience
All developers
Time
As needed
Requires
None
Modules
Flow Core
On this page

Use this page to resolve a common decision quickly, then follow the linked guide when you need a complete workflow or behavior contract. For a reproducible failure, start with Troubleshooting instead.

Browse by topic

Getting Started

Where should I start after installing Flow Core?

Complete Install & Verify to establish a known-good authoring baseline. Then open Explore a Working Flow to observe a complete runtime path and finish Build Your First Flow to create one visible result. Choose a larger architecture only after this path works.

Do I need C# to use Flow Core?

No. You can assemble supported Triggers, nodes, Instructions, Conditions, and typed values without writing code. Use C# when your project needs a custom operation, decision, event source, or external-system bridge. Start with Build Your First Flow, then use the Scripting guides only when the built-in authoring surface does not own the required behavior.

Which logic model should I choose?

Use normal Flow for a known event sequence, FSM for one persistent active mode, Behavior Tree for repeated priority decisions, Stack for temporary layers that resume in reverse order, and GOAP for a plan discovered from facts and costs. Choosing a Logic Model provides the complete decision table and composition boundaries.

Which Flow Core modules do I need?

Adopt only the capability your project needs. Flow Character owns movement and animation behavior, Flow Camera owns Shot selection, Flow Interaction owns candidate and focus routing, and Flow Stats owns calculated values and effects. They remain independent modules and can connect through normal Flow when a visible sequence crosses ownership boundaries. See Gameplay Module Architecture.

Graphs & Runtime

What is the difference between a Flow Graph and FlowCoreProcess?

A Flow Graph is the reusable asset that stores authored nodes, connections, and settings. FlowCoreProcess is the scene component that assigns that graph, builds its runtime, binds Local Blackboards, and exposes public Entry calls for one GameObject. Graph Assets & FlowCoreProcess explains what belongs in authoring data and what belongs in the runtime owner.

Can multiple GameObjects use the same Flow Graph without sharing runtime state?

Yes. Every FlowCoreProcess builds its own runtime, so active chains and current execution state stay independent even when several objects reference one graph asset. Keep per-object values in Local Blackboards or another explicit runtime owner. Editing the shared graph still changes authored behavior for every process that uses it. See Graph Assets & FlowCoreProcess.

Why does my graph not start?

First confirm that the intended FlowCoreProcess is enabled, references the graph you opened, and has its required Local Blackboards bound. Then verify the exact Trigger or Entry, the first connection, and any Guard that can reject execution. Use Troubleshooting for symptom-based checks or Debugging Running Graphs for a complete trace.

Data & Lifetime

When should I use a Blackboard?

Use a Blackboard when a value should be named, typed, inspectable, and available beyond one event call. Choose Local for one process, Scene for intentional scene-wide sharing, and Global only for broader application ownership. The complete path includes scope, Blackboard index, key, and type. See Blackboard & Typed Values.

What is the difference between payload and TempPayload?

payload is read-only event data supplied by the Trigger, Entry, or signal that starts a chain. TempPayload is writable scratch data produced and consumed within that same chain, then cleared when the chain ends. Store state that must outlive the chain in a Blackboard. See Triggers, Entries & Payloads.

How should I share data without relying on accidental global state?

Start with the narrowest owner. Keep object-specific state in a Local Blackboard, share scene facts through an intentionally selected Scene Blackboard, and reserve Global scope for data that truly belongs to broader application flow. A module or external system should keep values it natively owns and expose them through a supported handoff. See Blackboard & Typed Values.

Scripting & Persistence

How can C# or a third-party system interact with Flow Core?

Call a named Entry through the intended FlowCoreProcess when C# owns activation timing. For another package, translate its state or callback through a typed Blackboard, event, named Entry, or supported graph-selection boundary while keeping one source of truth. Use Running Graphs from C# and Integrating Third-Party Systems.

How do I create custom Instructions or Conditions?

Create an Instruction for a project-specific operation that performs work and returns an intentional result. Create a Condition for a typed pass/fail decision without gameplay side effects. Keep both in runtime assemblies, clone serialized data correctly, and use the supported registration pipeline. Follow Authoring Custom Instructions and Authoring Custom Conditions.

How do I save and restore runtime state?

Enable Persistence on the Blackboard owners that should survive a scene or play session, then save and load the same slot through Flow Core’s supported save channel. Restore supported captured state to the intended owners after any required scene barrier. Save does not resume an arbitrary graph at an exact Instruction. Follow Save & Restore Runtime State.

Help & Updates

Where should I look when something is not working?

Use Debugging Running Graphs when you need to trace runtime owner, start point, Branch, result, and typed value path. Use Troubleshooting when you already have a visible symptom. For Profile, validation, override, or live-value problems in Flow Stats, use Troubleshoot Flow Stats.

Where can I review changes, report an issue, or get help?

Use Release Notes to review user-visible additions, fixes, compatibility notes, and upgrade boundaries by version. The shared footer on every documentation page provides Tech Docs for deeper contracts, Join Discord for community help, Report a Bug for reproducible defects, and Request a Feature for proposed capabilities.