# The Bootflow Subsystem

## Summary

When the client (& server) start up, they advance through a state machine in `J_BootflowSubsystem`. This subsystem ensures that the initialization of various systems happens in the correct order. It offers a selection of delegates that can be used to be notified about how far the bootflow has advanced.

When in doubt, the most appropriate of these to use is `HandleBootflowFinished`, which will trigger once all the bootflow steps have been achieved.

<figure><img src="https://1456550285-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoWTlPaoHd1McSakqMigu%2Fuploads%2Fgit-blob-81b8bf5d7bf38180580f8355f28663d39b97f119%2Fimage.png?alt=media" alt=""><figcaption><p>The most common use case in BP - wait for the bootflow to be finished, in <code>BeginPlay</code> (or <code>MorpheusBeginPlay</code>), and do your logic in the callback</p></figcaption></figure>

### Delegates on J\_BootflowSubsystem <a href="#delegates-on-j_bootflowsubsystem" id="delegates-on-j_bootflowsubsystem"></a>

These are the events you can hook into. They work similarly to startup handlers used to work, i.e. you attach an event in BP which is executed once that state has been reached. Each subsequent event contains all the ready conditions of the previous event.

* `HandleBootflowStarted`\
  The earliest event.
  * The HUD is ready to use
  * [live-config](https://docs.msquared.io/creation/unreal-development/features-and-tutorials/live-config "mention") GameData (i.e. LiveConfig) is available
* `HandleLegalScreensCompleted`\
  \&#xNAN;*Auth client only. GameLaunch level only*\
  This happens after all the legal screens (like EULA, photosensitivity warning etc.) have been displayed. Only happens in the `GameLaunch` level
  * The legal screen widget is shown by the startup map listening to `OnShowLegalScreens`.
  * Once the legal screens have been completed, `SetLegalScreensCompleted` is called to proceed to the next step.
  * This flow can be skipped by setting the `Bootflow.SkipLegalScreens` live config flag to `True` (this is the current default)
* `HandleCommonActorsSpawned`\
  At this point it’s likely that most Morpheus actors put into the level are available. However, currently we only give guarantees about the singleton actors that are configured in the WorldSettings. (See [singletons](https://docs.msquared.io/creation/unreal-development/features-and-tutorials/singletons "mention"))\
  At this point we’re also signed in with the player’s user account.
* `HandleSpawningUnlocked`\
  \&#xNAN;*Auth client only*\
  Spawning is now available. This depends on whether you have set `RequireManualSpawnRequestUnlock` in your world settings.
  * If this setting is false (which is default), this is called automatically directly after `HandleCommonActorsSpawned`.
  * If this setting is true, you need to call `UnlockSpawning` on the BootflowSubsystem first which then triggers `HandleSpawningUnlocked` and progresses the state machine.
  * This is useful if e.g. spawn points can be set based on an activity which streams in a sublevel and you need to wait for the sublevel to be loaded before collision is available.
* `HandleAuthMorpheusActorSpawned`\
  \&#xNAN;*Auth client only*\
  The player’s MorpheusActor has been spawned (of type `AMorpheusPawnActor`)
* `HandleAuthRenderTargetPawnSpawned`\
  \&#xNAN;*Auth client only*\
  The player’s pawn has been spawned (the RenderTargetActor for the player’s MorpheusActor). At this point the pawn is guaranteed to exist, but it’s not possessed yet.
* In release v37 onwards, custom bootflow steps can be injected here. For more details, see [#adding-custom-steps-to-the-bootflow](https://docs.msquared.io/creation/unreal-development/features-and-tutorials/the-wait-for-condition-system#adding-custom-steps-to-the-bootflow "mention")
* `HandlePlayerProfileCompleted`\
  \&#xNAN;*Auth client only*\
  The player’s profile has been set.
  * This will automatically pass if the `ShowPlayerProfileSetup` live config flag is `False`
  * Otherwise, `OnRequestProfileSetupScreen` will be called here, which can be bound to to spawn a widget, or other logic that enables the user's profile setup.
  * Once that is completed, the flow must call `SetProfileSetupScreenCompleted` to proceed to the next step.
* `HandleFadeIn`\
  \&#xNAN;*Auth client only*\
  The world is ready to show. The player camera manager uses this to initially fade in the camera. If an intro sequence is to be played, this happens now.
* `HandleBootflowFinished`\
  The player’s pawn has been possessed, the player has full control. This is the final bootflow event. Trying to get a MorpheusActor from the PlayerController is now safe but only on **player clients**. Bot clients will always fail this!

When in doubt, `HandleBootflowFinished` is appropriate for most situations in Blueprint.