Hi,
I haven’t been able to reproduce this on console or on windows.
I tested in a simple scene, one with a level sequence in the world set to auto play and one where it was being created from the game instance and played.
I suspect what might be the cause is when the object is being requested to load.
How are the Game instance and this Level Seqauence related to one another, is the level instance being referenced by the game instance?
From looking at the codebase, and your call stack, it appears it trying to load the level sequence during LoadObject/Static LOad Object (line 1142) on my tests it was being created from Initialise Standalone.
GameEngine.cpp:1138
`// Create game instance. For GameEngine, this should be the only GameInstance that ever gets created.
{
TRACE_CPUPROFILER_EVENT_SCOPE(InitGameInstance);
FSoftClassPath GameInstanceClassName = GetDefault()->GameInstanceClass;
UClass* GameInstanceClass = (GameInstanceClassName.IsValid() ? LoadObject(NULL, *GameInstanceClassName.ToString()) : UGameInstance::StaticClass());
if (GameInstanceClass == nullptr)
{
UE_LOG(LogEngine, Error, TEXT(“Unable to load GameInstance Class ‘%s’. Falling back to generic UGameInstance.”), *GameInstanceClassName.ToString());
GameInstanceClass = UGameInstance::StaticClass();
}
GameInstance = NewObject(this, GameInstanceClass);
GameInstance->InitializeStandalone();
}`
If you could provide me a little more context on how the level sequence is related to the game instance and being referenced during its static load of the asset, or a minimal sample project that reproduces the error, I could debug further on my end.
----
Some information about the changes to the Async Loading in 5.5.
When FindObject is called outside of PostLoad functions, all objects that still have the EInternalObjectFlags::AsyncLoading are filtered out so you should not be able to get a pointer to an object that still has a RF_NeedPostLoad flag.
When you resolve a TSoftObjectPtr or call FindObject from within a PostLoad call, you may end up with objects that are not fully loaded yet because there is a scope in the loader that is active during PostLoads to give you access to objects that are being loaded.
This is actually a feature to give PostLoad access to other objects it might want to interact with. The idea in those cases is that you are responsible for calling ConditionalPostLoad on other objects you interact with, since by definition, during PostLoad you are part of the loader.
5.5 improved object visibility in zenloader (the default loader used when the game is packaged) by dividing it into 2 different visibility phases, when inside a PostLoad, FindObject will not be able to see objects still being loaded on the async loading thread (i.e. being serialized) to avoid potential race conditions.
In 5.5, objects being serialized on the async loading thread are in EInternalObjectFlags::AsyncLoadingPhase1.
When they are ready to be accessed by the game thread, we switch them to EInternalObjectFlags::AsyncLoadingPhase2.
Kind Regards
Keegan Gibson