# The "Wait For Condition" System

## Summary

This is a simple system to allow people to wait for conditions, and mark when they have been met or updated.

Each condition has a "name" - if you mark a condition with that name as "met", then any listeners of that condition name will be notified (and any subsequent users who listen to a condition that has already been met will be notified immediately).

You can also optionally include a generic object with a certain condition, e.g. if you want to wait for a certain actor to be ready, you can have a "OnActor\[X]Ready" condition, and listeners will be informed both of when the actor is ready, and what the actor is.

## Usage

Includes the following helper functions:

* `WaitForCondition`: A simple "wait for condition" - provide a condition name and a "On Condition Met" event, and it will trigger the event once the condition has been marked as done (via MarkConditionMet), or will trigger immediately if the condition has already been marked as done.
* `WaitForCondition_WithResultObject`: Same as "WaitForCondition", but will also provide a "Result Object" associated with the condition, in the "On Condition Met" event.
* `ListenToConditionUpdates`: Same as WaitForCondition\_WithResultObject, but also listens to any subsequent updates to the "Result Object". (This will call the "On Condition Met" event immediately if the "Result Object" has already been provided via an earlier MarkConditionMet\_WithResultObject, and then again every subsequent time)
* `WaitForConditions`: Same as WaitForCondition, but takes a list of condition names, and only triggers if/when they have all been met.
* `MarkConditionMet`: Call this to mark a condition as having been "met", triggering any listeners waiting on the condition.
* `MarkConditionMet_WithResultObject`: Same as MarkConditionMet, but provides a "Result Object". This will trigger any listeners waiting on the condition, or having its result object updated.\
  NOTE: This can be called multiple times with the same condition name to update the current "Result Object" associated with that condition.
* `GetMetConditions`: Returns the list of all conditions that have been met so far
* `HasMetCondition`: Returns true if the provided condition name has been marked as "met"
* `GetConditionResultObject`: Returns the current object for the provided condition name.

<figure><img src="/files/RUIiURglhQ4borHinOZ9" alt=""><figcaption><p>An example of a "skins system", that provides the starting skin asset on <code>BeginPlay</code> (providing the condition with the <code>SkinConditionName</code> with the <code>SkinAsset</code>), and informs the condition system whenever the asset is updated.</p></figcaption></figure>

<figure><img src="/files/DdclxBBQaOTuf2XENMOI" alt=""><figcaption><p>Examples of listeners to the condition system - you can listen to updates of a condition, e.g. listening to whenever the <code>SkinAsset</code> from the earlier example updates, or listening to when multiple conditions have been marked as met, to implement a basic bootflow system.</p></figcaption></figure>

## Adding custom steps to the bootflow

{% hint style="info" %}
This functionality is present in release v37 onwards
{% endhint %}

If you want to add custom steps to the [The Bootflow Subsystem](/platform-documentation/creation/unreal-development/features-and-tutorials/helpers-and-extras/the-bootflow-subsystem.md), this can now be done, using the `CustomBootflowConditions` world settings. These will be injected to the end of the bootflow, immediately before "Bootflow Finished" on the server, and before "Profile Setup" (and "Fade In") on the client. You can use this to therefore inject your own steps to the bootflow, which you can guarantee will all be met in the `HandleBootflowFinished` step.

<figure><img src="/files/yZIFH9EZSVzDMQDk7XRM" alt=""><figcaption><p>An example with 2 added steps to the bootflow</p></figcaption></figure>

{% hint style="info" %}
NOTE: Currently the system runs the same custom bootflow conditions on all machines, i.e. all types of clients (bots included) and the server. If you have a condition . One way of doing this would be to "early out" your conditions on machines where it wouldn't do anything, or alternatively, you could make each machine wait for different conditions to trigger the same final condition that is what the bootflow listens to (see image below):
{% endhint %}

<figure><img src="/files/TQISoCrXCS6DprXepNtA" alt=""><figcaption><p>An example of having different conditions on the client and server - both will wait for <code>CoreGameplayMechanics</code>, but only the client will wait on the <code>HUD</code> and <code>Skins</code>, and only the server will wait for <code>ServerOnlySetup</code>. When their respective conditions are met, both will then mark <code>AllCustomStepsComplete</code>, and so unlock the bootflow</p></figcaption></figure>


---

# 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://docs.otherside.xyz/platform-documentation/creation/unreal-development/features-and-tutorials/helpers-and-extras/the-wait-for-condition-system.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.