Unreal 4.16.1 debug game build error: ICU data directory was not discovered

Still getting this issue in 4.17.1 on PS4, and haven’t heard anything back…

We are no longer running into this issue on Windows with our prior repro steps. I will see if I can get some testing on a PS4 done to try to repro it there.

I also encountered this issue in ue4 17.1 on PS4
00:08:15 Assertion failed: HasFoundDataDirectory [File:D:\UE4_Source\UnrealEngine4_17\Engine\Source\Runtime\Core\Private\Internationalization\ICUInternationalization.cpp] [Li
00:08:15 ne: 128]
00:08:15 ICU data directory was not discovered:
00:08:15 …/…/…/abyss/Content/Internationalization
00:08:15 …/…/…/engine/Content/Internationalization[Callstack] 0x006159fd - FInternationalization::Get()
00:08:15 [Callstack] 0x00662084 - FTextFormatter::FormatStr(FTextFormat const&, TArray<FFormatArgumentValue, FDefaultAllocator> const&, bool, bool)
00:08:15 [Callstack] 0x00661dc4 - FTextFormatter::Format(FTextFormat&&, TArray<FFormatArgumentValue, FDefaultAllocator>&&, bool, bool)
00:08:15 [Callstack] 0x0063e14d - FText::Format(FTextFormat, FFormatArgumentValue)
00:08:15 [Callstack] 0x009097eb - FProjectDescriptor::Load(FString const&, FText&)
00:08:15 [Callstack] 0x0090c089 - FProjectManager::LoadProjectFile(FString const&)
00:08:15 [Callstack] 0x004072b0 - FEngineLoop::PreInit(wchar_t const*)
00:08:15 [Callstack] 0x004058cf - FEngineLoop::PreInit(int, wchar_t**, wchar_t const*)
00:08:15 [Callstack] 0x00421640 - tchar_main(int, wchar_t**)
00:08:15 [Callstack] 0x00420b61 - main
00:08:15 [Callstack] 0x0400c7fb - _start

I am also experiencing this issue when running DebugGame on PS4. I included more information from my log in the PS4 forum: link text

