Game not loading assets in standalone builds

(/home/alkaline) #1

Originally reported by: Alee (Discord), kaylinDevelopment (GitHub)

Description: After creating a new world in the latest pre-alpha build, during NPC generation, the game crashes with a memory read access violation. The stacktrace of the exception points toward the world generator (FWorldGenTask.cpp) on line 601.

In the latest closed-source master, this line is:

UCompanyTypeAsset* CompanyType = this->CompanyTypes[this->RandomStream.RandRange(0, this->CompanyTypes.Num() - 1)];

This suggests that the bug is related to deciding what type of company the game should generate next during the company generation phase of Peacenet World Generation.

Screenshots and logs:

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x00000000

0x000000013fc773ec ProjectOglowia-Win64-Shipping.exe!FWorldGenTask::DoWork() [c:\users\alkaline\documents\peacenet-ue\source\projectoglowia\private\uworldgenerator.cpp:601]
0x000000013fc71cd2 ProjectOglowia-Win64-Shipping.exe!FAutoDeleteAsyncTask<FWorldGenTask>::Abandon() [c:\program files\epic games\ue_4.20\engine\source\runtime\core\public\async\asyncwork.h:119]
0x000000013fd1273a ProjectOglowia-Win64-Shipping.exe!FQueuedThread::Run() []
0x000000013fdddd27 ProjectOglowia-Win64-Shipping.exe!FRunnableThreadWin::Run() []
0x000000013fddb4b7 ProjectOglowia-Win64-Shipping.exe!FRunnableThreadWin::GuardedRun() []
0x00000000775859cd kernel32.dll!UnknownFunction []
0x00000000776ba561 ntdll.dll!UnknownFunction []

Crash in runnable thread PoolThread 1```

(/home/alkaline) #2

Seems like this bug is only affecting standalone builds because the Unreal editor isn’t affected. Will have to look further into this.

Also, it seems as though there are actually companies in the game. Removing all companies from the game in the editor results in some more weirdness, though.

Gonna try my classic “Nuke it” troubleshooting step. Companies are not part of the alpha milestone, I’m not sure why I implemented them. I know their implementation is partial so my guess is Unreal didn’t package up all the company type assets properly and as such the game gets access violations trying to read them.

(/home/alkaline) #3

I was able to reduce the crash to an infinite loop in standalone builds. I removed the company system entirely.

EDIT: Bug has been identified in the code. Certain assets in the game do not get cooked by Unreal Engine 4 during packaging a standalone build.

This affects:

  • Company type assets (they’re gone now)
  • Markov Training Data assets
  • Any other data asset not used by the game via a hard reference.

Possible fixes may include reconfiguring Unreal’s cooker to package everything regardless of whether it’s used directly through a hard reference.

(Kaylin Stapleton) #4

Hi, thanks for the update. I wish you luck in the advancement in The Peacenet. :slightly_smiling_face:

(/home/alkaline) #5

No problem, and thank you too! :smiley:

(/home/alkaline) #6

So this bug is much larger than I thought it was. Turns out that Unreal simply…isn’t packaging up any assets in the game that aren’t directly referenced by other assets. I’m going to rename this bug to “Game not loading assets in standalone builds.”

(/home/alkaline) #7

Major update:

I have successfully triaged the issue and I’m working toward completely fixing it. It is now possible to generate a world in The Peacenet, however clicking “Continue” crashes the game with this error.

Access violation - code c0000005 (first/second chance not available)

ProjectOglowia_Win64_Shipping!UImageLoader::SaveImage<FColor>() [c:\users\alkaline\documents\peacenet-ue\source\projectoglowia\private\imageloader.cpp:244]
ProjectOglowia_Win64_Shipping!UImageLoader::GetBitmapData() [c:\users\alkaline\documents\peacenet-ue\source\projectoglowia\private\imageloader.cpp:183]
ProjectOglowia_Win64_Shipping!USystemContext::UpdateSystemFiles() [c:\users\alkaline\documents\peacenet-ue\source\projectoglowia\private\usystemcontext.cpp:500]
ProjectOglowia_Win64_Shipping!<lambda_6cc5118a5b065a4dfd3832af5f8903fd>::operator()() [c:\users\alkaline\documents\peacenet-ue\source\projectoglowia\private\peacenetworldstateactor.cpp:421]
ProjectOglowia_Win64_Shipping!__scrt_common_main_seh() [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:288]

I have nailed the bug to being the result of Unreal check statements not being compiled in shipping builds. For those wondering, the check statement is a debugger function you can call. It basically does:

if(something is true)

The engine skips compiling of these statements in shipping builds since they’re for debug error checking. So, since I was doing things like this:

TArray<FAssetData> Assets;
check(AssetRegistryModule.Get().GetAssetsByClass("MarkovTrainingDataAsset", Assets));

it would skip compiling the function which retrieves the Markov Training Data Assets, and thus none are loaded in, thus causing this bug.

(/home/alkaline) #8

Final update before fix:

Since I know what’s up with the bug (it’s check() statements), and I’ve gotten the bulk of it fixed, I should have a patch out by either tonight or tomorrow depending on how long it takes to remove the image loader.

(/home/alkaline) #9

Fixed the bug. I completely rewrote the world generator. There were many cross-thread operations in the previous world generator that caused a lot of crashes outside of the Unreal Editor.

If all goes well I should have a test build out by the end of this month. World generation is much faster now so I was able to afford to have it done on a single thread rather than doing multi-threading stuff. I’ve actually done a lot of refactoring in the game that’s made the whole thing a lot more stable and fast. I’ll write a blog post about it eventually.