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.

The most common use case in BP - wait for the bootflow to be finished, in BeginPlay (or MorpheusBeginPlay), and do your logic in the callback

Delegates on J_BootflowSubsystem

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 GameData (i.e. LiveConfig) is available

• HandleLegalScreensCompleted 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) At this point we’re also signed in with the player’s user account.

• HandleSpawningUnlocked 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 Auth client only The player’s MorpheusActor has been spawned (of type AMorpheusPawnActor)

• HandleAuthRenderTargetPawnSpawned 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
• HandlePlayerProfileCompleted 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 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.