Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Leave a comment:


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

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


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

    Leave a comment:


  • replied
    Originally posted by franktech View Post

    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Originally posted by VictorBurgos View Post
    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!!!

    Leave a comment:


  • replied
    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.

    Leave a comment:


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

    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




    Last edited by VictorBurgos; 10-13-2017, 03:22 PM.
Working...
X