Currently the order of initialization of a primary module is this:
Initialize UObjects from the module (call constructor of each UObject in the module).
Call StartupModule (module initialization code).
Initialize Engine
The problem is that my UObject constructors depend on a third-party library that I need to initialize properly. Since constructors are invoked before I get a to initialize the library, I get unexpected behaviour (crashes). Is it by design, and if it is, can I alter this behaviour so that module is initialized before its objects are initialized (which makes more logical sense)?
I’ve attached a project to demonstrate this. If you Play it as Standalone Game from the editor and then inspect the logs, you’ll see messages in this order:
First, I just wanted to mention that it is generally not a good idea to depend on any elements of a project being initialized in a specific order in UE4, or any game engine. Having said that, could you provide an example of how you are initializing your UObjects from the third-party library? I’d like to see if I can find a way to get it to work for you.
I think in general it’s fine to depend on a presence of a lifecycle of different parts of a system. The problem is that there seems to be no well-defined lifecycle for modules in UE4. As I see it, depending on StartupModule() being called before module objects are created is somewhat similar to depending on BeginPlay() of an AActor being called before Tick() (i.e. an entity, be it an actor, a level or a module should be initialized before the engine operates on it). Are you sure this is actually by design?
Thank you for offering to take a look at my project. The actual setup is a bit involved, I’ll try to create a simplified sample to demonstrate what I’m trying to achieve in the next couple of days.
I apologize if I wasn’t very clear about the order in which elements of a project are initialized. There shouldn’t be any problems with regards to objects that reference other objects within the same module. Individual modules should always initialize everything within them the same way. What I meant was that if you have an object in Module A that requires something in Module B (or a third-party library) to be initialized first, we don’t guarantee that Module B will always be fully initialized before Module A starts initializing its own objects.
Thank you for clarification. In my case there is just one module. What I’m looking for is a way to guarantee that the module is initialized (i.e. StartupModule() is called) before its objects are being operated on in any way. I think such a guarantee would make sense, but it seems that the engine doesn’t provide it.
So I postponed dealing with this, but the issue becomes more pressing as we are approaching the release date.
Let me clarify more the problem I was explaining here. Currently, UE4 will touch (call constructors of) objects within a module that has not been initialized (StartupModule() has not been invoked) yet. With proper module lifecycle, this must not happen. UE4 must first call StartupModule() and only then try to do something else with the module (including constructing objects of the module). At the moment it seems that UE4 does not provide a way to have some initialization code running before any other code is touched.
I’ve attached a modification of original sample where the project crashes, because the constructor of AInitializationDemoGameModeBase is invoked before StartupModule() and it tries to access a pointer that has not been initialized yet. The situation in the actual game is similar, although we don’t have direct control of the whole initialization code, because it is in a third-party library (StartupModule() initializes the library). Notice that the sample has thread-safety problems, but it is solely for demonstration purposes. The actual library uses thread-local storage, so there are no issues with that. The only problem we have is that there is no well-defined module lifecycle in UE4.
I apologize for not responding sooner. I completely missed that you had responded to this post.
As I mentioned previously, UE4 does not require that a module be started, initialized, and available before any classes within it can be instantiated. Class constructors get run right away to make sure the Engine is aware of all of the classes, and they are loaded into memory so that they are available if needed.
I just realized that I never mentioned some options that are already in the Engine for delaying initialization of some things if that is necessary. For Actor classes in general, you can add anything that needs to wait to be initialized to either PostLoad() (for serialized Actors), or PostActorCreated() (for spawned Actors). For GameModeBase classes specifically, there is InitGame(), which is called at the start of the game before any other functions are called, and can be used to set up parameter initialization and helper classes. In the case of the example that you provided that crashed, when I moved the log lines from the GameModeBase class’ constructor into an overridden InitGame(), the crash no longer occurred, and the messages appeared in the log as expected when I started PIE.
Is it possible to move any code that needs to access the third party library into one of these functions so that it does not run until after the library is initialized by StartupModule()?