Rationale behind different Startup Order of the Blueprint Framework between Editor and Packaged?

[VictorBurgos]

That's not only old, but doesn't have the correct information. Or rather, it's missing a lot of key things.

[S-ed]

This may help (yet it may be outdated, since it seems written for 4.11)
https://docs.unrealengine.com/latest...cle/index.html

[Raildex_]

The Init Order should be same, otherwise things will be initialized in the Editor, but not in a packaged build.
The Order of Execution in the GameMode doesn't make sense either.
RestartPlayer is called before BeginPlay afaik.

[VictorBurgos]

Well, makes more sense than Editor then? I see it like, without a brain, the body would die. So, you need a body to throw that brain in But of course, without a body, the brain will still live, and it can get transplanted into whichever body it wants.

[Zeblote]

The packaged version doesn't make 100% sense either. Player controller should come before character.

[VictorBurgos]

Seen a few threads around where Devs use deliberate Is-Valid-Yet Startup-Loop non-blocking 'wait' actor/var reference-checks.
So its widespread, and presumably exasperated by different target hardware / platforms too. BTW: Thanks for listing the order!!!

No worries, you're welcome. It was going to be part of my book anyway, and I needed to know the exact order because I knew it was different from first hand experience (i.e. bugs) before. I mean the Packaged version makes 100% sense..the Editor version...not so much. Wish we could get some official statement from Epic on this though.

[CriErr]

Yep, the weirdest part is not valid game state from a user widget for one frame, wait until valid is the only real solution for this stuff I see.

[UnrealEnterprise]

Editor= GI-PC-Char-GM-GS-PS-HUD-Level-Actor
Packaged= GI-GM-GS-PS-Char-PC-HUD-Level-Actor

GI= Game Instance
GM= Game Mode
GS= Game State
PS= Player State
Char= Character
PC= Player Controller
HUD= HUD
Level = Level
Actor = Actor

Seen a few threads around where Devs use deliberate Is-Valid-Yet Startup-Loop non-blocking 'wait' actor/var reference-checks.
So its widespread, and presumably exasperated by different target hardware / platforms too. BTW: Thanks for listing the order!!!

[antsonthetree]

I've wondered about this too. There's even a third order in multiplayer for the Client machines. Don't have my notes for the exact changes. It would be great if someone could give some clarification, or if we could have a consistent path for all the scenarios.

[VictorBurgos]

Editor= GI-PC-Char-GM-GS-PS-HUD-Level-Actor
Packaged= GI-GM-GS-PS-Char-PC-HUD-Level-Actor

GI= Game Instance
GM= Game Mode
GS= Game State
PS= Player State
Char= Character
PC= Player Controller
HUD= HUD
Level = Level
Actor = Actor

I've noticed and asked before on different version and it's still irregular in 4.18. This is also one of the main reasons why I place all my UMG logic in HUD usually since it's one of the last to initialize. But really, this makes it awfully hard to debug issues between Editor and Packaged games sometimes if you don't understand that there is a difference in the startup order.

Also I haven't tested this in C++, but I do wonder if it's the same.



Editor and Packaged results