# Setup Play-in-Editor Setting up the common classes The assets present in Morpheus Platform are read only - in a downstream project, you cannot modify them, only extend from them, or use them as reference. Therefore if you want to modify different classes' behavior, or add extra functionality, you will need to make your own versions of the assets and use them instead. There are different ways of doing this: ### Play settings Please ensure these settings are configured.] 1. From your editor, select the `Play` drop-down. Then select `Advanced Settings...`

2. Ensure the following advanced settings are configured 1. In **Additional Launch Parameters** enter `-LocalDeployment` 2. Set **Launch Separate Server** to **✔️** 3. Set **Play Net Mode** to `Play Standalone` 4. Set **Run Under One Process** to **✔️**

### Using the template project If you create your project using the `M² Base Project`, the majority of commonly overridden assets will be already made for you, e.g. `BPM_Example_PlayerCharacter`. These will be writable, renamable etc. so can act as a starting point for your project. For further details of this flow, see [Using The Template Project](https://docs.msquared.io/creation/unreal-development/getting-started/using-the-template-project). ### Summary When making a new project using the Morpheus Platform defaults, the following is a list of classes to consider making your own versions of, to extend the Morpheus Platform functionality whilst adding your own: {% hint style="info" %} The assets below are what are made automatically for you by [using the template project](https://docs.msquared.io/creation/unreal-development/getting-started/using-the-template-project), so the simplest flow would be to start from there. {% endhint %}

Asset to override	Copy or Inherit?	Where to apply?
`BP_M2Example_GameMode`	Inherit	Project Settings -> Default GameMode, or World Settings -> GameMode Override
`BP_M2Example_PlayerController`	Inherit	In the Game Mode (`Player Controller Class`)
`BPM_M2Example_PlayerCharacter`	Inherit	In the Game Mode (`Player Morpheus Actor Class`)
`BP_M2Example_PlayerCharacter`	Inherit	Either via the Game Mode (`Default Pawn Class`), or via the role's pawn set asset (see the further details)
`BP_M2Example_HUD`	Either	In the Game Mode (`HUD Class`)
`M2M_MorpheusGameState`	Inherit	In the Game Mode blueprint (`Morpheus Game State Class`)
`WBP_M2Example_HUD`	Copy	In your HUD BP

### In more detail: * The GameMode: This configures a bunch of the classes used in your level, e.g. the player controller and HUD classes outlined below. If you want to make a new game mode, it should extend `BP_M2Example_GameMode` * To apply your game mode, you can either modify per-level in your world settings, or modify the default in your project settings -> Maps & Modes.

#### The Character: * The PlayerController: Should extend `BP_M2Example_PlayerController`. * The Morpheus Actor: The representation of a client's character that is used for replication. Should extend `BPM_M2Example_PlayerCharacter`.

* The Render Target Actor(s): The actual character spawned in-game to represent a player. Should extend `BP_M2Example_PlayerCharacter` * If you want to add further customization to the pawns used, e.g. wanting different roles to have different pawns, or want to make changes to the "animated crowd", you can configure them in your roles table's pawn set asset (the `Pawn Lod Level Set` field): * For a given role, its `PawnLodLevelSet` controls what render target is used.

* If you make a new pawn set asset (copying the existing one), you can swap out its `Base Pawn` and LOD0 `Actor Class`

* The UI: * The HUD BP: The logic responsible for spawning the HUD, and managing our UI. An example has been made in `BP_M2Example_HUD`, which can be used as an example that can either be copied or extended. * The HUD WBP: The actual HUD widget that contains the in-game UI. To use your own HUD widget, we recommend making a copy of `WBP_M2Example_HUD` as a starting point.\ To use your new HUD, you can change the Game Layer Class in your HUD BP. {% hint style="info" %} There are some other base classes in msquared that can be used as valid starting points, such as accessing the C++ directly (via `PlayerController`, `M2_CharacterBase` or `M2M_CharacterBase`). However, these will be missing some of the expected Origin features, so only use these if you really know what you're doing. {% endhint %} ### Setting up the map When making a new map, check the world settings, to make sure everything is as expected: * The GameMode Override: Make sure it points to your new game mode * The Roles table: You can configure the default role, and the roles table used here