I’m also getting this error Debug on ipad pro with 4.17, why`````。

HI guys,
I have always this probleme in Unreal Engine 4.17.
It’s not possible i think.
Please Help me

Any movement on this? I have the same issue running a Debug build on PS4 with 4.18…

Additional info…the path provided is “…/…/…/engine/Content/Internationalisation”
…which gets converted by FPS4PlatformFile::NormalizeFilename() into “/data/mygamename/engine/content/internationalisation” by the shortening logic - so that looks obviously wrong. I haven’t been able to successfully debug through the optimised DebugGame build (which works) to see why that succeeds…

I took another look at this today in 4.18.3, and was able to successfully run both a Debug and a DebugGame build on a dev kit from within Visual Studio. Is this still something that is giving you trouble? Are you able to launch the game onto a dev kit from within the Editor?

Hi , I was building from source and got this issue on 4.19.2 using Debug and Development mode on XboxOne, I cannot launch the game, I will try the workaround mentioned below.

The problem lies on FICUInternationalization::Initialize()
bool HasFoundDataDirectory = false;
for(const auto& DataDirectoryString : PotentialDataDirectories)
{
if( FileManager.DirectoryExists( *DataDirectoryString ) )
{
u_setDataDirectory( StringCast( *DataDirectoryString ).Get() );
HasFoundDataDirectory = true;
break;
}
}

Where PotentialDataDirectories:
L"…/…/…/FallenOne/Content/Internationalization"
L"…/…/…/Engine/Content/Internationalization"

My files are on:
FallenOne sits on C:\UE4\FallenOne
Engine on C:\UE4\VanillaEngine\UnrealEngine\Engine

Here is the callstack:
> FallenOne-XboxOne-Debug.exe!FICUInternationalization::Initialize() Line 129 C++
FallenOne-XboxOne-Debug.exe!FInternationalization::Initialize() Line 274 C++
FallenOne-XboxOne-Debug.exe!FInternationalization::Get() Line 30 C++
FallenOne-XboxOne-Debug.exe!FTextFormatter::FormatStr(const FTextFormat & InFmt, const TArray<FFormatArgumentValue,FDefaultAllocator> & InArguments, const bool bInRebuildText, const bool bInRebuildAsSource) Line 904 C++
FallenOne-XboxOne-Debug.exe!FTextFormatter::Format(FTextFormat && InFmt, TArray<FFormatArgumentValue,FDefaultAllocator> && InArguments, const bool bInRebuildText, const bool bInRebuildAsSource) Line 855 C++
FallenOne-XboxOne-Debug.exe!FText::Format(FTextFormat Fmt, FFormatArgumentValue v1) Line 444 C++
FallenOne-XboxOne-Debug.exe!FProjectDescriptor::Load(const FString & FileName, FText & OutFailReason) Line 64 C++
FallenOne-XboxOne-Debug.exe!FProjectManager::LoadProjectFile(const FString & InProjectFile) Line 33 C++
FallenOne-XboxOne-Debug.exe!FEngineLoop::PreInit(const wchar_t * CmdLine) Line 1390 C++
FallenOne-XboxOne-Debug.exe!EnginePreInit(const wchar_t * CmdLine) Line 689 C++

Also put the project folder into the same UE4 folder and compiled the project to get this error message:

Sandbox filewrapper tried to access
project path before it was set

Update: got it working, my issue was the way I was using the cooker on the fly, you need to launch it with your project name or the path to the .uproject file Cooking Content in Unreal Engine | Unreal Engine 5.3 Documentation

This is still not working on my Mac Project with 4.17.2. I am not able to debug because FPaths::GameContentDir() and FPaths::EngineContentDir() are pointing to wrong directories. In Development Mode both functions pointing to the wright directories.

This is still not working on my Mac Project with 4.17.2. I am not able to debug because FPaths::GameContentDir() and FPaths::EngineContentDir() are pointing to wrong directories. In Development Mode both functions pointing to the wright directories.

Definitions.Add("UE_ENGINE_DIRECTORY= ‘PATH TO ENGINE’ "); to build.cs is not helping.
Any other workaround available?

I’m also having this problem trying to set up for Mac.

I tried looking at the bug report, and seeing what they did to fix it, but all the links are dead.

I am having this issue on 4.20.3 both with Ue4 and Ue4 source

Not working on 4.21.2 macOS. Neither binary vs source nor Xcode vs VS Code helps. Let’s play spot the bug: Engine/Source/Programs/UnrealBuildTool/Configuration/UEBuildTarget.cs

string OutputFilePath = ExecutableBinary.OutputFilePath.FullName;
if (Platform == UnrealTargetPlatform.Mac && OutputFilePath.Contains(".app/Contents/MacOS"))
{
	OutputFilePath = OutputFilePath.Substring(0, OutputFilePath.LastIndexOf(".app/Contents/MacOS") + 4);
}
string EnginePath = Utils.CleanDirectorySeparators(UnrealBuildTool.EngineDirectory.MakeRelativeTo(ExecutableBinary.OutputFilePath.Directory), '/');
if (EnginePath.EndsWith("/") == false)
{
	EnginePath += "/";
}
GlobalCompileEnvironment.Definitions.Add(String.Format("UE_ENGINE_DIRECTORY=\"{0}\"", EnginePath));

There’s a corner case check for OSX bundles (though in a hacky way, but it’s fine), which strips off Contents/MacOS and assigns it to OutputFilePath. However, OutputFilePath is not accessed again, causing UE_ENGINE_DIRECTORY to be set to relative to the binary’s location in the bundle :confused:

  • Engine/Source/Runtime/Core/Private/Mac/MacPlatformProcess.cpp sets the working directory to project-root/Binaries/Mac.
  • When checking for the EngineDir in Engine/Source/Runtime/Core/Private/GenericPlatform/GenericPlatformMisc.cpp, it will check the default …/…/…/Engine (works fine in fully packaged builds due to some magic), then what UE_ENGINE_DIRECTORY is set to, which is relative to project-root/Binaries/Mac/project.app/Contents/MacOS, not project-root/Binaries/Mac.

Which also means there’s a second bug here: chopping off Contents/MacOS still leaves us a directory higher than what UE_ENGINE_DIRECTORY needs to be set to. Aka UE_ENGINE_DIRECTORY would be relative to project-root/Binaries/Mac/project.app if not for bug #1, but regardless needs to relative to project-root/Binaries/Mac.

The commits, at least on the Release branch, are squashed, but I suspect this is the breaking change:

Change 3378297 on 2017/04/04 by Graeme.Thornton

Fix incorrect generation of UE_ENGINE_DIRECTORY in UBT

Maybe not that fixed. That said, it was likely broken beforehand, and I suspect macOS no-editor debugging has never worked out of the box in UE4. I’ll also note UE4’s “where do I find stuff” logic feels super rickety and is spread out across way too many places and I’m surprised things don’t break constantly for no reason. Then again - maybe they do.

Here’s a possible fixed version, though it needs a bit more testing. Doesn’t break on the ICU data directories, but doesn’t find the cooked content unless I explicitly set it with -Sandbox=“/Saved/Cooked/MacNoEditor” - suspect there’s similar issues with how project dirs are set. If you want to try it, I suggest applying the attached patch file with **git apply filename-of-the-attached.patch ** from the root of a UnrealEngine source checkout. Changed code snippet for reference:

// The hardcoded engine directory needs to be a relative path to match the normal EngineDir format. Not doing so breaks the network file system (TTP#315861).
DirectoryReference EngineDirectory = ExecutableBinary.OutputFilePath.Directory;
if (Platform == UnrealTargetPlatform.Mac && EngineDirectory.FullName.Contains(".app/Contents/MacOS"))
{
	EngineDirectory = EngineDirectory.ParentDirectory.ParentDirectory.ParentDirectory;
}
string EnginePath = Utils.CleanDirectorySeparators(UnrealBuildTool.EngineDirectory.MakeRelativeTo(EngineDirectory), '/');
if (EnginePath.EndsWith("/") == false)
{
	EnginePath += "/";
}
GlobalCompileEnvironment.Definitions.Add(String.Format("UE_ENGINE_DIRECTORY=\"{0}\"", EnginePath));

Engine/Source/Programs/UnrealBuildTool has a C# Visual Studio project file, compile that (probably on a Windows machine sry) and you should be able to drop the four Engine/Binaries/DotNET/UnrealBuildTool.* files it into the corresponding directory on a macOS UE installation. Note that a normal build of Unreal Engine won’t apply this.

Git patch, might need to rename to file.patch instead of .txt

1 Like

Hey guys,

This issue unfortunately still persists in 4.21.2.

We have cooked a standalone build for a VR-project of ours.

Locally (on the machine it was cooked on) it’s running fine, as well as on our other workstations and home office machines.

However, on the two brand new machines (MSI ROG with 1070 GTXs) of our client, the same standalone will crash with the same Fatal Error - due to ICU Internationalization folder not being found.

Those two machines are running Windows 10 Home (all other machines Win 7, 8.1, 10 Professional, respectively).

Running editor versions of the cooked build is no problem at all.

We have already tried installing VS on those machines as well as the UE4 depencies for 64 bit, but to no avail.

Can anyone help us shedding some light on this?

Best regards,

Til

Some of my packaged projects won’t run, and when I try to run them from the Win64 folder (Engine>Binaries>Win64), I get a similar message:

LowLevelFatalError [File:Unknown] [Line: 153] 
ICU data directory was not discovered:
../../../Engine/Content/Internationalization
../../../Engine/Content/Internationalization


0x00007ffcfc96a719 KERNELBASE.dll!UnknownFunction []
0x00007ff67be141b6 UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67bdccf7d UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67bd3bc12 UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67bd31dde UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67bd5f455 UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67ba608dd UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67ba69c5b UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67ba63e76 UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67ba640ba UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67ba6da4b UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ff67db4d69e UE4Game-Win64-Shipping.exe!UnknownFunction []
0x00007ffcfe827bd4 KERNEL32.DLL!UnknownFunction []
0x00007ffcfee6ce51 ntdll.dll!UnknownFunction []

My project is Blueprint only, so don’t know how this is related. Would love some support right now, can’t find anything anywhere about this, and have no idea how C++ works.

One of my players is getting the same error with 4.26 in a packaged, shipping build. No debugging.

No special characters in the file path, DirectX and VS updated with the prerequisites. I can’t seem to figure out the issue.

olololololol

hello, I’m facing the same issue would you mind helping if you found a solution ? thank you in advance