Plugin: keeping an object alive for the whole game

Hello,

I am developing a Plugin that exposes a network API.

The main entry point of this API is a plain C++ object named Client that represents a connection to a server.

Once the API user has created the Client (there usually is only one), I want this Client to persist across levels (the goal is to keep the connection open). Destruction of the Client should only occur if the user explicitly asks for it.

So far, I have found two ways to achieve this:

  1. Store the Client directly in the plugin’s module object (the one that inherits from IModuleInterface).
  2. Store the Client in a custom UObject, which is added to the root set when created.

Both these options have worked fine so far, but they share a common problem: when using Play in Editor, the Client is kept alive after the Play session ends, which I do not want.

I am looking for a non-intrusive way to prevent the Client object from outliving a Play in Editor session.
By non-intrusive, I mean that I want it to be transparent to the user of my plugin (i.e. they should not have to create a custom GameInstance to hold a reference to the Client, etc.).

Is this at all possible? Thanks in advance.

If you have someplace that runs any Tick/PerFrame logic, you could probably try something like this:

// Some Tick method either in the Module or custom UObject (make sure you set bCanEverTick to true...)

void CustomUObject::Tick(float DeltaTime)
{
#if WITH_EDITOR
  if (GEngine->() == nullptr)
  {
     // We were running in-editor, manually clean up the client connection.
     // ...
  }
#endif
}

There variues PIE events in FEditorDelegates which you can bind to, they are static, look up in constants:

remember to use #if WITH_EDITOR and make diffrent initiation code for editor and game builds

FEditorDelegates::EndPIE is just what I was looking for :slight_smile: Thanks a lot! It’s strange I didn’t hear about it until now despite all the research I’ve done.

Indeed I have someplace in my code where I could do that. I’ll use 's solution as it looks cleaner, but thanks for giving me the idea anyway, this could prove useful.