> For the complete documentation index, see [llms.txt](https://docs.otherside.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.otherside.xyz/odk-docs/odk-plugin/task-flow/setup-guide.md). # Setup Guide This guide walks through how to set up a new flow. *** #### 🎭 Step 1: Place the Task Flow Actor Start by placing a `BP_ODK_TaskFlow` actor in your level.

This actor is responsible for: * Initializing the flow * Coordinating triggers, conditions, tasks, and actions * Tracking and updating the flow's progression It is placed in the level as an actor so that only tasks that can be completed in the current map are shown on the HUD. You’ll configure a few key variables on this actor: * **`WaitForBootflowToFinish`** – Whether to wait for bootflow before initializing * **`TriggerDelay`** – Optional delay (in seconds) before the flow begins * **`FlowTrigger`** – The executor that kicks off the flow (see below) * **`TaskFlowDataAsset`** – The asset that defines your actual tasks and logic *** #### 🎯 Step 2: Assign a Flow Trigger

The **FlowTrigger** variable must be set to an executor that inherits from `BP_ODK_FlowTrigger_ExecutorBase` or `BP_TaskFlowTrigger_TokenId` when setting up a Quest. The `InitializeTaskFlowExecutor` event should be used as you would `BeginPlay`, to set up the trigger and make bindings etc.

Once your trigger logic finishes, it must call `FlowTriggerCompleted`

This tells the system: * **Where to start** (via Task Index, e.g. resume from save) * **How to proceed** (StartFlow, RetryFlow, CompleteFlow) You can use an existing trigger executor or make your own to suit your feature. *** #### 📦 Step 3: Create and Configure the Task Flow Data Asset Create a new data asset that inherits from `PDA_ODK_TaskFlow`. This defines the structure and logic of your flow. Inside the asset, configure: * **Flow Name** * **Conditions** – (flow-level)

* **Tasks** – An array of individual task executors * **Retry** – Optional executor to handle retry logic * **Actions** – Optional logic fired at various moments * **Custom Details** – Optional data for flow-specific needs This asset is what makes the flow dynamic and reusable. *** #### 🧩 Step 4: Define Each Task Each task should be a class derived from `BP_ODK_TaskFlow_Task`. You’ll configure: * Whether the task is enabled * Optional conditions (task-level) * One or more **Complete Task Triggers** * *This is the most important step. The Complete Task Triggers contain all the logic to define if the task is complete* * Optional **Startup Delay** * Optional **Actions** tied to task lifecycle Each task should: * Implement `InitializeTaskFlowExecutor()` * Call `TaskTriggerExecutionComplete()` when finished *** #### 🔁 Step 5: Add Retry Logic (Optional) If your flow should support retries (e.g. when a player fails, cancels or completes the flow), create a retry executor that inherits from `BP_ODK_RetryTaskFlow_ExecutorBase`. This executor: * Is triggered after a FlowTrigger completes with a retry state * Should call `RequestRetryTaskFlow()` when ready to restart You can implement logic like displaying a retry prompt or auto-restarting silently. *** #### ⚙️ Step 6: Add Actions (Optional) Actions are “one-shot” events that happen at defined flow or task points. To create one, derive from `BP_ODK_TaskFlowAction_ExecutorBase`, and implement `InitializeTaskActionExecutor` Attach them to: * Task-level or flow-level lifecycle events * Visuals, sound effects, UI, cleanup, etc. These don’t block progression and are never cached. *** #### 🧪 Debugging Enable verbose output with the **live config** value `ODK.TaskFlows.LoggingEnabled` This will print task and flow events to the log, which is helpful when troubleshooting setup issues. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.otherside.xyz/odk-docs/odk-plugin/task-flow/setup-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.