We’re currently trying to create patches for our game and we’re finding that the patches contain various assets that haven’t changed since we made the base release version. This occurs even if we immediately create a patch after our base version has finished building. Our basic steps are:
Create a release version, using the Project Launcher and call it 0.1.
Build is successful, and we have a 0.1 folder in our ‘Releases’ directory. (builds runs fine etc)
We then immediately make a patch and tell it to use 0.1 as our base
Patch is generated and is 1GB big and contains all our maps and a smattering of other assets.
We are running from source so we have tried to debug and find out what is going wrong, and it’s leading us to the GenerateHashForFile function in UnrealPak.cpp, when it uses the FMD5 FileHasher to create the hash.
For some reason, the generated Hash for the assets in game/saved/cooked (that are created because the creating a patch requires ‘Cook By The Book’) is different to the one that is in our 0.1 release, which gets extracted to StagedBuilds\WindowsNoEditor\GAME\Content\TempFiles folder when it is creating the patch.
I’ve run UnrealPak with the -test option on both the patch pak and the base 0.1 pak and it reports that everything is ok for both of them.
The output we get from the ProjectLauncher for the assets is this:
Source file hash for %s doesn’t match dest file hash %s and will be included in patch
One of the files that is always added to to the patch .pak is:
I don’t even know why this is being included in the build as we don’t use Paper2D, which makes it all the more confusing that the engine thinks it needs to be in the patch. It’s as if the assets are being cooked differently each time.
After many tests and builds we’ve noticed something very concerning.
Build a release package of the game
copy the saved/cooked content to a safe place.
make a release package of the game using the exact same settings.
compare two of the umap files in winmerge and there is a very small part of the file that is different.
How can this be? It seems as though when we cook the content, it’s producing the maps differently each time. This is with no compression, no encryption, no pak file, and with ‘Save packages without versions’.
We set up a empty starter project based on the first person template, and migrated one of our maps to that project. Repeating the same tests gives us the same results. The maps are different from one cook to another.
Do you have available showing that the .pak files aren’t going into the correct folders? Also, have you looked into the [documentation for creating patches][1]?
Yes we’ve followed the patch creation documentation to the letter, and originally assumed we were doing something wrong so have revisited and checked them multiple times.
I’ve attached two . One for original release build, and one for the patch. These were done in a test project with one of our maps migrated into it. [Release Build Log][1] | [Patch log][2]
We were originally suspicious of the NPC_Characters.uasset, as it seems to keep showing up in the patches, but this is just an enum with 4 entries in it. I’ve attached a screenshot of it as I can’t attach the uasset itself.
The other asset that consistently appears in our patches is DummySprite.uasset, which comes from engine/plugins/2D/paper2D/Content/ which really confused us.
Are there any investigative steps you can recommend we take at this point?
We have quite a few bug reports opened up on this issue. The .pak file issues are caused in general by bad serialization code. These issues are hard to track down and hard to fix so they inevitably occur all over the place and are generally associated with a particular asset type (Static mesh, Skeletal mesh, Texture, etc).
UE-19355 is a priority 2 which is still on our to do list and is unresolved.
UEPLAT-1013 is a priority 2 which is still on our to do list and is unresolved.
UEBP-93 is a priority 2 which is still on our to do list and is unresolved.
UECORE-288 is a priority 2 which is still on our to do list and is unresolved.
In order for us to debug this further, we will need to gather the different packages (in this case, the two cooked versions of the package), and also the original package. If you’ve made any changes to the engine, we’ll need those changes as well in order to debug this issue further.
You can also debug the issue yourself as it could have something to do with any code you’ve introduced into the engine. In this case, you would be trying to find where the packages deviate, which piece of content is causing the issue and which specific property. This is not a very easy task as it does involve debugging our serialization code.
However, keep in mind we are working on these bugs and we are really striving for 4.11 to be the release where these changes occur. Please feel free to check in any time to see the progress on these bugs. If you’re using the Source (GitHub) version of the engine, Lamb has already added in a bunch of changes which you could manually merge into your engine build.
Thanks for the information. We will try and look into what we can do about it.
Is there any information about what would actually cause this issue to start occurring, or is it something that ‘just happens’? For example, is it to do with upgrading from one engine version to another (where serialization code may have changed) and therefore potentially, recreating assets afresh in the newer version would alleviate the issue?
I’m asking since recreating assets or similar steps sounds like it would probably be quicker in the short term than actually debugging and fixing the issue properly.
The information that I got from Lamb was shared above. this seems to be something that just happens but it’s typically associated with asset types. Hopefully we’ll see progress within these bugs in a few weeks. Please feel free to check in at any time.
UE-19355 is a priority 2 which is still on our to do list and is unresolved.
UEPLAT-1013 is closed out as of 4.11.
UE-17748 was closed out for 4.11 and it pertains to deterministic cooking, relating back to UEPLAT-1013
UE-19632 was closed out for 4.12 and it also pertains to deterministic cooking relating back to UEPLAT-1013
UECORE-288 was fixed in 4.11 for blueprint deterministic cooking
If you notice anything out of the ordinary, you may want to submit your own AnswerHub Thread and link it back to this one as documentation, but you provide reproduction steps, , etc.
