Persistent lvl doesnt trigger BeginPlay in Standalone (after upgrade to 4.22.2)

Hey Peeps,

Using UE 4.22.2, Perforce Rev. P4V/NTX64/2019.1/1797168, Win64, fully BP project.

We’ve been working with version 4.19.2 for some time, and recently upgraded to 4.22.2.
We use few simple functions in our Persistent level blueprints, that are initiating on Begin Play event.
After the upgrade those stopped triggering, when launched in Standalone Game.
They, however, do trigger, when launched in PIE, or in packaged project.

I’ve attempted disconnecting every single node, and just using “Print String” and those also don’t fire.
I’ve already tried with a blank project, and can confirm that Begin Play works as expected in level BP.

We do use Perforce as source control tool, and have attempted to test this on multiple workspaces with the same result.

So far, couldn’t find anyone experiencing similar problem, besides this:

However, this is somehow related to game mode and casting. Just in case I’ve tried this solution, to no success.

Any chance we are missing some kind of new/old setting that might be blocking this?
Settings search haven’t shown anything, besides ability to add arguments to Standalone instance.

Any ideas would be much appreciated.

There’s an issue with casting, structs, data tables, UMG, and a few other things I’ve found when updating the engine.

There’s a couple solutions to this:

1: Fine every single cast, struct, data table, and in all your UMG widgets, you need to right click the nodes and refresh them or

2: Completely delete and re-add all casting nodes, structs, data tables, etc…

It’s extremely tedious, especially if the project is big like some of the ones I’ve worked on. But it works, I submitted a bug ticket to Epic and they said it was something wrong with MY code. Though I’ve combed through it dozens of times. This is the only solution to either refresh all of these, or delete and re-add them.

But again for me, as far as I’ve noticed it’s only with the things I mentioned above:

Structs
Data Tables
Casting Nodes
Actor Variables (character, pawns etc…)
UMG nodes both in UMG itself, and in whatever blueprint is referencing them

So, I’ve added a bunch of other Log messages, and I found something that I dont understand.

First of all, I’ve found that if a single persistent level with no sub-levels is used, Begin Play from Persistent Level IS triggered.
If there ARE sub-levels, it’s not.
This happens in Standalone only (doesnt happen in the build or PIE)

I’ve tried to replicate this in a default empty project, and cannot replicate this.
Does not matter whether there is only persistent level, or there are sublevels on it, Begin Play from Persistent Level IS triggered, as expected.

Second thing that I’ve noticed, is that our Player character is not being possessed in Standalone only. (doesnt happen in the build or PIE)

Starting in PIE:

279832-pie.png

All these start with Begin Play in blueprints, and I see that the load order is

  1. Camera object, standing on the level

  2. Game mode

  3. Player character, standing on the level

  4. Persistent Level

I always believed that Persistent Level + Game mode would be first to be loaded during the game start, and only after that all the rest objects would load.

Then, when I start in Standalone:

279833-standalone.png

Player object is missing from the log.
We use standard character controller, and it’s setup in game

279834-game-mode.png

Hey, Ronnie, thanks for answering.

I could try that, for sure, but do you know how this could be related to the places, where there are no casts, widgets, or any other things used in the BPs?

Like, using simple Print String with Begin Play node doesn’t do anything.
Any idea if map files could also be screwed by upgrading project version?
If so, do you have any ideas on what could we do to un-screw them?

So there’s two things.

First when you open your game a game instance is created and it’s persistent until the app is closed.

You’d want to load the Game Mode first as it contains the “rules” of operation for your level. AFTER the game mode is loaded you’d want to load everything else. I don’t see any situation where you’d want the character loaded in before the level.

Yeah, that’d makes sense.

I don’t believe we’ve intentionally done that, modified the engine, or in any other ways made that happen.

I’ve also started a blank project from SideScroller example, and see that it does this:

279836-sidescroller-example.png

I could go back to the revision when that was not happening and check what kind of load order is happening there, but again, could the upgrade change that?

Then the other thing would be, how to change the load order in general?
We don’t have any C++ or other tingling with it.

[googling “change load order BP UE4”]

Lol, that obviously didnt show any helpful information besides “the load order will always be different depending on scenario”.
What did I expect?
Also, no way people talk about how to change that.

So… a bunch of Delay nodes?

Lol, I still dont get how could it be that the game mode somehow initializes before the level does?

What could potentially cause that?

That is definitely strange. I’d definitely suggest backing everything up before making any major changes, the engine still seems fickle sometimes. Random things seem to crash and corrupt projects.

I have no idea what could’ve changed. I’d still suggest refreshing all your nodes. Sometimes things just need to be re-compiled. Especially after an update.

So, after a massive amount of attempts, I’ve reached a roadblock.
Refreshing/deleting nodes so far didn’t show any success, I’ve tried to do this with all the BPs that could be even remotely related to startup, including map, game modes, interfaces, etc. Won’t be possible to do this to every single object at our current scale.

After the downgrade I attempted to launch the most recent revision of my project (the one where we found out that there’s a problem with Standalone) but launch it on 4.19.2, and there was no problem. So, as Ronnie has stated, there’s definitely a problem with converting.

Re-converting few times didn’t show any improvement, so, apparently there is something happening in our project that doesn’t work in 4.22.2/3.

That means, we are stuck with 4.19.2 for a year, or until we get someone to deal with this.
Alternatively, I will attempt to gradually upgrade to 4.20, then 4.21 then 4.22 and see if that will help.

Haha it happens. There’s a term in the tech world we call “FBFM” “Fixed By F**kin Magic” … Sometimes things just work, sometimes they don’t.