The "Wait For Condition" System

This feature is present in release v30 onwards.

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.

An example of a "skins system", that provides the starting skin asset on BeginPlay (providing the condition with the SkinConditionName with the SkinAsset), and informs the condition system whenever the asset is updated.

Examples of listeners to the condition system - you can listen to updates of a condition, e.g. listening to whenever the SkinAsset from the earlier example updates, or listening to when multiple conditions have been marked as met, to implement a basic bootflow system.

Adding custom steps to the bootflow

This functionality is present in release v37 onwards

If you want to add custom steps to the The Bootflow Subsystem, 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.

An example with 2 added steps to the bootflow

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):

An example of having different conditions on the client and server - both will wait for CoreGameplayMechanics, but only the client will wait on the HUD and Skins, and only the server will wait for ServerOnlySetup. When their respective conditions are met, both will then mark AllCustomStepsComplete, and so unlock the bootflow