LogStats Stats.zip (1.3 MB)
Could you please help me find what went wrong with packaging my build?
I attached the Log and I’ve always had trouble reading these.
Thank you for your help.
Respectfully,
David
Hey @DavidTveraas!
The UE client does some things that really assist when looking at the logs that you don’t get if you copy it over without formatting. Can you go through and find any yellow or red text and snip that with a few lines before and after? You really don’t often have to worry about anything that is standard white text. 
And yellow usually allows a compile but red is a hard no most of the time.
Looking through I see a lot of “Invalid value for PACKAGE_FILE_TAG at start of file.” Usually this is caused by GIT LFS only having the pointer file instead of the actual binary. Try doing a git pull!
If that doesn’t work you can also check this thread, they had similar issues and had to pull from the “Saved” directory after deleting the offending files. Can't open CTF map, Post Tag is not valid. File might be corrupted - #13 by N_otTfue
For another thing with your errors, it looks like you have a version of Vision OS that is possibly out of date? Also did you add that to your Visual Studio installation? If you didn’t that’s a big one you could do to solve a lot of errors.
Hope this helps, get back to us!
Thanks! It turns out the issue you identified were files I got from an asset pack which I was not using anyway, so I simply deleted them.
Packaging now work! Hurrah!!!
Glad you got it sorted! This is a classic case — corrupted binaries sneaking in from an asset pack you weren’t even using, and the log never points at the real culprit. You end up combing through thousands of lines just to find the one red entry that matters.
For anyone else hitting packaging failures like this, one thing that saves a lot of that detective work is running a pre-packaging scan before you build. There are a few tools on the Fab marketplace for this — I develop one called Package Preflight that scans your project for the most common packaging risks before you hit Package Project:
- Missing / misconfigured maps in the packaging map list
- Editor-only dependencies referenced by Runtime modules
- Uncompiled or broken Blueprints
- Missing asset references (dependencies whose package files no longer exist — exactly the kind of thing that surfaced in this thread)
- Oversized textures, config conflicts, file pollution, and more
It produces a severity-coded report (Error / Warning / Info) with evidence and fix suggestions for each finding, so you catch these issues before a failed build instead of after. It won’t catch everything — toolchain problems like VS/SDK version mismatches are outside its scope — but it does eliminate most of the project-side issues that lead to those dead-end “Unknown Error” logs.
Full disclosure: I’m the developer of Package Preflight, so take this recommendation with the appropriate grain of salt. That said, the lesson from this thread stands regardless — a lot of packaging failures come from assets you forgot you even had.