I tried packaging my project a couple of times now. First I had some “Editor-Only” related problems with my code. I fixed them. Then I had a linker problem with a missing HACD_64.lib. I don’t know how, but somehow I fixed that, too. Next came a few blueprint classes that wouldn’t compile. I deleted them. So far, I had a basic idea what the problem was, but what am I supposed to make of the following ??
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2016.07.25-11.17.31:867][ 0]LogSavePackage:Display: Finished SavePackage D:/Unreal/Project02/Saved/Cooked/WindowsNoEditor/Project02/Content/UE4_Mannequin/testABP.uasset
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2016.07.25-11.17.39:913][ 0]LogOutputDevice:Error:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: begin: stack for UAT
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2016.07.25-11.17.39:913][ 0]LogWindows:Error: === Critical error: ===
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: Fatal error!
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2016.07.25-11.17.39:913][ 0]LogOutputDevice:Error:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: end: stack for UAT
MainFrameActions: Packaging (Windows (64-bit)): CommandUtils.Run: Run: Took 893,4991052s to run UE4Editor-Cmd.exe, ExitCode=3
MainFrameActions: Packaging (Windows (64-bit)): Project.Cook: Cook failed. Deleting cooked data.
MainFrameActions: Packaging (Windows (64-bit)): Program.Main: ERROR: AutomationTool terminated with exception: AutomationTool.AutomationException: Cook failed. ---> AutomationTool.AutomationException: BUILD FAILED: Failed while running Cook for D:\Unreal\Project02\Project02.uproject; see log C:\Users\Ti
MainFrameActions: Packaging (Windows (64-bit)): m\AppData\Roaming\Unreal Engine\AutomationTool\Logs\D+Programme+Epic+Games+4.12\Cook-2016.07.25-13.18.13.txt
MainFrameActions: Packaging (Windows (64-bit)): bei AutomationTool.CommandUtils.RunCommandlet(FileReference ProjectName, String UE4Exe, String Commandlet, String Parameters)
MainFrameActions: Packaging (Windows (64-bit)): bei Project.Cook(ProjectParams Params)
MainFrameActions: Packaging (Windows (64-bit)): --- Ende der internen Ausnahmestapelüberwachung ---
MainFrameActions: Packaging (Windows (64-bit)): bei Project.Cook(ProjectParams Params)
MainFrameActions: Packaging (Windows (64-bit)): bei BuildCookRun.DoBuildCookRun(ProjectParams Params)
MainFrameActions: Packaging (Windows (64-bit)): bei AutomationTool.BuildCommand.Execute()
MainFrameActions: Packaging (Windows (64-bit)): bei AutomationTool.Automation.Execute(List`1 CommandsToExecute, CaselessDictionary`1 Commands)
MainFrameActions: Packaging (Windows (64-bit)): bei AutomationTool.Automation.Process(String[] CommandLine)
MainFrameActions: Packaging (Windows (64-bit)): bei AutomationTool.Program.MainProc(Object Param)
MainFrameActions: Packaging (Windows (64-bit)): bei AutomationTool.InternalUtils.RunSingleInstance(Func`2 Main, Object Param)
MainFrameActions: Packaging (Windows (64-bit)): bei AutomationTool.Program.Main()
MainFrameActions: Packaging (Windows (64-bit)): Program.Main: AutomationTool exiting with ExitCode=25 (Error_UnknownCookFailure)
MainFrameActions: Packaging (Windows (64-bit)): Domain_ProcessExit
MainFrameActions: Packaging (Windows (64-bit)): copying UAT log files...
MainFrameActions: Packaging (Windows (64-bit)): BUILD FAILED
PackagingResults:Error: Error Unknown Cook Failure
This is only the end of the log, but there were no “error” appearences before it.
Hello MaxPower42,
From the messages listed there, it seems that the issue that is causing this is fail is somewhere in the cooking process. Could you post the full log? The error message that we’re looking for, which could be coming up as a warning instead, should be listed somewhere further up in the log file.
It also may be a good idea to download the debugging symbols for the editor from the launcher if you have the space to do so. This can be done in the Library tab in the “Options” window, available from the dropdown arrow beside the installation in question. Having the Editor Symbols for Debugging may make it so that these blanks spots in the log are filled with actual error messages if you fail to package again. If not, we’ll have to rely on what is in the rest of the log.
Thanks for answering. I didn’t know that warnings can cause the packaging to fail. There are lots of warnings, mostly about missing files. I will try to fix as many of them as I can. If it doesn’t help, I will post what’s left. The editor symbols were already installed by the way.
Ok, after looking at the warnings I found that most of them look more or less like this:
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2016.07.25-18.27.45:886][ 0]LogUObjectGlobals:Warning: Failed to load '/Game/NewFolder/ProjectilePS': Can't find file '/Game/NewFolder/ProjectilePS'
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2016.07.25-18.27.45:886][ 0]LogLinker:Warning: Can't find file for asset '/Game/NewFolder/ProjectilePS' while loading NULL.
I picked this warning and checked for ProjectilePS (some particle system) in the asset explorer. But this and many other files that produce warnings are not located where they are being looked for, but in other folders to which I moved them at some point. The reference viewer showed that this object is not being referenced by anything, so I don’t know where these old paths are coming from. They don’t exist anymore, not in the editor and not in the content folder on disk. In PIE there are no problems whatsoever, only in Packaging.
edit: btw, there are no redirectors in the whole project. I tend to “fix them up” as soon as I see one, without really knowing if they are important for anything.
I hope not 
Hm, I’ve seen this problem before and the user elected to just migrate to a new project just to be done with it and that worked, but I’d rather that not be the go-to solution every time, seeing as this is much harder to do for projects that include code.
Do you have any plugins installed? Sometimes plugins will get a hold of an asset and keep a reference to it and could be causing the issue. If you do have any, please try disabling them and then also disabling them inside of your .uproject file (right-click → Edit with Notepad) and then try packaging.
If not, as a shot in the dark to see if it’ll at least temporarily fix the issues in the meantime, try duplicating these assets that are being referred to in the wrong spot and fill those spots with the correct assets.
Yes, I have read about that fix in this question. But that person also says that all your changes may be reverted after restarting the editor, and that you need to re-compile basically everything that references the broken objects. The thing is, I am getting dozens, maybe a hundred, of these warnings and I really don’t want to go through this unless there is absolutely no other way.
I am not using any plugins btw. I used to have IKinema installed until I removed it a couple of days ago.
The first thing I tried was deleting the folders “intermediate” and “saved”, but it didn’t achieve anything except breaking my VS-solution, which refused to load my project afterwards.
Next I tried migrating to a new project. First I copied over all source code files and added them to the solution. In order to compile, I had to copy the .uproject-file as well, because of the dependencies/modules. Then I copied the config-files and finally migrated the whole “content” folder from the editor. I could run the project in PIE without problems, but got the same missing file warnings on packaging.
Then I deleted all the content of the new project from the windows explorer and manually copied it over from the original project once more, but the warnings were still there.
And now I’m pretty much out of ideas. What I would very much like to know is where the editor is getting this outdated path-data from. I mean, it has to be stored somewhere, but I can’t find the responsible code. Maybe I could write some algorithm that iterates through all assets/packages/files and whatever additional path-information there is, and auto-corrects mismatches as good as possible. But I don’t know where in the engine to look for those paths.
I think I was wrong about the manual copying of the content folder from the windows explorer. There are definitely fewer missing files now, only something around 10 to 20. Maybe they would all have been fixed, if I hadn’t migrated (and deleted) the content before copying. I’m gonna try this again tomorrow.
Ok I give up. I spent all fricking day trying to fix the warnings and package my project. It doesn’t seem possible. No matter what I do, the engine always tries to load files that have either been moved or deleted months ago. There is absolutely no problem whatsoever with PIE, but packaging won’t work. Not a chance…
Can you please help me with this? Where on earth do all these outdated paths come from?? Seriously, where are they stored and read from? And why is the engine trying to load them? Where in the code does this happen?
There isn’t really anywhere in code that it “happens” as this is just a case of left over references. If packaging is the only part that is failing, I suggest setting your “list of maps to include in a packaged build” inside of Edit > Project Settings > Packaging. You’ll need to expand the options at the bottom to see this setting. You can start by just including all relevant maps. If you still end up with the same warnings, we’ll know that one of these maps is referencing these non-existent assets somehow. At that point, you could narrow down which map is giving you issues, if it isn’t multiple of them.
If you would rather I take a look, please feel free to send a copy of the project to me. You can do so privately by sending me a link to a download for it through a private message on our forums.
[1]:
Thank you for that offer. My project is kind of big, though. It has 3000+ animations and 100s of models from Mixamo Fuse in it. I am picking the ones I need and later I’m going to delete the ones I don’t. It’s about 20GB in size at the moment. Not sure where to upload this…
But if you say that all the paths are guaranteed to be inside assets (including levels), maybe I can figure it out on my own after all.
I already deleted all the maps I don’t need, which were all those showcases I imported along with content packs. There are only two maps I am currently working with and since I spawn everything procedurally, I basically just need them for their landscapes (which, sadly, I can’t spawn or change procedurally).
I spent days trying to fix all the warnings. When I fixed some, on the next packaging attempt there were even more of them. I went on fixing those too until the log showed zero errors and warnings, and still aborted with the same fatal error and empty log-entries like in my first post. Then I had the brilliant idea to take a look at the last asset (an AnimBP) that got successfully packaged. Turns out that in the same folder was another AnimBP that was utterly broken…
If I clicked at it or just looked at it for too long, the whole editor would crash and shut down. I had to delete its package from the windows explorer. I guess I had a custom anim node in that blueprint that I modified or deleted some time ago. So, the bottom line is, the packaging failure had nothing to do with the warnings but with a broken-beyond-repair animation blueprint. This probably doesn’t happen too often, but if anyone gets error messages like I did, you should check your assets in the “proximity” of the one that got packaged last.
As for the hundreds of warnings I am getting: they are almost exclusively caused by FStringAssetReferences that, for some reason, contain wrong path-information, and most of them are either PreviewMeshes of Materials/MaterialInstances or PreviewMeshes of Thumbnail-objects.
I wish you folks at Epic could improve the way assets are being managed. When you move a folder of assets, you can pretty much count on it that something is broken afterwards, even though the process takes forever.