IPIEAuthorizer should have access to FRequestPlaySessionParams

Development Pipeline & Plugins
, ,
1

IPIEAuthorizer’s first parameter is a flag for whether it’s play or simulate, but it’s called from StartPlayInEditorSession which has access to the full FRequestPlaySessionParams struct (including the Simulate flag). Getting access to this (mostly for the actual LevelEditorPlaySettings) would be helpful to allow us to implement extra logic on the PIEAuthorizer.

As a stretch, I’d suggest making it modifiable as the LevelEditorPlaySettings are modified in StartPlayInEditorSession - this would let us auto-configure things on our side, just like the engine is doing, but I think naming that IPIEAuthorizer islikely not right, hence it being a stretch goal.

We’ve implemented this change on our project by simply changing IPIEAUthorizer to

virtual bool RequestPIEPermission(FRequestPlaySessionParams& PlaySessionParams, FString& OutReason) const = 0;

And changing one call site to

if (!Authority->RequestPIEPermission(InRequestParams, DeniedReason))
2

Steps to Reproduce

3

Hello, wanting access to those parameters in RequestPIEPermission is reasonable, but typically we do a multiple engine versions long deprecation path to change signatures of public functions and interfaces. We’re not going to make the change primarily due to that overhead, but I encourage you to make and maintain that change locally.

4

Quick followup: FRequestPlaySessionParams seems accessible via GEngine. Does this get you what you need?

bool FMyPIEAuthorizer::RequestPIEPermission(bool bIsSimulateInEditor, FString& OutReason) const
{
	if (UEditorEngine* EdEng = Cast<UEditorEngine>(GEngine))
	{
		TOptional<FRequestPlaySessionParams> SessionParams = EdEng->GetPlaySessionRequest();
		if (SessionParams.IsSet())
		{
			if (SessionParams->GameModeOverride && SessionParams->GameModeOverride->GetName().Contains("ForbiddenGameMode"))
			{
				OutReason = "Example authorizer";
				return false;
			}
		}
	}
	return true;
}

You will need to add “UnrealEd” to your Build.cs PublicDependencyModuleNames, and preferably only use UEditorEngine in editor modules (or compile any usage only WITH_EDITOR).

5

Thanks for the quick reply.

I’d suggest adding it as a new function to the PIEAuthorizer with the new signature so!

Because StartPlayInEditorSession takes the value as a parameter, any modifications in the PIEAuthorizer wouldn’t actually be picked up after the fact, so we need to either modify the input parameter, or have StartPlayInEditorSession re-fetch the Request Params after the loop!

6

Got it, indeed GetPlaySessionRequest() doesn’t let you mutate the actual request stored on the UEditorEngine. Nor is there another way to mutate the request from IPIEAuthorizer or otherwise.

If the authorizer is for internal use in just your studio’s projects, you can consider creating a UEditorEngine subclass which can be configured in DefaultEngine.ini. See

GConfig->GetString(TEXT("/Script/Engine.Engine"), TEXT("UnrealEdEngine"), UnrealEdEngineClassName, GEngineIni);
EngineClass = StaticLoadClass(UUnrealEdEngine::StaticClass(), nullptr, *UnrealEdEngineClassName);

You can then override

UNREALED_API virtual void StartQueuedPlaySessionRequestImpl();to to modify the play request or to introduce hooks for other systems to modify the play request. The default implementation also contains this step that copies the PIE request:

// Keep a copy of their original request settings for any late
// joiners or async processes that need access to the settings after launch.
PlayInEditorSessionInfo->OriginalRequestParams = PlaySessionRequest.GetValue();

Since your IMyPIEAuthorizer modifies the request after that copy has been made, any place where OriginalRequestParams is accessed has outdated info. It may be no problem depending on which properties you modify, but if we would make the PlaySessionRequest mutable through IPIEAuthorizer or somewhere else after that copy, it violates the assumption that the copy is representative.

Edit: So just be mindful of that for your local change, and it’s another reason for us to not just make the request params mutable there. Since there is a virtual already to override, I don’t think we will make this change but if you’d like I can get a second opinion on this.

7

Ah, that’s a great point.

We can replace StartQueuedplaySessionRequestImpl actually, we have a cusotm EdEngine already. Thanks for the replies here, we can close this out if you’re not going to modify the interface.

8

Glad to provide those thoughts. I’ll close this. Have a great day!