GameMode: local player controller Login/PostLogin called before BeginPlay?

It seems that when I start a standalone game, C++ AGameMode::Login is invoked for the local player controller before the GameMode BP Event BeginPlay? The same is true for the BP Event PostLogin for the same local player controller (fired before GameMode BP Event BeginPlay).

However, this doesn’t seem symmetric/consistent to the usual sequence for remote clients logging in, in that the respective PreLogin/Login/PostLogin are invoked (long after) GameMode Event BeginPlay.

Basically, I attempted to consistently do some initialization (loading config) in GameMode Event BeginPlay, and then use the initialized config to aid the player login process, no matter if it’s a local player or remote. However, with the current behavior, I have to load my config (check if initialized) inside Login (for once) to carry on the player specific setup.

Can I consider this asymmetric inconsistent behavior a possible bug?

Hey lluo-

I want to clarify to make sure I understand you correctly. I created a game mode bp and a player controller bp. In both I added a print node on BeginPlay and noticed that the player controller print statement would show prior to the Game mode print statement. Is this the behavior you’re referring? If I am not understanding correctly can you elaborate on your issue along with any steps that would help me reproduce the problem on my end.


Hi ,

The issue I had was not regarding the execution order of BeginPlay for GameMode and local player controller. The issue is that AGameMode::Login for the local player controller seems to be executed before AGameMode::BeginPlay. But for remote player controllers, AGameMode::Login is executed after AGameMode::BeginPlay (this is obvious, since remote players most likely connect to the server after the server game mode BeginPlay has been executed).

While I intended to have AGameMode::BeginPlay to perform some global config loading (e.g. the config has a PlayerToken for each expected player), and then hoping when a player is logging in in AGameMode::Login, I can use that config to match the player (e.g. the player has to have a matching PlayerToken option in Options), and I’ll setup the player based on the matching attributes under the corresponding PlayerToken.

With AGameMode::Login for the local player controller invoked before AGameMode::BeginPlay, the needed config wouldn’t be loaded yet, so for the local player controller, I had no consistent way of matching this local player controller to the corresponding config which will only be loaded later in AGameMode::BeginPlay, so I had to do the config loading inside AGameMode::Login, which doesn’t feel very beautiful.

Note that AGameMode::BeginPlay is inside Blueprint (or in C++ it would be AGameMode::StartPlay), while AGameMode::Login is C++ code, but I think you got the idea.

Not a big issue by itself, since my game would practically only run dedicated server without a local player controller, so I can always stick the initialization inside AGameMode::BeginPlay, and all the remote player controllers will be setup in AGameMode::Login after AGameMode::BeginPlay anyways. It only makes my testing with a listen server a problem, since I have to move the initialization logic into AGameMode::Login just to make the listen server testing scenario working.



Oh right, after re-reading your post, yes, I think what you saw in your test should also be one of the manifestations of the issue I was describing. :slight_smile:

Hey Iluo-

I was also able to reproduce the issue with the Login function and have entered a bug report (UE-27284) for investigation.


Why is this “By Design”?
This is a design flaw.
My line of thought would be:
BeginPlay() hasn’t fired yet, so the Actor does not exist yet. (This is true for BP Classes basically)

But GameMode seems to be an exception from this rule, since it can execute code before anything else.

1 Like

Hey Raildex_-

While GameMode is an actor, it is already present before the level finishes loading and BeginPlay, while it is usually there as the first thing that occurs when an Actor is loaded, has things that happen before it such as construction and this function.

Will this bug be fixed? PostLogin event on GameMode is still firing before BeginPlay event on the same.

ya i agree with Raildex_, its a design flaw. I hope this gets fixed.