* The Singletons: There are a number of singleton actors that are spawned when the game is started, and enable various bits of Origin functionality. For more details on these, see [singletons](https://docs.msquared.io/creation/unreal-development/features-and-tutorials/singletons "mention").

The MorpheusGameState class: This game state is similar to the unreal native game state, but with the benefit of being replicated by morpheus. Use this instead of unreal's game state To set it up, go to your GameMode blueprint class and set it in the dropdown

To retrieve the morpheus game state, use the GetMorpheusGameState function ### Changing animations Your characters' animations are controlled in the `ABP_M2_Human`. Making changes to your Animation Blueprint in a downstream project is unfortunately quite an involved process currently compared to native Unreal, due to needing to be applied to both actor render targets and the animated crowd. If you do want to do this, please get in touch! ## Configuring to use MMLs There are a currently a few workarounds required for full functionality (especially related to MMLs) when using Play-in-Editor functionality. {% hint style="info" %} The following sections are current required to place MMLs when in Play-in-Editor mode - this requirement will be removed in a future update. {% endhint %}

### Ensure you're using the correct game mode You need to be using the `BP_Origin_GameMode` (configurable via world settings), or a game mode that is a child of this. {% hint style="info" %} You may need also need to add this change to the template maps: `InfinitySpace` and `Meadow`. A fix for this will be rolled out in a future release. {% endhint %} ## Configuring Sign-in Settings {% hint style="info" %} You can find the current sign-in settings by navigating to `Editor preferences > General > Sign in settings` {% endhint %} When you first download the editor and create a new project, your sign-in settings will be configured such that you can immediately start PIE with no other modifications. This section will outline how you can configure your sign-in settings to have more control over how your individual clients and server authenticate. {% tabs %} {% tab title="Settings" %} | Setting name | Description | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Offline Mode |

Skips server and client authentication. When enabled you will not have account information and will not be capable of interacting with the Morpheus platform backend.

This is a good fallback if you experience authentication errors and just need to run PIE to test non-authenticated actions.

Default value: false.

| | Per Client Sign in Settings |

The sign in method and parameters to be used by the spawned clients. You must have at least as many configured Per Client Sign in Settings as clients you will be launching in PIE.

Default value: 4 clients configured to sign in with SSO.

| | Trusted Client Api Key |

The Api key used to authenticate your local trusted clients (e.g., Sentinel and Remote Viewer).

This is an internal-only feature.

| | Use Local Bot Api Key |

Determines whether locally spawned bots should authenticate.

This is an internal-only feature.

Default value: false.

| | Local Bot Api Key |

The Api key used to authenticate local bots.

This option is only available when Use Local Bot Api Key is enabled

This is an internal-only feature.

| | Use Transient Users for Bots |

Determines whether the authenticated locally spawned bots should be granted a user account.

This option is only available when Use Local Bot Api Key is enabled.

This is an internal-only feature.

Default value: false.

| | Transient User Allocation Token |

The allocation token used to request user accounts for the locally spawned bots.

This option is only available when Use Transient Users for Bots is enabled.

This is an internal-only feature.

| | Use Local World for PIE |

When this is enabled, the user will be granted a local world context which persists between PIE sessions. It is analogous to a deployed world and can be used to test any requests and functionality made with World scope.

When Server Uses Client Sign in Settings for PIE is disabled, the server will fall back to authenticating with SSO.

Default value: true.

| | Server Uses Client Sign in Settings for PIE |

When enabled, the server will sign in with the sign in method and credentials defined by the first Per Client Sign in Setting .

Default value: true.

| | Client Sign in Stall Method |

Advanced feature.

Users can create a blueprint inheriting from J\_SignInStallMethodCommon which will allow them to pause bootflow during sign-in until some condition is met.

| The default settings are shown below

Below are some common sign-in setups and the setting modifications from the default settings to use them | Setup | Server/Client Behaviour | Notes | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Default |

Server and up to 4 clients will use SSO and share credentials.

If you do not have credentials saved in the credential manager from a previous PIE instance, the server will authenticate first (prompting SSO popup that you must confirm). The credentials will then be saved and the clients will authenticate.

| | |

Offline Mode

- Enable Offline Mode

| Server and Client will both skip authentication. | Things may break! As servers and clients in offline mode are not able to perform authenticated actions we don't guarantee all features will work as expected. | |

Bearer token

- Change the Per Client Sign in Settings Type to User Supplied Bearer Token
- Paste a bearer token into the field

| The server and clients will all authenticate with the supplied bearer token. This setup will completely avoid SSO requiring no saved credentials and no prompt window. |

Bearer tokens are only valid for 1h. Once your token expires, requests and logins will fail until you supply a new bearer token.

Clients and server can share the same bearer token.

| |

Api key

- Disable Use Local World for PIE.
- You will need to perform Editor sign-in

The server will authenticate with Api key.

Clients will authenticate with the configured Per Client Sign in Settings.

Your PIE session will not have a world context to make requests from. This can lead to errors for actions and requests requiring a World scope.

This was the default server sign-in method prior to local worlds. It can serve as a good fallback if you see sign-in errors related to the local world.

| | {% endtab %} | | | | {% endtabs %} | | | ### Local world authentication By default, PIE sign-in is configured to use local-worlds. This requires no configuration by the user and should work immediately. You can check whether this setting is enabled by navigating to `Editor preferences > Sign in settings > Use Local World For PIE`. {% hint style="warning" %} If you disable this setting, you will need to [Set up server credentials](#set-up-server-credentials). {% endhint %} ### Set up server credentials {% hint style="info" %} This is only relevant if you don't have [local world authentication](#local-world-authentication) enabled. {% endhint %} In Editor Preferences, in the `Sign-in settings` section, change your settings to reflect the following where: * `Offline Mode` is NOT ticked In the Editor, click on the "Editor Sign In" button on the toolbar {% hint style="info" %} The Editor Sign In button will only appear if [Local world authentication](#local-world-authentication) is not enabled {% endhint %}

You will be requested to sign in with your Google Account in your main system browser. Once complete, you will be presented with a list of api keys:

The name will depend on the key your organization admin set up. Select the key they instructed you to use and click "ok". ### Set up client credentials In Editor Preferences, in the `Sign-in settings` section, change your settings to reflect the following where: * `Offline Mode` is NOT ticked * The `Per Client Sign In Settings` property has the `Single Sign On` element