Cooking: Unable to find cached package name for package

When cooking a project that contains FMOD sounds, any that have been used in the game will cause the cook warning “Unable to find cached package name for package” followed by the in path “/Game/FMOD/…”. (CookOnTheFlyServer.pp, line 1329)

While it is only a warning, and the sounds load fine, when using hundreds of sounds it will produce a warning for each one.

This only started occuring in UE 4.13, the patch notes mention “Moved resolving string asset references to be just before package saved instead of after load”. It appears that because these assets are loaded to memory and not disk, they all return an empty PackageFName.

Am I understanding this correctly? Is there a way around this?

Same Problem with 4.14


Could you please upload your full error output logs as a .txt file? Please also provide me with your reproduction steps you’re getting to achieve this error in the engine.

Is this occurring in 4.14?


  • Create new project
  • Add FMOD Integration
  • Place FMOD Audio in map
  • Cook for windows (works for any platform)

I have just made a fresh project following these steps that gets these warnings:

This is occuring in 4.13 and 4.14.

FMOD is an plugin created by a third party. You’re going to need to speak with them further about the troubles you’re experiencing with FMOD. Packaging for Windows is working perfectly fine without FMOD added.


Thank you.

That is correct, I am from FMOD.

It appears in the CookOnTheFlyServer, if a package exists but not on disk, it will be added to the FileNameCache maps without a valid name. (ref image)

Is this intended behavior? Or should I be doing something different with the packages?


I just wanted to make sure that you saw your response on UDN. Here is the bug that was entered by : [UE-41012][1]


Unreal Engine Issues and Bug Tracker (UE-41012)


Thank you for providing a fix - it’s a shame that it won’t make it until UE 4.17 because it causes silent crashes of the OTF Cook Server on PS4.

We have manually integrated the change, however I wanted to point out a potential typo:

In PackageName.cpp:
ContentPathToRoot.Emplace(ScriptRootPath, GameScriptPath);

  •   ContentPathToRoot.Emplace(ScriptRootPath, GameScriptPath);

I’m guessing the intention was to make this:

  •          ContentPathToRoot.Emplace(MemoryRootPath, GameContentPath);

I’m not 100% sure regarding the second parameter as this is a “Memory” type that doesn’t have a strict mapping to the actual .

Additionally, just above there is the line:

Which probably needs to be changed to:


Rainbow Studios, Inc.

After further testing, it seems that the fix, when integrated to 4.15, does not resolve the problem with the OTF Cook Server bailing. However, I believe I have tracked down the change in 4.15 which has been causing this behavior:

The following block of code was added to CookOnTheFlyServer.cpp in 4.15:

    check( bSucceededSavePackage == false );

The check fails because bSucceededSavePackage is true (it succeeded) but the Cache lookup via GetCachedStandardPackageFileFName returns NAME_None. (Hence getting into the else block)

The issue is pretty gnarly as it results in all PS4 OTF Cook runs having the cook server suddenly terminate, causing the PS4 runtime to crash due to receiving malformed/truncated asset data. This leaves no logs or other traceable information that I could find. The only way to track it down (and know what asset was causing it) was to build the entire engine+game in debug, launch the PS4 via the editor, then attach visual studio to the OTF process once started automatically via the project launcher. One final note - it seems like when you launch via the Project Launcher that the Development OTF Cook server is used (UE4Editor.exe) even if you are running the Debug UE4 Editor. (UnrealFrontend-Win64-Debug.exe) I simply copied the newly build Debug executable to the expected file manually - but there is probably a better way to get it to run the right OTF Cook Server that I’m unaware of. (Just watch out for it using a stale binary that isn’t the one you have been building…)